Комментарии 5
Всё хорошо, но это не стандартный синтаксис. А значит новый программист в команде не обязан это знать, а значит на это уйдет время. Если это опен сурс, то множество контрибьюторов уменьшается пропорционально сложности. Плюс т.к. это не стандартный синтаксис, и нет возможности как-то задокументировать где и как описано это поведение, то в случае «археологических раскопок древнего кода написанного на Erlang c применением parse_transform» будет непонятно что-и-где меняет поведение компилятора, и почему мы должны писать именно так а никак не иначе.
Поэтому считаю, что parse_transform не прижились в мире Erlang именно по этой причине. Elixir конечно стандартизировал это, и ввел более лаконичное описание, то несомненный плюс для языка Elixir. Но и гораздо больше возможностей выстрелить себе в ногу за счет мета-программирования.
Голосую за то, чтобы в Erlang ввести |> из Elixir.
Поэтому считаю, что parse_transform не прижились в мире Erlang именно по этой причине. Elixir конечно стандартизировал это, и ввел более лаконичное описание, то несомненный плюс для языка Elixir. Но и гораздо больше возможностей выстрелить себе в ногу за счет мета-программирования.
Голосую за то, чтобы в Erlang ввести |> из Elixir.
Erlang не хватает пайпов из Elixir, это точно
Есть подозрения, что большое количество "контрибьютеров" вредно для здоровья => https://singaporedatacompany.com/blog/more-developers-more-problems
Все бы хорошо, несмотря на «неродной» синтаксис и парстрансформы, но Erlando загнулся 4 года назад. Плюсую коммент выше — пайп был бы очень удобен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Монады в Erlang