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

[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'а это тривиально решается программистом. Более того, пример, который приводится там в презентации Cloud Haskell как «решение проблемы» — откровенно идиотский, т.к. это просто примитивное ожидание подтверждения получения сообщения без какой-либо логики вроде таймаутов и «а что делать, если потерялось именно подтверждение», и он ровно так же присутствует в Erlang'е (впрочем, хотя бы с таймаутами).

Кстати, я как-то забыл ещё один момент: очень заметно, что тот товарищ — дилетант в Erlang'е, потому как Cloud Haskell не имеет одной из главных (и, имхо, даже более важных, чем межнодное взаимодействие) фич: супервизоров и их деревьев. Проект, который заявляет о том, что он «Erlang-inspired», при отсутствии супервизоров можно закапывать сразу.

[thesz.livejournal.com]

>супервизоров и их деревьев.

Прав ли я, что супервизоры и их деревья (которые, если мне не изменяет память, обычно являются чем-то вроде расчёски, ибо количество уровней чаще всего 1) выполняются в виде библиотеки поверх сообщений от VM? Если я прав, то сообщения от VM об отключении процесса есть, насколько я понимаю в состоянии дел. Если я не прав, то не затруднит ли вас показать, где в языке Эрланг, без OTP, присутствует этот функционал?

[si14.livejournal.com]

Вы же вроде хлопнули дверью, если мне не изменяет память?

>количество уровней чаще всего 1
Нет
>супервизоры и их деревья выполняются в виде библиотеки поверх сообщений от VM
Нет
>не затруднит ли вас показать, где в языке Эрланг, без OTP, присутствует этот функционал
links/monitors/trap_exit

[thesz.livejournal.com]

Даже если вам изменяет память, есть Яндекс, Гугл и просто путешествие выше по ссылкам.

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

Поскольку вы сказали категорическое "нет", я хотел бы попросить вас дать статистику по проектам на Эрланге, которая бы подтвердила бы "не чаще всего". Ибо мои сведения взяты из устаревшей, наверное, диссертации Джо Армстронга.

Спасибо за links/monitors/trap_exit. Это отлично подтвердило ваши слова. Более чем. Любой, кто прочитает links/monitors/trap_exit способен уверовать в отсутствие супервизоров на сообщениях от VM. Ибо зачем ему проверять? И вам не стоит давать ссылки, ибо вдруг кто проверит, не станет верить на слово.

У меня позиция много слабей. Я всего лишь могу предоставить ссылку на код на GitHub: https://github.com/haskell-distributed/distributed-process/blob/master/distributed-process/src/Control/Distributed/Process.hs

Там нет магических слов links/monitors/trap_exit. Там есть вот такой кусочек кода:

    -- * Monitoring and linking
  , link
  , linkNode
  , linkPort
  , unlink
  , unlinkNode
  , unlinkPort
  , monitor
  , monitorNode
  , monitorPort
  , unmonitor
  , ProcessLinkException(..)
  , NodeLinkException(..)
  , PortLinkException(..)
  , MonitorRef -- opaque
  , ProcessMonitorNotification(..)
  , NodeMonitorNotification(..)
  , PortMonitorNotification(..)
  , DiedReason(..)

Это декларации для удобного импорта. На мой взгляд, присутствует весь необходимый функционал. Реализация функций находится вот здесь: https://github.com/haskell-distributed/distributed-process/blob/master/distributed-process/src/Control/Distributed/Process/Internal/Primitives.hs

Хочу вернуться к диссертации Джо. Вот она: http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf

Да, описание мониторов находится в описании Эрланга.

Однако, есть и страница 41: "Viewed as a concurrent language, Erlang is very simple. Since there are no shared data structures, no monitors or synchronised methods etc there is very little to learn."

Получается, что в самом Эрланге нет мониторов, но они есть в его VM.

А вот описание деревьев супервизоров начинается на странице 118, в разделе "Programming Fault Tolerant Systems". То есть, к Эрлангу, как языку и его VM, это отношение не имеет. А я, вроде, об этом спрашивал.

Ну, и страница 175: "There were a total of 141 .app files the AXD sodware. These 141 files represent 11 disjoint supervision trees. Most of the supervision trees are very flat and do not have a complex structure." Далее страница 176: "There are two main sub-nodes in the tree, and the supervisor structure underneath the sub-nodes is flat.".

То есть, как минимум poster child project Эрланга имеет структуру супервизоров, как описал я.

[si14.livejournal.com]

>Даже если вам изменяет память, есть Яндекс, Гугл и просто путешествие выше по ссылкам.
Именно так, просто я хотел слегка смягчить указание на то, что возвращаться после хлопка дверью несколько убого.

>хотел бы попросить вас дать статистику по проектам на Эрланге, которая бы подтвердила бы "не чаще всего"
Статистику, будьте добры, посчитайте как-нибудь сами, я же приведу в пример пару приложений — системный kernel и сверхпопулярный ranch (ex-cowboy):
http://i.imgur.com/xpFLc.png
http://i.imgur.com/kPrPb.png
Тезисы Армстронга с 2003 года это мило, но с тех пор прошло почти 10 лет.

>Получается, что в самом Эрланге нет мониторов, но они есть в его VM.
Пожалуйста, изучайте вопрос полнее перед тем, как делать какие-либо утверждения и выводы.
https://en.wikipedia.org/wiki/Monitor_%28synchronization%29
http://www.erlang.org/doc/man/erlang.html#monitor-2
Это принципиально разные вещи. На странице 41 идёт речь о первом, я говорил о втором.

Я не совсем понял, в чём вы попытались меня уличить, кстати, но в целом ситуация меня крайне забавляет всю ветку: вам никак не надоедает учить меня Erlang'у, хотя казалось бы, с чего б вам это делать.

[thesz.livejournal.com]

Меня мало волнует кем-то воспринимаемая убогость. Мне надо сделать определённые действия, я их делаю.

>вам никак не надоедает учить меня Erlang'у, хотя казалось бы, с чего б вам это делать.

Что вы! Я делюсь известной мне информацией и получаю неизвестную мне. Параллельно пробуя разобраться с увиденными мной логическими ошибками.

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

[si14.livejournal.com]

>Зачем делать глубокие деревья?
Erlang and OTP in Action, Martin Logan, Eric Merritt, and Richard Carlsson, 2010

>Как я понимаю, они менее устойчивы
Неправильно понимаете.

[thesz.livejournal.com]

Замечательно. Большое спасибо.

[thesz.livejournal.com]

Пропустил насчёт "уличить".

Вот, в чём.

Вы воспринимаете Эрланг вместе с его VM и OTP. Если вы отделите Эрланг от VM и OTP, вас ждёт много интересного. Например, открытие, что Эрланг - очень плохой язык. Потому, что простой.

В частности, в самом Эрланге нет мониторов ни в одном из указанных вами смыслов.

Далее, вы обвинили автора distributed-process в отсутствии мониторов процессов, когда они там есть. Достаточно было посмотреть на основной файл с экспортами. Аналога супервизоров OTP нет, есть такое. Но средства сделать это есть.

А это означает второе замечательное открытие - OTP переносима.

[si14.livejournal.com]

>Эрланг - очень плохой язык. Потому, что простой
Спасибо за крайне весомое экспертное заключение. Как ни странно, не только я, но и Лев Валкин, основной бизнес которого построен на Erlang'е, считает простоту Erlang'а одним из основных его плюсов. Равно как и тысячи других людей, пишущих на Erlang'е работоспособные продукты. Равно как и люди из Эриксона, которые создали Erlang. Но, безусловно, все мы просто глупы.

>вы обвинили автора distributed-process в отсутствии мониторов процессов, когда они там есть
Это снова ваша фантазия. Цитирую себя же:
>Cloud Haskell не имеет одной из главных (и, имхо, даже более важных, чем межнодное взаимодействие) фич: супервизоров и их деревьев
Где вы увидели тут что-то про «отсутствие мониторов процессов»?

>OTP переносима
...но не на Haskell. В соседней ветке вы уже высказались по поводу «рантайм дебаг и интроспекция не нужны, у настоящих профессионалов не бывает ошибок и всё сразу работает без багов», однако это по-прежнему одни из основных фич OTP. Поэтому для того, чтобы состязаться с OTP, неплохо бы для начала придумать, как сконструировать сходный рантайм с горячими обновлениями и динамической интроспекцией. В противном же случае вы вольны называть свои любимые продукты как угодно, но не «новая версия Erlang'а» и не «OTP поверх Haskell».

[thesz.livejournal.com]

>Как ни странно, не только я, но и Лев Валкин, основной бизнес которого построен на Erlang'е, считает простоту Erlang'а одним из основных его плюсов.

Если я всё правильно понимаю, на Эрланге в Echo пишут довольно простую логику. Ибо сложную логику писать на Эрланге грех.

Вот, например, транслятор синтезируемого подмножества VHDL с моделированием вы точно не станете писать на Эрланге. Ибо 1) сложно и 2) медленно.

