Корректность, типизация и Erlang
В последнее время все чаще встречаю упоминания об использовании Erlang на просторах ex-USSR.
Судя по всему, возрастающее применение Erlang оправдывается достаточно большим количеством success stories. К тому же Erlang поддерживается не только группой исследователей и community, как это происходит с Haskell и OCaml, но и такой немаленькой фирмой, как Ericsson. Это позволяет легче убедить менеджмент в пригодности Эрланга для серьезной разработки.
Но, как и в предыдущем посте, я хочу поговорить о корректности программ.
С Эрлангом наблюдается очень забавная картина: с одной стороны он предназначен для написания fault-tolerant программ и обладает замечательной runtime системой, хорошо подходящей для написания распределенных пуленепробиваемых non-stop приложений. С другой стороны — это язык с динамической типзацией, что, по моему мнению, противоречит написанию корректных программ.
Как можно написать корректную программу, если язык позволяет допустить практически любую опечатку? А как я поправлю ВСЕ места, где использовался модуль, принцип работы которого я только что поменял? Возможно, у Эриксон и есть столько денег на тестеров, но что делать более экономным людям?
А вы подумали о времени и нервах, потраченных на поиск несчастной опечатки? Конечно, в Эрланге пытаются поправить существующее положение: создана специальная тулза dialyzer. Однако, никакие тулзы не заменят полностью качественной, теоретически обоснованной, статической типизации.
Думается мне, что если бы не некоторые из старых методологий, изначально заложенных в Эрланг, то он никогда бы не стал языком для пуленепробиваемых систем.
Короче, если вы никогда не опечатываетесь, никогда не редактируете большие программы, пишете юнит-тесты для всех функций в системе, и, самое главное, вам не лень делать работу, которую можно автоматизировать, то Эрланг, лисп, питон, перл, tcl, lua — это все для вас. Я завидую вашему кунг-фу :)
PS: Ни в коем случае не хочу сказать, что эрланг — плохая платформа. Если ваша программа на 90% состоит из сетевого трафика, то, возможно, Эрланг вам и подходит. Но вот как язык...
PPS: Еще одна, несколько другая, жалоба на отсутствие статической типизации в Эрланге.
8 комментариев:
В common lisp есть типизация.
Конечно там есть типизация. Динамическая :)
Всякие
(declare (type fixnum foo-bar))
не в счет. Они служат для оптимизации специфичных участков кода и, если ничего не путаю, даже не обязательно проверяются.
Конечно, сама система типов у common lisp побогаче, чем у erlang. Хотя... Алгебраических типов данных все равно нет :). И хотя они там легко делаются, без статической типизации в лиспе работать с ними практически невозможно. pattern matching не отладишь никогда (из-за этого, в свое время, полностью отказался от лиспа).
Ну Erlang же очень распределенный, соответственно сложно статически проверить корректность посылки сообщений (типов там итп), поэтому толку от статической типизации маловато будет.
Ну и в случае питона и др., бесспорный плюс динамической типизации, вызовов методов через посылку сообщений, duck typing -- слабое связывание компонентов системы.
Щас вот книжку читаю про питоновый веб-фреймворк django, там вот например если в шаблоне страницы неопределенная переменная используется, эксепшен не кидается, а вместо нее вставляется ''. И ребята объясняют, что это специально -- в большинстве случаев пусть лучше юзер увидит не совсем правильную страничку чем Internal Server Error. Таким образом засчет динамической типизации приложение получается существенно более "непотопляемым" :)
Ну Erlang же очень распределенный, соответственно сложно статически проверить корректность посылки сообщений (типов там итп), поэтому толку от статической типизации маловато будет.
Не уверен, что очень сложно проверить.
Ну и в случае питона и др., бесспорный плюс динамической типизации, вызовов методов через посылку сообщений, duck typing -- слабое связывание компонентов системы.
Ну да, это можно и структурным полиморфизмом на окемле или даже темплейтами на С++. Другое дело, что это не в рантайме. Но связывание в рантайме и так слишком опасно, чтобы его юзать.
...И ребята объясняют, что это специально -- в большинстве случаев пусть лучше юзер увидит не совсем правильную страничку чем Internal Server Error.
Я все-таки считаю, что лучше разработчик сразу увидит, что облажался, чем юзер потом.
С другой стороны — это язык с динамической типзацией, что, по моему мнению, противоречит написанию корректных программ.
На мой взгляд, противоречия нет. Если не лениться, и везде где тип существенен писать "охраны", то dialyser нормально проверит типизацию.
То есть Erlang динамически типизован, но "типобезопасен".
На мой взгляд, противоречия нет. Если не лениться, и везде где тип существенен писать "охраны", то dialyser нормально проверит типизацию.
В том то все и дело, что лениво писать типы. И необязательно это. А человек — такое существо, что если чего-то можно не делать, то это обязательно будет не сделано.
То есть Erlang динамически типизован, но "типобезопасен".
К сожалению, только при условии дополнительной ручной работы.
Типобезопасность гаранитируется рантаймом, никакой ручной работы, но ошибка прогера сгенерирует рантайм-ошибку, умрёт один процесс, система останется жить, а не упадёт с BSOD, модуль можно будет тут же проапдейтить и вуаля...
Что-то мне не хочется тут же в 3 часа ночи апдейтить упавший модуль, который мог вообще не упасть.
Разницы между BSOD и падением из-за рантайм ошибки никакой нет. Программа (или ее часть) все равно не работает.
Отправить комментарий