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

[thedeemon]

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

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

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

Comments

[geekyfox.livejournal.com]

но, опять же, если вы готовы ввязываться в заталкивание максимального количества бизнес-логики в типизированную модель данных и принимать на себя все накладные расходы по (А) поддержанию всего этого хозяйства в актуальном виде и (Б) собственно его использованию - то не надо рассказывать сказок о том, как написание бесконечных type-conversions волшебным образом увеличивает до небес вашу производительность труда

[thesz.livejournal.com]

Есть такая нехитрая истина разработки ПО - чем быстрее вы обнаружите ошибку, тем дешевле её исправлять. Это основной результат многолетних исследований Software Engineering Institute (CMU SEI).

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

Никто не рассказывает вам сказки. Просто делятся своим опытом. Мне кажется, вам самому не хватает опыта использовать чужой опыт и оценить последствия тех или иных решений.

[geekyfox.livejournal.com]

чем быстрее вы обнаружите ошибку, тем дешевле её исправлять

Отлично. Я нашёл ошибку через пять минут ручного тестирования, вы нашли ошибку через час ковыряния кода, моделирующего домен. Я уже победил :-)

основной результат многолетних исследований

Ну раз вы такой весь из себя образованный, то вы должны знать, что кроме скорости обнаружения ошибки ещё есть такой параметр, как вероятность её появления. А вероятность появления ошибки пропорциональна размеру кодовой базы (грубо говоря, программист делает одну ошибку на N строк кода). В связи с этим, привнося дополнительный код типобезопасного моделирования домена вы неизбежно привносите возможные ошибки в коде типобезопасного моделирования домена. И вот тут начинается интересное :-)

Мне кажется

Когда мучают галлюцинации, надо ходить к профильному врачу.

Что же касается моего опыта, то количество времени и нервных клеток, которое я потратил на решение проблем, обусловленных опечатками, присовыванием интов заместо строчек и тому аналогичной мелочёвки, настолько не идёт в сравнение с тем, сколько я говна съел по причине, так сказать, излишне изощрённых архитектурных решений, что про первое даже неинтересно и разговаривать.

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

[thesz.livejournal.com]

>Я уже победил

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

Поэтому вы не победили, увы и ах.

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

Это подтверждено практикой или снова мысленный эксперимент?

Только прошу вас, не приводите в пример проекты на Си или Си++. Или на их более модных аналогах C# или Java. Ибо там контр-стимул не в статической типизации, а в побочных эффектах, которые не могут быть под контролем системы типов.

Ради практики применения типов посмотрите на результаты применения OCaml в Jane Street Capital. Там изменяют инфраструктуру почём зря. И это ещё не самая хорошая система типов.

[geekyfox.livejournal.com]

не, про Jane Street Capital неинтересно, там уровень разработчиков заметно выше среднерыночного и соответствующая культура разработки

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

[thesz.livejournal.com]

Увы, нет. Есть обратные. Средний C# программист не смог разобраться в очень сложном проекте на Хаскеле.

С другой стороны, это подтверждает необходимость Хаскеля. Если знает Хаскель, и справился на нём писать, значит - не дурак. А также "ваш проект на Хаскеле привлечёт только самых умных разработчиков".

[geekyfox.livejournal.com]

Жаль, было бы интересно поглядеть. Вообще, чисто умозрительно, у хаскеля должен быть совершенно запредельный потенциал написания говнокода в лучших традициях того, что "давайте распихаем всю бизнес-логику по костылям и подхачкам, волшебный конпелятор нас всё равно спасёт". Вот именно по всем тем причинам, которые вы перечислите в качестве достоинств. Но, видимо, entry barrier берёт своё.

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

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

[thesz.livejournal.com]

Я не могу согласиться насчёт accidential complexity и строгой типизации. Но и неопровержимых аргументов у меня нет.

Всё, что мне остаётся, это заявление о намерениях - "я буду искать аргументы!" ;)

[geekyfox.livejournal.com]

Помилуйте, то, что использование статически типизированных языков позволяет разработку более сложных (в том числе и акцидентально более сложных) проектов, которые, при такой сложности продолжают быть maintainable и shippable - это просто-таки selling point статически типизированных языков. Тут я не знаю, с чем можно спорить.

То, что не только позволяет, но и стимулирует - тут всё очень зависит от более других факторов.

[thedeemon.livejournal.com]

Хаотически перемешать функторы еще нужно суметь, тут не одно Ph.D. может потребоваться. У некоторых вот реальная проблема, что монады не коммутируют, собаки такие. ;)

[geekyfox.livejournal.com]

данунеее, главное один раз вкурить, что функтор - это такая фабрика декораторов, дальше дело пойдёт шустро ;-)

[dmzlj.livejournal.com]

Exactly! http://www.slideshare.net/voidlizard/operden1-7764151

[geekyfox.livejournal.com]

* тема квалификации разрабов не раскрыта.
* тема качества кодовой базы после двух лет майнтенанса в режиме "ну пожалуйста приделайте эту фичу к послезавтрему, Сансаныч оч просил" не раскрыта.
* позырить на магаз нельзя.

не интересно.

[soonts.livejournal.com]

В процессе ресёрча для основной ветки холивара с афтаром, наткнулся на пост сотрудника Amazon.
Там было 2 группы разработчиков, на Perl и на Java, он пишет шо Perl в целом заруливал именно из-за ДТЯ:
https://sites.google.com/site/steveyegge2/is-weak-typing-strong-enough

[geekyfox.livejournal.com]

самое смешное в этой статейке - то, что эту адвокатуру ДТЯ (в контексте Lisp/Perl vs Java) можно с минимальными изменениями преобразовать в адвокатуру СТЯ (в контексте Haskell vs JavaScript)

[thedeemon.livejournal.com]

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

"Cons of static typing

They artifically limit your expressiveness.
In Java, for instance, the type system doesn't let you do operator overloading, multiple inheritance, mix-ins, reference parameters, or first-class functions. "

С скале и окамле все это доступно, насколько мне известно. Отсутствие таких фич - отнюдь не свойство static typing, это чисто свойство джавы, как языка намеренно обедненного.