Про динамическую типизацию
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 12:34 pm (UTC)no subject
Date: 2012-10-11 12:39 pm (UTC)no subject
Date: 2012-10-11 02:06 pm (UTC)Кстати, работы не так, чтобы много. Даже на Java можно. Один полиморфный класс PString<A>, повторяющий только нужные действия над String, несколько пустых классов для обозначения полей и пошло-поехало.
Я тут ознакомился с TSP поближе. У них есть postmortem анализы работ, в которых выявляются ошибки и предлагаются действия по их устранению в будущих проектах.
Моё мнение, что иметь представление об ошибке и о том, как её можно исправить и не исправлять - не то, что преступление, но совершенно ненужная бравада своей отвагой. Наподобие "кто кого перепьёт".
no subject
Date: 2012-10-11 02:26 pm (UTC)no subject
Date: 2012-10-11 04:28 pm (UTC)Накладные расходы по поддержанию всего этого хозяйства в актуальном виде как раз ведут к удешевлению поддержки ПО. Ибо вы не можете допустить глупую опечатку и обязаны увязать все проблемные места.
Никто не рассказывает вам сказки. Просто делятся своим опытом. Мне кажется, вам самому не хватает опыта использовать чужой опыт и оценить последствия тех или иных решений.
no subject
Date: 2012-10-11 05:59 pm (UTC)Отлично. Я нашёл ошибку через пять минут ручного тестирования, вы нашли ошибку через час ковыряния кода, моделирующего домен. Я уже победил :-)
основной результат многолетних исследований
Ну раз вы такой весь из себя образованный, то вы должны знать, что кроме скорости обнаружения ошибки ещё есть такой параметр, как вероятность её появления. А вероятность появления ошибки пропорциональна размеру кодовой базы (грубо говоря, программист делает одну ошибку на N строк кода). В связи с этим, привнося дополнительный код типобезопасного моделирования домена вы неизбежно привносите возможные ошибки в коде типобезопасного моделирования домена. И вот тут начинается интересное :-)
Мне кажется
Когда мучают галлюцинации, надо ходить к профильному врачу.
Что же касается моего опыта, то количество времени и нервных клеток, которое я потратил на решение проблем, обусловленных опечатками, присовыванием интов заместо строчек и тому аналогичной мелочёвки, настолько не идёт в сравнение с тем, сколько я говна съел по причине, так сказать, излишне изощрённых архитектурных решений, что про первое даже неинтересно и разговаривать.
Но вот к качеству проектирования вся эта типизация имеет отношение вполне ортогональное, и корреляция если и есть, то скорее отрицательная: статическая типизация компонент ослабляет ограничения на размеры и качество кодовой базы жизнеспособного продукта и, соответственно, является контр-стимулом к реинжинирингу всего этого хозяйства.
no subject
Date: 2012-10-11 06:29 pm (UTC)Коль вы уж заговорили о тестировании, то скорость работы проверяется статистикой, а не одним мысленным примером.
Поэтому вы не победили, увы и ах.
>Но вот к качеству проектирования вся эта типизация имеет отношение вполне ортогональное, и корреляция если и есть, то скорее отрицательная: статическая типизация компонент ослабляет ограничения на размеры и качество кодовой базы жизнеспособного продукта и, соответственно, является контр-стимулом к реинжинирингу всего этого хозяйства.
Это подтверждено практикой или снова мысленный эксперимент?
Только прошу вас, не приводите в пример проекты на Си или Си++. Или на их более модных аналогах C# или Java. Ибо там контр-стимул не в статической типизации, а в побочных эффектах, которые не могут быть под контролем системы типов.
Ради практики применения типов посмотрите на результаты применения OCaml в Jane Street Capital. Там изменяют инфраструктуру почём зря. И это ещё не самая хорошая система типов.
no subject
Date: 2012-10-11 06:52 pm (UTC)интересен был бы кейс вида "пацанчики сраёна сели писать интернет-магазин запчастей на хаскеле и у них получилось это сделать без ста восьмидесяти хаотически перемешанных между собой функторов". у вас есть такой пример?
no subject
Date: 2012-10-11 07:25 pm (UTC)С другой стороны, это подтверждает необходимость Хаскеля. Если знает Хаскель, и справился на нём писать, значит - не дурак. А также "ваш проект на Хаскеле привлечёт только самых умных разработчиков".
no subject
Date: 2012-10-11 07:46 pm (UTC)Строгая типизация - это, безусловно, очень хорошее средство примириться с акцидентальной сложностью кодовой базы. Но, блин, не надо с ней примиряться!
Ну и как таковой навык "умеющий читать и писать замысловатый код" далеко не для любого проекта является ключевым, но тут всё слишком взаимосвязано, чтобы обобщать.
no subject
Date: 2012-10-11 08:03 pm (UTC)Всё, что мне остаётся, это заявление о намерениях - "я буду искать аргументы!" ;)
no subject
Date: 2012-10-11 08:36 pm (UTC)То, что не только позволяет, но и стимулирует - тут всё очень зависит от более других факторов.
no subject
Date: 2012-10-11 07:47 pm (UTC)no subject
Date: 2012-10-11 07:52 pm (UTC)no subject
Date: 2012-10-12 03:22 am (UTC)no subject
Date: 2012-10-12 07:51 am (UTC)* тема качества кодовой базы после двух лет майнтенанса в режиме "ну пожалуйста приделайте эту фичу к послезавтрему, Сансаныч оч просил" не раскрыта.
* позырить на магаз нельзя.
не интересно.
no subject
Date: 2012-10-18 11:16 pm (UTC)Там было 2 группы разработчиков, на Perl и на Java, он пишет шо Perl в целом заруливал именно из-за ДТЯ:
https://sites.google.com/site/steveyegge2/is-weak-typing-strong-enough
no subject
Date: 2012-10-19 09:52 am (UTC)no subject
Date: 2012-10-19 12:33 pm (UTC)"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, это чисто свойство джавы, как языка намеренно обедненного.
no subject
Date: 2012-10-11 04:53 pm (UTC)генерики в жабе сделаны через очень большую жопу на самом деле.
no subject
Date: 2012-10-11 06:22 pm (UTC)no subject
Date: 2012-10-12 11:07 am (UTC)Где почитать? Смотрю на авиаторов и завидую тому, что у них есть разбор полётов.
no subject
Date: 2012-10-12 07:50 pm (UTC)После каждой итерации надо пересмотреть эти отчёты и выявить, какие же дефекты наиболее часто встречаются. Далее надо постараться писать код так, чтобы не допускать дефектов и снова вести отчёты.