Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
если после выражения (например case...of...end) следует точка (,)
Опечатка?
Хз что там люди говорят, просто обожаю синтаксис Erlang! Он намного легче воспринимается человеческим мозгом, просто людей портят всякие Java, PHP, C# и пр. гадость. Всем Erlang!)
Иногда вот думаешь, а, может, ну его нафиг этот синтаксис? Бросить всё и начать писать на Lisp-е. И никаких тебе проблем и мучений с форматированием. Только голая семантика. Тем более, lfe.io — (lisp (flavored (erlang))) — существует.
Он по мотивам common lisp и сейчас не умеет reader macros, то есть паттерны там выглядят просто кошмарно.
Насколько я разумею, всегда же можно использовать просто максросы и синтаксис поверх атомов. Но я не специалист. И мне весьма интересно, что Вы имеете в виду. Поясните, пожалуйста.
Вообще, я зачем-то смешал теплое с мягким… Влияние CL — это было скорее про verbosity имен, что я тоже не одобряю, но с этим еще моно жить.
А вот с verbosity паттернв все гораздо хуже. На данный момент описание паттернов в lfe просто чудовищно многословны и нет никакой возможности их сократить хотя бы до уровня erlang-а.
Я не уверен, что последний пример заработает, но суть, надеюсь, ясна.
То есть, если я начну писать на lfe вместо erlang, мой код точно не станет короче. Станет ли понятнее — сложный вопрос, но лично меня полноценные выражения вместо специального синтаксиса скорее отвлекают.
Вероятно, если бы была поддержка reader macro, я бы смог заменить это на какой-то компактный спецсинтаксис(да хоть бы оригинальный эрланговский), но ее сейчас нет, а что в этом случае можно поделать обычными макросами — я даже не знаю.
А вот с 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, я бы смог заменить это на какой-то компактный спецсинтаксис(да хоть бы оригинальный эрланговский), но ее сейчас нет, а что в этом случае можно поделать обычными макросами — я даже не знаю.
Так-то оно так, конечно. Зато такая громоздкость выражений склоняет к быстрому вводу абстракций. Например, вместо последнего, в LFE очень быстро появится нечто вроде (packet a b).
Действительно появится. Я почитал документацию, если все правильно понял — переменные нельзя реиспользовать в паттерне. Пичаль везде.
Это, конечно, хорошо, но я бы предпочел вводить абстракции, когда мне нужно, а не когда размер паттерна выходит за грань разумного. Ну и да, если бы все было так просто… Я сейчас развлекаюсь с MPEGTS, там такие упакованные структурки, что паттерн на 8 полей по binary получается запросто, и как его разинлайнить — тоже не очень понятно.
Вообще, конечно, это все bias. Мне очень хочется иметь более гибкий и изящный язык под BEAM, чем Erlang — но только язык, без дополнительных наворотов. Чтобы добавил компилятор в конфиг rebar-а, и пользуешься, смешивая его с эрлангом в любой пропорции. Два более-менее живых проекта — lfe и elixir, и ни один моим требованиям как-то не соответствует. Хоть свой лисп пиши, очень печально.
Это, конечно, хорошо, но я бы предпочел вводить абстракции, когда мне нужно, а не когда размер паттерна выходит за грань разумного. Ну и да, если бы все было так просто… Я сейчас развлекаюсь с MPEGTS, там такие упакованные структурки, что паттерн на 8 полей по binary получается запросто, и как его разинлайнить — тоже не очень понятно.
Вообще, конечно, это все bias. Мне очень хочется иметь более гибкий и изящный язык под BEAM, чем Erlang — но только язык, без дополнительных наворотов. Чтобы добавил компилятор в конфиг rebar-а, и пользуешься, смешивая его с эрлангом в любой пропорции. Два более-менее живых проекта — lfe и elixir, и ни один моим требованиям как-то не соответствует. Хоть свой лисп пиши, очень печально.
У меня околонулевой опыт в Lisp-ах, но уже такое ощущение, что абстракции надо просто вводить всегда и даже не задумываться: надо или не надо. Ответ всегда — надо.
Хоть свой лисп пиши, очень печально.
Почему печально? Наоборот. Окно возможностей. И задачка для магистранта-аспиранта. Вот как бы Вы отнеслись к упомянутому уже Clojure поверх Erlang VM?
Хоть свой лисп пиши, очень печально.
Почему печально? Наоборот. Окно возможностей. И задачка для магистранта-аспиранта. Вот как бы Вы отнеслись к упомянутому уже Clojure поверх Erlang VM?
абстракции надо просто вводить всегда и даже не задумываться: надо или не надо. Ответ всегда — надо.Не соглашусь по двум причинам:
— абстракции не бесплатны, как в контексте машинных (накладные расходы есть почти всегда, даже в c/c++), так и человеческих ресурсов (например, если абстракции не идеально соответствуют предметной области, то сведение к другим абстракциям требует сваливания во всё более низкоуровневый вариант и подъём до другой модели мира),
— абстракции текут (для эффективного использования абстракций приходится понимать более низкоуровневую реализацию, иначе начинается работа с абстракцией как с магическим заклинанием: как-то работает, но шаг в сторону и у исполняющего башка единорога вместо своей).
Максимализм в любой области вреден. Переформулируя выражение, приписываемое товарищу Однокамушкину, абстракции надо вводить тогда, когда это необходимо, но не раньше.
В Lisp есть макросы, которые позволяют без накладных расходов применять абстракции. Ну, и просто сам язык такой: если возникает желание абстрагировать, то, скорее всего, пора её вводить. Это как с переменными в более привычных языках: если есть ощущение, что хочется переменную, видимо, пора её делать.
Не получается Сlojure поверх BEAM. Слишком много динамики в рантайме требуется, в BEAM столько нет.
Ой, какая приятная штучка. Обязательно надо поиграться.
Но если Lisp, то, имхо, уже все-таки Clojure.
Но если Lisp, то, имхо, уже все-таки Clojure.
А рубисты помучавшись с Эрлангом (а он всё же, гад, быстр), взяли и сделали подсластитель Эликсир — всё то же самое, но на вкус привычнее :-)
Elixir и правда прикольный язык. Особенно хорошо о нем написал Джо Армстронг (я надеюсь в этом хабе все знают этого человека?) у себя в блоге. Если интересно, могу попробовать перевести и ее тоже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного о синтаксисе Erlang