Или станете?

>Но, безусловно, все мы просто глупы.

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

>Это снова ваша фантазия. Цитирую себя же:

Вот интересный кусок: http://thedeemon.livejournal.com/54732.html?thread=814284#t814284

Если я всё правильно понимаю, супервизоры и их деревья являются библиотекой поверх мониторов. То есть, это тривиальная вещь при наличии менее тривиальной, более базовой.

Или я опять не прав?

И опять же, вы путаете Эрланг и OTP. OTP не для всего подходит, как и Эрланг. Прошу прощения, но это необходимо пояснить нашим читателям.

[si14.livejournal.com]

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

>Тем не менее, моя позиция звучит, как "не знают лучшего". Не знаю, времени не хватило, слишком молоды, не работают над ошибками
Для такой позиции неплохо бы иметь хоть какие-то аргументы, кроме того, что это ваше мнение — или, хотя бы, авторитет в виде каких-то реальных проектов. Я бы попросил вас всё-таки показать ваш аккаунт на гитхабе, чтобы я мог оценить, насколько лучше писать работающие вещи на Haskell'е. Бессмысленные игры с эмуляцией зависимых типов на деньги работодателя меня не очень интересуют, простите.

>Вот интересный кусок
Сколько раз вы ещё собираетесь лгать, передёргивать и приписывать мне свои слова, после чего делать вид, что с вами стоит продолжать беседу, и задавать какие-то вопросы?

