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

[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]

дело не в том, что "увлекаться".

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

[w00dy.livejournal.com]

как можно перепутать номер счёта и назначение платежа? Это ж разные поля объекта, например.

[geekyfox.livejournal.com]

да банально опечататься при написании кода, с кем каких тупняков не бывает :-)

[w00dy.livejournal.com]

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

[geekyfox.livejournal.com]

ну вот опечатался я один раз, отвлекли меня, или что ещё, и написал foo.счётПлатежа = bar.назначениеПлатежа;

я хочу, чтобы волшебная система типов меня спасла!

[http://users.livejournal.com/_adept_/]

А в чем проблема-то? счетПлатежа и назначениеПлатежа - оба абстрактные типы, которые внутри строка. Но это таки разные типы, и если написать такое присваивание, то будет ошибка.

Ваш Капитан Очевидность.

[thinker8086.livejournal.com]

По треду выше фокс утверждает, что так никто не делает.

1С-Программисты тихо улыбаются и молчат.

[http://users.livejournal.com/_adept_/]

Делают-делают. Благо кода-обертки там - 2-5 строк на каждый новый тип (если писать на haskell или ocaml), а выгоды - вагон.

[thedeemon.livejournal.com]

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

Тесты - это одиночная стрельба в игре "морской бой". Типы - стрельба очередями, проходящими через все поле.

[geekyfox.livejournal.com]

да брось, в условиях внятного компонентного API и простых структур данных все ошибки, выявляемые типизацией, влёт ловятся даже поверхностным тестированием

в условиях хитрозамуженного API и структур, естественно, mileage may vary. но призыв в такой ситуации продумать то, откуда взялась эта сложность и нужна ли она вообще, походу вообще ни у кого не вызывает отклика, так что ладно.

[rblaze.livejournal.com]

http://evanfarrer.blogspot.ca/2012/06/unit-testing-isnt-enough-you-need.html

[geekyfox.livejournal.com]

любопытно, но, поскольку аффтар не удосужился заюзать для своего исследования pylint, довольно бессмысленно

[rblaze.livejournal.com]

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

[geekyfox.livejournal.com]

ну так покажите мне языки, на которых нельзя писать неряшливо

[rblaze.livejournal.com]

Ну так мы же не про д'Артаньяна, который будет писать красиво даже на фортране. Мы о том, как работать в команде средних пидарасов. И это исследование показывает, что даже если взять пидарасов получше средних и проекты, на которые постоянно смотрят, тесты всё равно не отлавливают всё, что могла бы выявить типизация.

[thesz.livejournal.com]

Типы представляют собой логику. Поэтому гарантировать корректность логики программы с помощью типов можно. Например, легко сделать так, что нельзя перепутать номер счёта и назначение платежа. Поэтому тесты нужны только функциональные, не на каждый чих. И да, проверок условий (рантаймных валидаторов) в нормальной программе быть не должно.

[geekyfox.livejournal.com]

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

[thesz.livejournal.com]

С другой стороны, если вы не готовы это делать, то не стоит кивать на слабости системы типов, не так ли?

Кстати, работы не так, чтобы много. Даже на Java можно. Один полиморфный класс PString<A>, повторяющий только нужные действия над String, несколько пустых классов для обозначения полей и пошло-поехало.

Я тут ознакомился с TSP поближе. У них есть postmortem анализы работ, в которых выявляются ошибки и предлагаются действия по их устранению в будущих проектах.

Моё мнение, что иметь представление об ошибке и о том, как её можно исправить и не исправлять - не то, что преступление, но совершенно ненужная бравада своей отвагой. Наподобие "кто кого перепьёт".

[geekyfox.livejournal.com]

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

[thesz.livejournal.com]

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

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

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

[geekyfox.livejournal.com]

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

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

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

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

Мне кажется

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

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

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

[jdevelop.livejournal.com]

про жабу - хаха три раза, вы все равно упретесь в кастование рано или поздно

генерики в жабе сделаны через очень большую жопу на самом деле.

[thesz.livejournal.com]

Что же тут поделать-то можно. Здесь ничего поделать нельзя.

[nealar.livejournal.com]

Я тут ознакомился с TSP поближе. У них есть postmortem анализы работ, в которых выявляются ошибки и предлагаются действия по их устранению в будущих проектах.
Где почитать? Смотрю на авиаторов и завидую тому, что у них есть разбор полётов.

[thesz.livejournal.com]

Эээ. Ну, ведутся отчёты о дефектах, обнаруженных: пересмотром (review) кода после написания, но перед коммитом; после коммита и пересмотра кода другими участниками (inspection - отличается от review, ибо сторонний глаз); в процессе тестирования; в процессе эксплуатации и тп.

После каждой итерации надо пересмотреть эти отчёты и выявить, какие же дефекты наиболее часто встречаются. Далее надо постараться писать код так, чтобы не допускать дефектов и снова вести отчёты.