Pull to refresh

Comments 25

Так и не понял, накой тут Эликсир?! Чем сам Эрланг был бы хуже? Имхо, как раз синтаксис Элексира более громоздок — много всяких лишних «разниц». Или что под «простотой синтаксиса» понимается?

Дочитал до конца только по причине упоминания «мощного инструментария для мета-программирования». Все ждал — когда уже… но, не судьба видать. Оно поверх parse_transform работает? Или что-то свое (сильно вряд ли, конечно,… ну а вдруг).

Ну из того что лежит на поверхности — в Elixir можно определить в одном файле сколько угодно модулей, не надо отдельно выписывать экспортируемые функции, не надо ставить все эти точки и скобочки, ну и вообще, по личным ощущениям код получается компактнее и красивее. Но настоящая выгода ощущается конечно при использовании эликсировских макросов (те самые quote-unquote). Они определённым образом преобразуют AST, могут быть вложенными, рекурсивными и вообще тут работает принцип «код как данные» — макросы по синтаксису очень похожи на обычные функции, что сильно упрощает их использование
… по личным ощущениям код получается компактнее и красивее.

На вкус и цвет, как говориться… у меня от def<что-то-там>, do и end-ов всяких глазки-то повытикали сразу :-) Эрланговский, имхо, лаконичней.

Они определённым образом преобразуют AST, ...

Ну т.е. parse transformation… возможно, вид сбоку.

В любом случае, удачи вам и интерестных проектов :-)

Эликсир имеет свой компилятор из кода эликсир в AST, а из AST в AST эрланга, соответственно если и задачи у parse_transform и макро в эликсире схожие, то реализация никак не поверх parse_transform.

Если есть интерес о статье по метапрограммированию в эликсире, могу написать.
Если есть интерес о статье по метапрограммированию в эликсире, могу написать.


За себя могу сказать, что мне будет интересно только если оно чем-то принципиально отличается от parse_transform.
Было бы круто)
На самом деле возможности эликсировских макросов имхо плохо документированы, по крайней мере на официальном сайте
По-мойму, вам хорошо удалось показать, что «велосипеды» пишут не из-за императивности языков, а в следствие недостатка базовых знаний. Задача решается поиском в глубину или ширину, реализация должна уместиться в экран или около того (зависит от языка, конечно).
Хотя, я поторопился с ответом. Там не всё так просто.
Я не знаю что такое «поиск в глубину и ширину», хотя это конечно не характеризует меня с хорошей стороны. Но я хотел показать что если язык лаконичен и красив, то писать нормальные программы сможет любой, даже с большими пробелами в фундаментальных знаниях. Конечно когда набираешься некоторого опыта — понимаешь что сам язык не так уж и важен. Я просто заметил что Elixir учит меня думать более красиво. А дальше с этим умением можно будет писать нормально «хоть на php».
Я просто ошибся, прочитал задачу как «добраться конём из одной клетки в другую».
Если Вы хороший программист — плевать на каком языке писать, хоть на brainfuck (сарказм). Но если отсутствуют базовые знания — не спасет ни одна технология. И на счет книжки Страуструпа — это лихо, книга точно не для новичков. А начать следовало бы с того же Кнута — Искусство программирования, вот там учат программировать без учета языка и технологии, там учат думать. Есть ИнтУИТ в конце концов, нужно взять курс Структуры и алгоритмы обработки данных, и посмотреть, что же такое поиск в глубину и ширину.
Ой как согласен… Функциональный язык — далеко не выход из ситуации. И если не получается с C++, например, есть Java или C#, где работать с указателями не нужно и за памятью следит сборщик мусора. В любом случае, ни одна технология не спасет Вас от недостатка фундаментальных знаний. Функциональное программирование — это как другой мир, но только созданный не для того, чтобы снизить порог знаний для вхождения, а для решения своего класса задач.
Немного оффтоп, вспомнилось:
В институте преподаватель рассказывал историю, как у одной его студентки вообще не шло программирование (изучали сначала Pascal, C, C++). Когда дело дошло до курса функциональных языков — она мгновенно начала шарить, а потом подтянулась и по императивным и ОО языкам. Так что функциональный подход нужен не только для решения своего класса задач (хотя любую задачу можно решить и на императивном, и на функциональном языке), но и как другая дверь в мир программирования. Если человек «плавает» в императивных конструкциях, то у него не будет особой мотивации изучать фундамент. Но дайте ему дверь, через которую он в программирование «втянется» (неважно какую дверь, это может быть как С и Java, так и Erlang и Haskell), и тогда он уже сам поймет, что фундамент изучить надо.
Ну у меня было совсем наоборот. С императивными проблем вобще не было никогда, а вот курс по функциональному программированию как-то не пошел, плюнул и как-то пережил семестр. Прошло много лет, и вот я разработчик на Erlang, хотя также много приходится писать на C/C++. Видимо тогда был совсем не тот уровень, как когда-то не хватало уровня для программирования на С++
Обладая некоторым опытом в Erlang, хочу предостеречь от использования Elexir — мало документации, возможные ошибки при трансляции, синтаксис не поддающийся восприятию Erlang программистов, сложность получения помощи от сообщества.

