Про динамическую типизацию
Oct. 11th, 2012 01:33 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
thedeemonПоразжигал немного в комментах у ребе Б. рознь к социальной группе "ленивые авторы языков". Чтобы не излагать свою позицию каждый раз заново, сохраню сюда.
Знаете, некоторые печальные даты надолго остаются в памяти людей: 11 сентября, 17 августа, 1917-й год, 1941-й. К ним стоит добавить 1995-й - год появления JavaScript, PHP, Ruby, ну и Java тоже. Кому-то захотелось по-быстрому добавить динамизма в веб-странички, и он за пару недель наговнякал интерпретатор, встроив его в браузер Netscape. Кому-то захотелось оживить свою домашнюю страничку, добавить счетчик посетителей, еще что-то, и он на коленке сделал такой вот изменятель страничек на стороне сервера. О больших проектах тогда никто не думал, personal home page назывался тот изменятель. А когда делаешь интерпретатор, проще всего сделать его на динамической типизации. Это банально очень просто. О системе типов вообще можно не задумываться, не говоря уже об их выводе. К сожалению, на фоне тогдашнего мейнстрима (Си, ранние плюсы, что там еще было?) эти скриптовые языки выглядели очень выигрышно, писать мелкие куски кода на них было намного проще. Что такое нормальная система типов тогда мало кто знал: хаскель был еще в пеленках, ML'и традиционно не выходили из университетов. Так что люди эти скрипты подхватили, стали добавлять все новые функции. Менять систему типов стало поздно. В итоге выросло то, что выросло. С тех пор одна масса людей занята тем, чтобы делать все более сложные интерпретаторы, которые бы не так тормозили, другая масса придумывает 121-й способ добавить в JS типы, а третья на динамических языках пишет и плачет в бложиках о том, как грустно им делается. И проблема не только и не столько в скорости, сколько в maintainability кода и усилиях на необходимые тестирование и отладку при росте проектов.
Единственная реальная причина появления динамически типизированных языков - лень и недальновидность авторов. Эволюционно динамические языки - тупиковая ветвь, хоть они и обречены рождаться вновь и вновь просто потому что их делать проще, а делать языки люди любят. Сегодняшняя популярность некоторых из них - случайность, исторический казус, следствие контраста между этими языками и мейнстримом начала 90-х. То, что много идиотов используют идиотские языки, говорит лишь о том, что идиотов много. Сегодня, когда есть языки с нормальной статической системой типов, никаких реальных преимуществ у динамической больше нет. Только я имею в виду действительно нормальные статически типизированные языки - как минимум с параметрическим и ad hoc полиморфизмами, с выводом типов. Не Си с джавой. Хаскель, окамл, скала - такого уровня. У этих конкретных языков могут быть свои проблемы, часто инфраструктурные, но речь сейчас не о них, речь о динамической vs. статической типизации в целом.
Знаете, некоторые печальные даты надолго остаются в памяти людей: 11 сентября, 17 августа, 1917-й год, 1941-й. К ним стоит добавить 1995-й - год появления JavaScript, PHP, Ruby, ну и Java тоже. Кому-то захотелось по-быстрому добавить динамизма в веб-странички, и он за пару недель наговнякал интерпретатор, встроив его в браузер Netscape. Кому-то захотелось оживить свою домашнюю страничку, добавить счетчик посетителей, еще что-то, и он на коленке сделал такой вот изменятель страничек на стороне сервера. О больших проектах тогда никто не думал, personal home page назывался тот изменятель. А когда делаешь интерпретатор, проще всего сделать его на динамической типизации. Это банально очень просто. О системе типов вообще можно не задумываться, не говоря уже об их выводе. К сожалению, на фоне тогдашнего мейнстрима (Си, ранние плюсы, что там еще было?) эти скриптовые языки выглядели очень выигрышно, писать мелкие куски кода на них было намного проще. Что такое нормальная система типов тогда мало кто знал: хаскель был еще в пеленках, ML'и традиционно не выходили из университетов. Так что люди эти скрипты подхватили, стали добавлять все новые функции. Менять систему типов стало поздно. В итоге выросло то, что выросло. С тех пор одна масса людей занята тем, чтобы делать все более сложные интерпретаторы, которые бы не так тормозили, другая масса придумывает 121-й способ добавить в JS типы, а третья на динамических языках пишет и плачет в бложиках о том, как грустно им делается. И проблема не только и не столько в скорости, сколько в maintainability кода и усилиях на необходимые тестирование и отладку при росте проектов.
Единственная реальная причина появления динамически типизированных языков - лень и недальновидность авторов. Эволюционно динамические языки - тупиковая ветвь, хоть они и обречены рождаться вновь и вновь просто потому что их делать проще, а делать языки люди любят. Сегодняшняя популярность некоторых из них - случайность, исторический казус, следствие контраста между этими языками и мейнстримом начала 90-х. То, что много идиотов используют идиотские языки, говорит лишь о том, что идиотов много. Сегодня, когда есть языки с нормальной статической системой типов, никаких реальных преимуществ у динамической больше нет. Только я имею в виду действительно нормальные статически типизированные языки - как минимум с параметрическим и ad hoc полиморфизмами, с выводом типов. Не Си с джавой. Хаскель, окамл, скала - такого уровня. У этих конкретных языков могут быть свои проблемы, часто инфраструктурные, но речь сейчас не о них, речь о динамической vs. статической типизации в целом.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-10-11 04:30 pm (UTC)no subject
Date: 2012-10-11 05:03 pm (UTC)no subject
Date: 2012-10-17 08:03 am (UTC)Так и тут - конечно, похапе позволяет писать индусский код а-ля "str + 0" (типа конвертация строки в целое, ага), но реально все проблемы майнтайнабилити - это проблемы администрирования проекта.
Если продумана нормальная архитектура системы, осуществлено нормальное покрытие тестами, проводится нормальный code review, присутствует нормальное и по делу применение ООП - не вижу проблем с тем же PHP для решения довольно масштабных задач.
По крайней мере, цифра порядка 1млн посетителей в сутки, если речь о вебе, - не предел, и это ведь с довольно недорогой инфраструктурой.
А вот если система делается на коленке студентом-индусом даже без контроля версий - тут бывает всякое. Но, как правильно замечено, ещё года 3-4, и ровно то же самое будет и в Хаскеле. Просто пока студенту-индусу "слабо" написать там Hello World. Как только этот порог преодолеет критическая масса - язык ровно так же ни от чего не спасёт, т.к. эти самые средства, призванные спасать - будут тупо игнориться.
no subject
Date: 2012-10-17 08:30 am (UTC)no subject
Date: 2012-10-17 09:01 am (UTC)Что до хаскеля, то во-первых не думаю, что критическая масса условных индусов сможет преодолеть барьер этого конкретного языка в обозримом будущем, а во-вторых, да, там тоже можно писать с ошибками, но совсем другими ошибками, не такими тупыми. Код с тупыми ошибками там не компилируется. И чем сильнее система типов, тем больше тот класс ошибок, что язык не дает так просто допустить.
Вон в похапе две классические функции array_map($callback, $arr) и array_filter($arr, $callback) имеют противоположный порядок аргументов, провоцируя регулярно их путать. Зачем решать этот вопрос административными методами и тестами, когда банальная проверка типов этот вопрос полностью снимает?
no subject
Date: 2013-02-14 11:19 pm (UTC)Ещё раз - данный инструментарий, вполне вероятно, будет игнориться в случае отстуствия анальных кар, хотя, конечно, кое-что игнорить не получится. Не имею практического опыта на Хаскеле, могу заблуждаться в обе стороны.
Но вот будет ли тут кратный выигрыш в средней по отрасли эффективности разработки и отладки - сомневаюсь.
>> имеют противоположный порядок аргументов, провоцируя регулярно их путать.
1) Единственный тестовый прогон с включёнными предупреждениями всех уровней решает проблему обнаружения ошибки.
2) Нормальное IDE порядок параметров подскажет.
3) Да, меня тоже огорчает, что такие ошибки не ловятся автоматом. С другой стороны, пока мой опыт показывает, что такие и подобные ошибки виновны в сравнительно малом числе проблем. Косяки на уровне логики намного опаснее.