Про динамическую типизацию

[thedeemon]

Поразжигал немного в комментах у ребе Б. рознь к социальной группе "ленивые авторы языков". Чтобы не излагать свою позицию каждый раз заново, сохраню сюда.

Знаете, некоторые печальные даты надолго остаются в памяти людей: 11 сентября, 17 августа, 1917-й год, 1941-й. К ним стоит добавить 1995-й - год появления JavaScript, PHP, Ruby, ну и Java тоже. Кому-то захотелось по-быстрому добавить динамизма в веб-странички, и он за пару недель наговнякал интерпретатор, встроив его в браузер Netscape. Кому-то захотелось оживить свою домашнюю страничку, добавить счетчик посетителей, еще что-то, и он на коленке сделал такой вот изменятель страничек на стороне сервера. О больших проектах тогда никто не думал, personal home page назывался тот изменятель. А когда делаешь интерпретатор, проще всего сделать его на динамической типизации. Это банально очень просто. О системе типов вообще можно не задумываться, не говоря уже об их выводе. К сожалению, на фоне тогдашнего мейнстрима (Си, ранние плюсы, что там еще было?) эти скриптовые языки выглядели очень выигрышно, писать мелкие куски кода на них было намного проще. Что такое нормальная система типов тогда мало кто знал: хаскель был еще в пеленках, ML'и традиционно не выходили из университетов. Так что люди эти скрипты подхватили, стали добавлять все новые функции. Менять систему типов стало поздно. В итоге выросло то, что выросло. С тех пор одна масса людей занята тем, чтобы делать все более сложные интерпретаторы, которые бы не так тормозили, другая масса придумывает 121-й способ добавить в JS типы, а третья на динамических языках пишет и плачет в бложиках о том, как грустно им делается. И проблема не только и не столько в скорости, сколько в maintainability кода и усилиях на необходимые тестирование и отладку при росте проектов.

Единственная реальная причина появления динамически типизированных языков - лень и недальновидность авторов. Эволюционно динамические языки - тупиковая ветвь, хоть они и обречены рождаться вновь и вновь просто потому что их делать проще, а делать языки люди любят. Сегодняшняя популярность некоторых из них - случайность, исторический казус, следствие контраста между этими языками и мейнстримом начала 90-х. То, что много идиотов используют идиотские языки, говорит лишь о том, что идиотов много. Сегодня, когда есть языки с нормальной статической системой типов, никаких реальных преимуществ у динамической больше нет. Только я имею в виду действительно нормальные статически типизированные языки - как минимум с параметрическим и ad hoc полиморфизмами, с выводом типов. Не Си с джавой. Хаскель, окамл, скала - такого уровня. У этих конкретных языков могут быть свои проблемы, часто инфраструктурные, но речь сейчас не о них, речь о динамической vs. статической типизации в целом.

Comments

[alexandr alexeev (from livejournal.com)]

Мысль интересная, но не во всем верная.

Во многих задачах от языка не требуется большой производительности. Например, если веб-приложение отвечает за <= 100 мс - это ОК. Perl да и другие языки с динамической типизацией с этой задачей легко справляются. Это справедливо и в отношении многих других приложений, часто программа упирается в диск, память или сеть, а не процессор.

Вы сами сказали, что во время появления JS, PHP и Ruby не было нормальных языков со статической типизацией. А программы писать на высокоуровневых удобных языках хотелось уже тогда, а не десяток лет спустя. Стало быть, появление озвученных языков - далеко не случайность, а вполне закономерное явление.

Наконец, люди не спроста так тащатся от питонов, пэхопе и иже с ними. Вы когда говорите, что вот в этом месте хотите сложить два числа, а вот в этом - вывести на экран, вы же думаете о числах, как о простых объектах, безо всяких там типов Int и String. В связи с этим динамическая типизация более понятна простым смертным, создает меньшую когнитивную нагрузку.

А у нас в отрасли кризис специалистов. Зачастую в программирование приходят бывшие админы, физики, врачи и тп. Ни у них, ни у компаний, которые их нанимают, нет пяти лет на полноценное обучение профессии. Знаешь PHP, условные операторы и циклы? Добро пожаловать в программисты!

Вот и имеем то, что имеем.

[thedeemon.livejournal.com]

Речь не про скорость, я же написал. Речь про поддерживаемость/развиваемость кода, когда его больше 200 строк.

Да, написать скрипт на 20 строк просто, и это хорошо. Написать аналогичный на приличном языке с выводом типов примерно так же просто.

В индустрии много малограмотных - это проблема, да. Но динамические языки ее не решают, на самом деле. Они ее чуть-чуть откладывают - позволяют быстро начать, а потом уже завязнуть в череде багов и циклах тестирования и отладки.

[inv2004.livejournal.com]

Я не выступаю в этом треде за диманическую/статическую типизацию. Но, по моему опыту - любой код, где больше 200строк - уже проблемный и требует рефакторинга и разбивания на гораздо мелкие и простые проблемы.

[geekyfox.livejournal.com]

чёрт, всё же надо освоить что-нибудь из APL-family :-D

[thedeemon.livejournal.com]

От разбивания суммарное число строк не уменьшается, обычно наоборот увеличивается.

[inv2004.livejournal.com]

Тем не менее я считаю каждый кусок можно будет рассматривать как маленькую простую задачу без привязки к остальным. Сейчас же тенденция нагородить что-то монстро-объектное, которое без хождения по внутренностям объектов не всегда понятно.

