Немного о синтаксисе Erlang

[@davidovsv]

если после выражения (например case...of...end) следует точка (,)

Опечатка?

[@serenheit]

Безусловно. Спасибо, поправил.

[@sokal32]

Хз что там люди говорят, просто обожаю синтаксис Erlang! Он намного легче воспринимается человеческим мозгом, просто людей портят всякие Java, PHP, C# и пр. гадость. Всем Erlang!)

[@mikhanoid]

Иногда вот думаешь, а, может, ну его нафиг этот синтаксис? Бросить всё и начать писать на Lisp-е. И никаких тебе проблем и мучений с форматированием. Только голая семантика. Тем более, lfe.io — (lisp (flavored (erlang))) — существует.

[@nwalker]

Он по мотивам common lisp и сейчас не умеет reader macros, то есть паттерны там выглядят просто кошмарно.

[@mikhanoid]

Насколько я разумею, всегда же можно использовать просто максросы и синтаксис поверх атомов. Но я не специалист. И мне весьма интересно, что Вы имеете в виду. Поясните, пожалуйста.

[@nwalker]

Вообще, я зачем-то смешал теплое с мягким… Влияние CL — это было скорее про verbosity имен, что я тоже не одобряю, но с этим еще моно жить.
А вот с verbosity паттернв все гораздо хуже. На данный момент описание паттернов в lfe просто чудовищно многословны и нет никакой возможности их сократить хотя бы до уровня erlang-а.

Erlang                    LFE
[H | T]                 (cons H T)
{A, B}                  (tuple a b)
<<A:5, B:A/binary>>     (binary (a (size 5)) (b binary (size a)) 

Я не уверен, что последний пример заработает, но суть, надеюсь, ясна.
То есть, если я начну писать на lfe вместо erlang, мой код точно не станет короче. Станет ли понятнее — сложный вопрос, но лично меня полноценные выражения вместо специального синтаксиса скорее отвлекают.

Вероятно, если бы была поддержка reader macro, я бы смог заменить это на какой-то компактный спецсинтаксис(да хоть бы оригинальный эрланговский), но ее сейчас нет, а что в этом случае можно поделать обычными макросами — я даже не знаю.

[@mikhanoid]

Так-то оно так, конечно. Зато такая громоздкость выражений склоняет к быстрому вводу абстракций. Например, вместо последнего, в LFE очень быстро появится нечто вроде (packet a b).

[@nwalker]

Действительно появится. Я почитал документацию, если все правильно понял — переменные нельзя реиспользовать в паттерне. Пичаль везде.

Это, конечно, хорошо, но я бы предпочел вводить абстракции, когда мне нужно, а не когда размер паттерна выходит за грань разумного. Ну и да, если бы все было так просто… Я сейчас развлекаюсь с MPEGTS, там такие упакованные структурки, что паттерн на 8 полей по binary получается запросто, и как его разинлайнить — тоже не очень понятно.

Вообще, конечно, это все bias. Мне очень хочется иметь более гибкий и изящный язык под BEAM, чем Erlang — но только язык, без дополнительных наворотов. Чтобы добавил компилятор в конфиг rebar-а, и пользуешься, смешивая его с эрлангом в любой пропорции. Два более-менее живых проекта — lfe и elixir, и ни один моим требованиям как-то не соответствует. Хоть свой лисп пиши, очень печально.

[@mikhanoid]

У меня околонулевой опыт в Lisp-ах, но уже такое ощущение, что абстракции надо просто вводить всегда и даже не задумываться: надо или не надо. Ответ всегда — надо.

Хоть свой лисп пиши, очень печально.

Почему печально? Наоборот. Окно возможностей. И задачка для магистранта-аспиранта. Вот как бы Вы отнеслись к упомянутому уже Clojure поверх Erlang VM?

[@grossws]

абстракции надо просто вводить всегда и даже не задумываться: надо или не надо. Ответ всегда — надо.

Не соглашусь по двум причинам:
— абстракции не бесплатны, как в контексте машинных (накладные расходы есть почти всегда, даже в c/c++), так и человеческих ресурсов (например, если абстракции не идеально соответствуют предметной области, то сведение к другим абстракциям требует сваливания во всё более низкоуровневый вариант и подъём до другой модели мира),
— абстракции текут (для эффективного использования абстракций приходится понимать более низкоуровневую реализацию, иначе начинается работа с абстракцией как с магическим заклинанием: как-то работает, но шаг в сторону и у исполняющего башка единорога вместо своей).

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

[@mikhanoid]

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

[@nwalker]

Не получается Сlojure поверх BEAM. Слишком много динамики в рантайме требуется, в BEAM столько нет.

[@serenheit]

Ой, какая приятная штучка. Обязательно надо поиграться.
Но если Lisp, то, имхо, уже все-таки Clojure.

[@Envek]

А рубисты помучавшись с Эрлангом (а он всё же, гад, быстр), взяли и сделали подсластитель Эликсир — всё то же самое, но на вкус привычнее :-)

[@serenheit]

Elixir и правда прикольный язык. Особенно хорошо о нем написал Джо Армстронг (я надеюсь в этом хабе все знают этого человека?) у себя в блоге. Если интересно, могу попробовать перевести и ее тоже.

[@Slavenin999]

Если интересно, могу попробовать перевести и ее тоже.

Было бы интересно почитать.