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

[thedeemon]

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

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

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

Comments

[si14.livejournal.com]

Будет. m1/m2/m3 это не TCP-пакеты, это пакеты уровня Erlang VM. TCP packet order обеспечивает консистентность самих m1/m2/m3.

[sassa-nf.livejournal.com]

Что "будет"?

Если m1/m2/m3 уходят по одному соединению, их порядок гарантирован TCP.

На видео речь идёт о совершенно ортогональной вещи. Речь о strict ordering vs reliable delivery. Так вот, Duncan всего лишь пожаловался, что в спецификации Эрланга не очень уточняется, что именно означает reliable delivery, а отсюда вытекают всякие вещи. И что в более поздних работах "кого-то там" именно этот вопрос уточняется. Из чего вытекает фокус с возможным reordering сообщений, которые переданы в cloud haskell по разным соединениям, хотя из program order должен бы выводиться total order сообщений.

У меня совершенно не сложилось впечатления, что де хаскель эту задачу решает "правильнее Эрланга", а лишь объясняется, почему они делают так, и что Эрланг тоже так поступает / будет поступать / столпы благословили такой подход.

Должен заметить, что ждать response совершенно не обязательно для гарантий reliable delivery. В Эрланге есть механизм Unit Of Order? Вот в Java Messaging Service есть.

В двух словах, Reliable delivery не отличается от такого упорядочивания, когда сообщения, отправленные в program order после отправки сообщения X, могут обозреваться получателем только после обозревания сообщения X. Unit of order создаёт такие ребра в partial order всех сообщений, получаемых агентом, что акторы работают как в reliable delivery.

Обращаю внимание на важный пункт: unit of order решается сугубо локальной логикой, не требующий синхронизации с удалёнными агентами, и всего лишь отражает локальную out of bounds синхронизацию, которую очередь сообщений не может наблюдать. Однако, это решение не может быть реализовано без примитивного барьера в системе передачи сообщений.

[thesz.livejournal.com]

Соединение TCP может быть разорвано. m1, m2, разрыв, подклюение, m3. Поскольку разрыв соединения может произойти до или после приёма m2, гарантировать приём (чтение принимающей стороной) m2 без изменения логики не представляется возможным.