[thedeemon.livejournal.com]

В ООП так и стараются, в общем, делать - разбивать на отдельные проблемы, инкапсулировать незначимые детали. Так размер методов и классов уменьшается, но количество увеличивается, потом люди удивляются, почему в джаве 100500 классов и на каждый чих нужно по три объекта создать.

[geekyfox.livejournal.com]

Основная масса траблов в ООПнутом коде начинается тогда, когда люди начинают ныкать ошметки логики за инкапсуляцией. Типа, нам нужен класс наподобие FooWorker, но слегонца другой, в связи с этим мы пишем BarWorker extends FooWorker, выдергиваем в FooWorker'e куски кода в отдельные методы, перегружаем их в BarWorker, присовываем его куда надо и вроде бы профит, но потом, когда становится много методов, у которых нету ни единственной реализации, ни надёжного интерфейса, то без поллитры водки уже не разберёшься.

Однако! Я не вижу большой проблемы изобразить аналогичную порнографию на HOF, было бы желание :-D

Дядька Мейер пытался эти проблемы пресечь в Eiffel посредством контрактов, но "она тоже утонула".

Вообще, хороший код на джаве +/- изоморфен коду на коболе, решающему аналогичную задачу.

[potan.livejournal.com]

Только связи между задачами в голове становится тяжело держать. А уж их восстанавливать, если наткнулся на легаси-код, написанный в таком стиле...

[inv2004.livejournal.com]

Согласен, но эта проблема есть и сейчас.

[alexandr alexeev (from livejournal.com)]

Глупости вы все говорите. Наверное это очень удобно говорить, что на языках с динамической типизацией невозможно поддерживать проекты в которых больше 200 строк и пользоваться ЖЖ например.

[thedeemon.livejournal.com]

Я не говорю невозможно. Люди умудряются и не такое делать. Я говорю о количестве требуемых усилий.

[thinker8086.livejournal.com]

Знаете, тут вспоминается известный тезис из ИБ: "Ни одна проблема безопасности не может быть решена чисто техническими средствами, но любая - может быть решена чисто административными".

Так и тут - конечно, похапе позволяет писать индусский код а-ля "str + 0" (типа конвертация строки в целое, ага), но реально все проблемы майнтайнабилити - это проблемы администрирования проекта.

Если продумана нормальная архитектура системы, осуществлено нормальное покрытие тестами, проводится нормальный code review, присутствует нормальное и по делу применение ООП - не вижу проблем с тем же PHP для решения довольно масштабных задач.

По крайней мере, цифра порядка 1млн посетителей в сутки, если речь о вебе, - не предел, и это ведь с довольно недорогой инфраструктурой.

А вот если система делается на коленке студентом-индусом даже без контроля версий - тут бывает всякое. Но, как правильно замечено, ещё года 3-4, и ровно то же самое будет и в Хаскеле. Просто пока студенту-индусу "слабо" написать там Hello World. Как только этот порог преодолеет критическая масса - язык ровно так же ни от чего не спасёт, т.к. эти самые средства, призванные спасать - будут тупо игнориться.

[geekyfox.livejournal.com]

ППКС

[thedeemon.livejournal.com]

Все же классы допустимых ошибок заметно отличаются, а это отражается на необходимых для тестов и рефакторинга усилиях. Да, можно решать вопросы административно - взять неограниченное число людей и неограниченное время, например. Японцы это любят, я слышал. Но если какие-то проверки и операции можно возложить на машину, зачем от этого так упорно отказываться? Нет ничего хорошего в том, что для того, чтобы узнать, что в программе оказался вызов не того метода или с неправильным количеством аргументов, нужно писать кучу тестов, регулярно их запускать и поддерживать в актуальном состоянии.

Что до хаскеля, то во-первых не думаю, что критическая масса условных индусов сможет преодолеть барьер этого конкретного языка в обозримом будущем, а во-вторых, да, там тоже можно писать с ошибками, но совсем другими ошибками, не такими тупыми. Код с тупыми ошибками там не компилируется. И чем сильнее система типов, тем больше тот класс ошибок, что язык не дает так просто допустить.

Вон в похапе две классические функции array_map($callback, $arr) и array_filter($arr, $callback) имеют противоположный порядок аргументов, провоцируя регулярно их путать. Зачем решать этот вопрос административными методами и тестами, когда банальная проверка типов этот вопрос полностью снимает?

[thinker8086.livejournal.com]

>> И чем сильнее система типов, тем больше тот класс ошибок, что язык не дает так просто допустить.

Ещё раз - данный инструментарий, вполне вероятно, будет игнориться в случае отстуствия анальных кар, хотя, конечно, кое-что игнорить не получится. Не имею практического опыта на Хаскеле, могу заблуждаться в обе стороны.

Но вот будет ли тут кратный выигрыш в средней по отрасли эффективности разработки и отладки - сомневаюсь.

>> имеют противоположный порядок аргументов, провоцируя регулярно их путать.

1) Единственный тестовый прогон с включёнными предупреждениями всех уровней решает проблему обнаружения ошибки.

2) Нормальное IDE порядок параметров подскажет.

3) Да, меня тоже огорчает, что такие ошибки не ловятся автоматом. С другой стороны, пока мой опыт показывает, что такие и подобные ошибки виновны в сравнительно малом числе проблем. Косяки на уровне логики намного опаснее.