Советую изучать Erlang.
Запиливая уже второй хобби-проект на Elixir, могу предостеречь от использования его в продакшене, но советую учить уже сейчас.

Документация (раз и два) вроде покрывает практически всё, что может вылезти при нормальном использовании.
Под ошибками при тансляции не очень понял что имеется в виду.
Синтаксис — гораздо ближе к мейнстримовым ЯП (Лисп, Руби), нежели к Эрлангу. Да, это означает что эрлангистам станет немного сложнее воспринимать код,. зато всем остальным немножко проще.
Насчёт сообщества — тут уже кому как везло, похоже. У меня пулл-реквесты в либы на Эрланге за пару дней рассматривают, и если отклоняют — то аргументированно в абсолютном большинстве случаев. То есть более-менее как в других сообществах.

Да, язык экспериментальный. Синтаксис периодически меняется несовместимым образом.
Но блин, mix божественен. И OTP в нём сделать правильно гораздо проще для человека не из Эрланг-тусовки.
И макросы самые мощные из всех ЯП, что я видел.
Тоже обожаю mix. Он может то что ребару и не снилось)
В статье не стал расписывать mix, OTP и макросы, дабы не перегружать. Хотя мне кажется надо бы про них написать подробнее, ведь в них самый сок
Ну может и не emacs, но однозначно плюсую Erlang. я использую Idea с соответствующим плагином
Использовал Idea для Erlang. Классная штука. Понравилось что слева наглядно показываются места где функции входят в рекурсию, ну и автодополнение очень крутое, для Elixir конечно пока такого нет
Обладая опытом 3 лет профессиональной разработки на эрланге, и как минимум 1,5 годовым опытом использования эликсира, могу опровергнуть ещё одно утверждение(о документации уже опровергли).

«сложность получения помощи от сообщества»
Могу сказать о моём опыте: более отзывчивого сообщества я ещё пока не встречал, когда у меня была какая-то проблема, то в тот же день(или даже час) вместе с Jose Valim находил её причину и он исправлял на мастере эликсира, когда нам нужны были maps-ы ещё за 3 месяца до их официального релиза в эрланге — мы уже начали встраивать их в эликсир — по сути из-за того, что они нужны были мне в одном экспериментальном проекте на фирме.
На самом деле эликсир — это калька с руби. И это очень хорошо!
После прочтения книжки по эрлангу так за эрланг и не взялся, зато стал писать на рубях в стиле эрланга типа head|tail, и думать тоже. Короче, полезная штука. А эликсир дает шанс когда-нибудь начать использовать эрланг рубистам.
На самом деле, и да и нет.
То есть синтаксис похож на рубёвый, не даром Хосе Валим один из основных контрибьюторов в Рельсы.

С другой стороны, язык это гораздо больше чем синтаксис. И с этой стороны Эликсир заметно ближе к современным Лиспам, чем к Руби. (Гомоиконность, гигиеничные макросы, вот этот вот весь ворох фич.)
Only those users with full accounts are able to leave comments. Log in, please.