[thesz.livejournal.com]

Опыт приобретается путём большого количества проб и ошибок. Качество ошибок и работа над ошибками - намеренная работа над ошибками, - позволяет повысить уровень программиста. Да вообще хоть кого. Например, пианисты высокого уровня играют в день меньше, чем средние пианисты. Но они играют трудные вещи, то, что плохо получается. Атлеты в Westside Barbell занимаются четыре дня в неделю, 45 минут в день и бьют рекорда в силовом троеборье.

Экономия времени на создание ошибок и их исправление приводит к ускорению собственного развития.

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

Поэтому я меряю "годность" языка по числу предметных областей, где я его могу применить.

По этому критерию конкретно Эрланг является плохим языком. Прошу прощения, но Common Lisp или Scheme лучше.

А от высоконагруженных серверов, торчащих в веб, меня отделяет всего лишь желание этим заняться.

У меня нет аккаунта на гитхабе. Вот мой репозиторий на mskhug: http://thesz.mskhug.ru/svn/

>Сколько раз вы ещё

Я не настолько изощрённый интриган. Вроде, после строки с "вот интересный кусок" я просто повторил свой вывод из известных мне фактов.

Надо же, как вы смогли прочитать.

Каюсь, ваше непонимание - полностью моя вина. Понятность, она полностью на ответственности говорящего.

[si14.livejournal.com]

>от высоконагруженных серверов, торчащих в веб, меня отделяет всего лишь желание этим заняться
От чего-либо работающего вообще, судя по
>нет аккаунта на гитхабе
тоже. Мне только непонятно, зачем вы пытаетесь проливать свет своего висящего в воздухе мнения на окружающих тогда, особенно всюду упираясь в «мне нравится», «я считаю» и прочее «я, мне, я, мне».

>вы обвинили автора distributed-process в отсутствии мониторов процессов, когда они там есть
>Это снова ваша фантазия[, я этого не говорил]
>Вот интересный кусок...
>Сколько раз вы ещё собираетесь... приписывать мне свои слова
>Я не настолько изощрённый интриган
Нет, конечно. Вы вполне неизощрённый мудак, не стесняющийся лгать, передёргивать и приписывать собеседнику свои слова. Обычное дело в интернете.

[thesz.livejournal.com]

>От чего-либо работающего вообще, судя по

Вы серьёзно? Аккаунт на гитхабе для вас критерий способности создать рабочий код?

>Мне только непонятно, зачем вы пытаетесь проливать свет своего висящего в воздухе мнения на окружающих тогда, особенно всюду упираясь в «мне нравится», «я считаю» и прочее «я, мне, я, мне».

Ну, здесь я пользуюсь западной этической системой, ибо она мне кажется удобной в этом случае.

>вы обвинили

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

>Нет, конечно.

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

[voidex.livejournal.com]

> Бессмысленные игры с эмуляцией зависимых типов на деньги работодателя меня не очень интересуют, простите.
Какие ж они бессмысленные, если работодатель за это платит?

[si14.livejournal.com]

Я не уверен, что это критерий. Каким-нибудь депутатам «работодатель» платит за игры в энгрибёрдс на казённом ipad'е; значит ли это, что это осмысленная деятельность? Не уверен.

[voidex.livejournal.com]

100% критерия нет.
А что тогда критерий?

[si14.livejournal.com]

Работающий продукт?

[sassa-nf.livejournal.com]

ну тогда мне нужно пересмотреть тот момент в ролике. если Erlang использует TCP и полагается на "TCP packet order" сообщений, то m2 бесследно не может пропасть - т.е. m3 "ни в жисть" не будет observed без m2.

[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 без изменения логики не представляется возможным.

[sassa-nf.livejournal.com]

в ролике речь о другом.

link p;
send p "hi!";
unlink p;
link p;
send p "bye!";
unlink p;

в каком порядке доставка "hi!" vs "bye!"? Логически два соединения разные и порядок между сообщениями этих соединений отсутствует.

[si14.livejournal.com]

Там дальше есть «решение» с wait (или как-то так). Ровно так же это решается в Erlang'е, просто один в один.