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

[thedeemon]

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

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

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

Comments

[theiced.livejournal.com]

статическая типизация не нужна вообще как класс.

[potan.livejournal.com]

Замена работающего кода без остановки системы все-таки на динамических языках делается проще.

[thedeemon.livejournal.com]

Много ли языков помимо Эрланга могут похвастаться такой фичей?

[thedeemon.livejournal.com]

Все правильно, кроме опечатки в первом слове. s/стат/динам/ :)

[volodymir-k.livejournal.com]

> Что такое нормальная система типов тогда мало кто знал: хаскель был еще в пеленках

Кто вам такую чухню сказал? Про системы типов было всё известно ещё в 70-х после Алгола, ФП-логическое-ООП уже тогда были в полный рост. А уж в 90-х и Лисков с КЛУ, и Мейерс с Эйфелем, да как бы и Вирт.

Университет кстати тогда практически все программеры б-м проходили, это вам не сейчас. И лабы у них были на уровне "сделайте после лекций компилятор языка с загрузчиком и отладчиком за семестр".

[volodymir-k.livejournal.com]

Если вдуматься, безумное требование. Либо у рантайма есть точка "ожидания" (и тогда система по сути остановлена), либо стеки и адреса выполнения мгновенно мапятся от балды и всё падает. Поменять можно неисполняемый прямо сейчас код, так это и асм, и ява умеет.

[potan.livejournal.com]

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

[vp.livejournal.com]

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

[vp.livejournal.com]

Все верно написано. Рождение ПХП и иже с ним - сугубо следствие ошибки масштаба. Сделали "вот так вот" - и пошло поехало по граблям и костылям.

[potan.livejournal.com]

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

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

У питона через раз работает для отдельного модуля из коробки. reload(module).
Я дописывал две страницы кода в проект, что бы работало чаще чем через раз. И с удовольствием использовал для того, что бы по кнопке перегружать свои скрипты без перезапуска сервера и клиента.

module.function = новая_реализация; работает во всех языках.

[geekyfox.livejournal.com]

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

другое дело, что немногие умеют писать без "объектно-ориентированных архитектур".

[thedeemon.livejournal.com]

Резонно, хотя авторы РНР явно прогуляли все занятия. Что до остальных - тем более их следует обвинить в лени и недальновидности, если могли сделать хорошо, но не стали.

[gineer.livejournal.com]

Скорее... немногие умеют писать... :))
то что проходит у рядового быдлокодера под графом "объектно-ориентированая архитектура"... это уже не видят, это исключительно нюхают. :)))

[gineer.livejournal.com]

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

Угу... если не учитывать уже существующей кодовой базы, наличия горы документации и примеров, поддержки разнообразными тулзами.
Да... никаких реальных приимуществ.
Как у динозавров (в эпоху их царствования)
по сравнению с млекопитающими. :)
Совсем никаких. :))


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

Вот так всегда.
"Он конечно сукин сын, но это НАШ сукины сын"... :))

[plumqqz.livejournal.com]

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

[vinslivins.livejournal.com]

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

[vinslivins.livejournal.com]

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

[vissarion.livejournal.com]

Все статические языки обвиняют в недостатке динамизма
а динамические - в отсутствии статической типизации

В ответ статические языки судорожно придумывают костыли вроде Reflections и Groovy

А динамические языки шлют всех лесом и ничего не делают сторону от утиной типизации.

[inv2004.livejournal.com]

Как обычно - APL.

[geekyfox.livejournal.com]

я имею в виду: когда есть более-менее осознанное процедурное API, оперирующее незамысловатыми структурами данных, то писать напротив него бизнес-логику на динамически типизированных языках - легко и приятно.

а вот когда возникает иерархия фабрик абстрактных декораторов - то вот тут начинается PAIN :-D

[osdm.livejournal.com]

В большинстве случаев не сработало бы, потому что появилось бы две копии типов (из старого модуля и из нового модуля), не совместимых между собой. Но вообще замена кода должна делаться как в андроиде: сохранили состояние и перезапустили программу. Тогда любой язык подойдет.

[diam-2003.livejournal.com]

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

Простая стыковка с "инородными" системами типов, выраженными, например, в сериализационных форматах и в структуре баз данных. Да, в статике тоже можно, и даже можно почти как в динамике (type providers те же), но в динамике с этим проще.

[stdray.livejournal.com]

Придумывают более выразительные системы типов, в которых больше правильных программ будут корректно типизированы.

[izard.livejournal.com]

clojure