Комментарии 83
... наличии у разработчиков неясности в вопросе выгоды от его применения.
Самое важное, имхо. Жозе в 11'ом не мог внятно ответить на вопрос "зайчем?". Даже когда его прямо спрашивали про "efene" и прочие "erlog"'и. Но тогда хоть можно было списать на "молодой/горячий".
Прошло больше десяти лет - как я понимаю - мало что поменялось с тех времен :-)
Т.е. "чем лучше", какой-нибудь - условный - haskerl/hamler - понять я способен... да даже "чем лучше" разные ML-диалекты, живущие на beam.
Но "чем лучше" elixir - лично я, например - понять не способен :-( Лично для меня это как была "поделка уровня efene", так и осталась.
«чем лучше» elixir — лично я, например — понять не способен
Метапрограммированием, аналогов которому нет ни в одном языке даже близко. Джо Армстронг в свое время, увидев quote/ unquote — сказал «это очень круто, нам нужно такое в эрланге». Но это было буквально за полгода до смерти, к сожалению.
Выставленным наружу родным AST, не прикрученным сбоку со всеми вытекающими несуразностями, как в расте, например. LISP все равно останется доминантой на этом поле, Вирдинг вон пилит свой LFE — но это для команды рядовых программистов современности слишком сложно; эликсир же позволяет возиться с AST где надо — тем, кому оно надо. В го даже смешно этого ожидать, в расте — как я оговорился — оно прикручено сбоку и попросту омерзительно.
Возможностью создавать собственные компиляторы, которые будут нативно вызваны в процессе сборки проекта (например, в одной из моих библиотек я компилирую диаграммы состояний в синтаксисах mermaid/plantuml — в код процесса FSM).
Экосистемой, в которой просто приятно жить, от коммьюнити до инстументария.
Всеми преимуществами OTP, нативно доступными из кода на эликсире.
Я не стану советовать переходить на эликсир с эрланга (хотя лично я из-за одного метапрограммирования перешел бы еще сто раз, не задумываясь). Но поделия наподобие ML-диалектов — оставьте студентам.
Ну и, наконец, скоростью написания рабочего пуленепробиваемого кода. Процентов 80 моих библиотек на любом другом языке я бы писал вдвое–впятеро дольше, а как тестировать — зачастую вообще неясно.
Спасибо за актуализацию темы о метапрограммировании Elixir. Это здорово, что есть тонкие ценители.
Собирался написать статью на эту тему. Не о том, как это здорово, а о том, что лично меня поразило.
Ну вот тут человек заморочился сделать conprehension для Stream, с таким точно синтаксисом, как forдля жадных коллекций: https://github.com/am-kantox/lazy_for/blob/v1.1.0/lib/lazy_for.ex#L1
Вот это настоящее метапрограммирование, это я понимаю.
Я собираюсь сделать язык описания направленного графа. Или вариант - читать модифицированный Dot. Может быть, как-то совместить.
Для этого вам не потребуется метапрограммирование. Если не хватает паттерн-матчинга в корке, посмотрите на https://hexdocs.pm/nimble_parsec/NimbleParsec.html от Жозе.
Метапрограммированием, аналогов которому нет ни в одном языке даже близко.
Даже не смешно. Квазицитирование LISP вы упомянули сами. А в Erlang - например - есть parse transform. Я хз "полечили" ли уже в Elexir его "танцы" с композицией макросов, но прикол в том, что в parse tranform такого рода "танцев" нет в принципе. "Программа, которая пишет программу, которая пишет программу, которая захватывает мир" - это и про erlang тож. Так что не надо нам тут за "метапрограммирование" :-)
Джо Армстронг в свое время, увидев quote/ unquote — сказал «это очень круто, нам нужно такое в эрланге». Но это было буквально за полгода до смерти, к сожалению.
Если я правильно понимаю, о чём речь, то "увидел" он их году так в 2013ом (если мне мой склероз не изменяет). И сказал совсем не это :-) Грубо говоря (хотя можно и поискать цитаты, если сильно надо), по его мнению, наличие механизма квазицитирования сделало бы parse transform более "right thing". О чём даже была дискуссия, в рамках которой было установлено что дело не в "наличие отсутствия" quote/unquote. Дело - если "на пальцах" - в возможности описывать такого рода трансформации, что называется, "по месту". Но, является ли это действительно "more right" так и не было установлено. Выглядит оно действительно привлекательно, но ведёт к весьма очевидным "приседаниям" с гигиеной и композицией.
И если уж говорить "вообще" за "Джо Армстронг и Elexir", то хвалил он (а он таки хвалил) Elexir не за его "метапрограммирование".
Выставленным наружу родным AST, не прикрученным сбоку со всеми вытекающими несуразностями, как в расте, например. LISP все равно останется доминантой на этом поле, Вирдинг вон пилит свой LFE — но это для команды рядовых программистов современности слишком сложно; эликсир же позволяет возиться с AST где надо — тем, кому оно надо. В го даже смешно этого ожидать, в расте — как я оговорился — оно прикручено сбоку и попросту омерзительно.
Не совсем понятно причет тут "rust"... но если говорить о "выставленным наружу родном AST" и о механизмах (штатных, причем) работы с ним, то parse tranform если и уступает в чём-то квазицитатам LISP'а, то только в "элегантности". Всё-таки "макрос" в erlang это отдельный модуль, со всеми вытекающими.
Возможностью создавать собственные компиляторы, которые будут нативно вызваны в процессе сборки проекта (например, в одной из моих библиотек я компилирую диаграммы состояний в синтаксисах mermaid/plantuml — в код процесса FSM).
Ещё раз... вы вообще в курсе наличия в erlang такого механизма как parse tranform? Судя по всему - нет. Для erlang вполне обыденно делать "такое". Это штатный - повторюсь - механизм.
Я не стану советовать переходить на эликсир с эрланга (хотя лично я из-за одного метапрограммирования перешел бы еще сто раз, не задумываясь).
Ну вы просто - насколько я понимаю - не в курсе про возможности метапрограммирования в erlang :-)
Видите ли, судя по тому, что вы везде пихаете parse_transform, есть два варианта: либо я не понимаю, что такое parse_transform, либо вы не понимаете, чем от него отличается quote/unquote.
Так вот, я в курсе, что такое parse_transform.
С ним все в порядке, в принципе, да вот беда: он вызывается после парсинга в синтаксическое дерево. На полном AST файла. Что приводит к громадному количеству бойлерплейта, но это бы еще и ладно. Парсер сломается на невалидном эрланге, и до парстрансформа дело попросту не дойдет — вот настоящая беда. Все переменные времени компиляции — тоже растеряются. Результат для стороннего читателя кода — окажется попросту непредсказуемым. Разворачивать макросы во время компиляции — это вообще не то же самое, что скормить получившееся AST стороннему модулю. Вообще.
И да, механизм штатный, вот только настолько громоздкий, что приходится триста раз подумать, прежде чем его расчехлять. И это говорю я, который 100% времени пишет библиотечный код на макросах. Даже мне лень лопатить весь код модуля, чтобы поменять пару вызовов (а если модуль чужой и непредсказуемый — там защитного кода будет в тысячу раз больше функционального).
Ну а обычные макросы в эрланге — слишком тупые, чтобы их можно было использовать для метапрограммирования.
Так что прежде чем ставить диагнозы по юзерпику, рекомендую разобраться в теме, а то пока все аргументы выглядят в точности, как причины луддита не использовать ткацкий станок вместо иглы и наперстка. И убогие смайлики тут не помогут.
Еще раз: я люблю эрланг, много на нем пишу, и знаю про большинство его возможностей. Но предпочитаю — эликсир. И выше расписал, почему, отвечая на ваш недозаданный вопрос, между прочим. Тыкать в ответ одним редкоиспользуемым даже в коммьюнити инструментом, о котором известно каждому третьекласснику — ну так себе манера дискуссии. На троечку.
Так вот, я в курсе, что такое parse_transform.
Зачем тогда загонять про "метапрограммированием, аналогов которому нет ни в одном языке даже близко"?!
С ним все в порядке, в принципе, да вот беда: он вызывается после парсинга в синтаксическое дерево. На полном AST файла. Что приводит к громадному количеству бойлерплейта ...
Ну мы можем, конечно, возобновить дискуссию по поводу "насколько локальность такого рода трансформаций more right thing"... только смысл?! В прошлый раз (как раз когда Армстронг опубликовал свое "неделя с элексиром"), если мне не изменяет мой склероз, всё закончилось тем, что "да, заманчиво, но вот как быть с" и ниже "списочек". Специально вот сейчас заглянул на elixirforum - как я понимаю, вопросы с "правильной" композицией "макросов" до сих пор "будоражат умы". Там уже такие "костыли со стразиками" рисуются, что реально не знаешь плакать или смеяться.
Т.е. - лично для меня - это выглядит так, что то, о чём предупреждали десять лет назад, сбывается с "пугающей точностью", как говориться.
А по поводу "бойлерплейта"... ну если каждый раз всё делать "с нуля" и "ручками", то таки да - "а что вы хочите?!". И если вы таки знаете за parse_transform, то зачем делать "с нуля"?! Какой-нибудь parse_trans, например, написан Ульфом уж точно больше десяти лет назад. И до сих пор жив и развивается. Емнип, даже на github'е с некоторых пор лежит. Т.е. для того, чтоб "всё писать с нуля" таки должны веские основания. Так что - в реальности - "бойлерплейта" там, скажем так, в меру. Не так чтобы вообще без... но "всё по делу".
... но это бы еще и ладно. Парсер сломается на невалидном эрланге, и до парстрансформа дело попросту не дойдет — вот настоящая беда.
?! Можно подумать что в quote можно любую "чушь" пихать :-) Естественно, модуль, который подвергается трансформации должен быть синтаксически корректным.
Все переменные времени компиляции — тоже растеряются.
С чего бы?!
Результат для стороннего читателя кода — окажется попросту непредсказуемым.
Ну да, ну да. Сразу вспомнил как увидел первые попытки нарисовать элементарный traceable на "тех самых макросах". "Воспоминание разблокировано", как говориться :-)
Разворачивать макросы во время компиляции — это вообще не то же самое, что скормить получившееся AST стороннему модулю. Вообще.
?! И то ("разворачивание макросов elixir" ), и другое (erlang parse_transorm) - происходит на одном и том же этапе компиляции. Вся разница в "локальности"... в "объеме контекста", если хотите.
И да, механизм штатный, вот только настолько громоздкий, что приходится триста раз подумать, прежде чем его расчехлять.
Как бы в том, чтоб "триста раз подумать" нет ничего плохого, как мне кажется. А по поводу "громоздкости" - тут на вкус и цвет. Он полностью прозрачен, логичен, лаконичен и внутренне не противоречив :-)
Ну а обычные макросы в эрланге — слишком тупые, чтобы их можно было использовать для метапрограммирования.
Про препроцессор эрланга я вообще ничего не говорил. Он к метапрограммированию не относится вообще никак.
Так что прежде чем ставить диагнозы по юзерпику, рекомендую разобраться в теме ...
В какой теме вы мне "рекомендуете разобраться"? :-) Всеж просто - вы, в "зачем нужен elixir" на первое место поставили "метапрограммирование, аналогов которому нет ...". Упомянули, например, квазицитирование LISP, кучу всего ещё, вспомнили Джо, который типа "хвалил за quote/unquote"... но - почему-то - не вспомнили о parse_transform erlang'а. Это как?!
Для меня это выглядит так, что вы либо не знаете, что он есть, либо не считаете его "метапрограммированием".
Я лишь отвечал на ваш - сугубо не верный, с моей точки зрения - посыл. Эрланговский parse_transofrm - именно как инструмент метапрограмирования - лично с моей точки зрения (да и не только с моей), тут далеко впереди "макросов", которые - опять же, по моему личному мнению. - вполне имеют свою нишу... они хороши, например, как инструмент для создания различного рода "embedded DSL". По крайней мере, тут их "локальность" имеет смысл быть.
А называть "embedded DSL" метапрограммированием, да ещё и "аналогов которому нет" - это "такое", имхо.
Вот и всё.
Тыкать в ответ одним редкоиспользуемым даже в коммьюнити инструментом, о котором известно каждому третьекласснику — ну так себе манера дискуссии.
По поводу, "редко"/"часто"-используемый он... уж не знаю, про какое "коммьюнити" вы тут утверждаете... нормально он используемый :-) Именно на уровне библиотечного кода - вполне себе.
По пунктам.
У слова «аналог» есть словарное значение.
parse_transformне является аналогом макросов эликсира ни в коей мере. Вы бы еще патчинг байткода джавы с помощью сторонних утилит упомянули.parse_transformидеален для некоторых задач, он безусловно является отличным инструментом метапрограммирования, но — повторюсь — аналогом его назвать нельзя. Вот и все.«вопросы с „правильной“ композицией „макросов“ до сих пор „будоражат умы“» — это детский сад. Понятия не имею, куда вы там заглядывали на форуме, вы бы еще на квору заглянули. Я десять лет использую макросы каждый день и мой ум холоден, как темперамент Крупской. Макросы просто работают. С их композицией нет никаких проблем вообще. Покажите проблему — я объясню, что вы делаете не так, и как надо.
Сначала вы говорите «
parse_transform, штатный инструмент», а когда я в ответ заикаюсь про несуразный бойлерплейт, выясняется, что вы имели в виду сторонние библиотеки. Да, я знаю проparse_trans. Нет, он не решает моих проблем тоже.В
quoteнельзя пихать «любую чушь», но невалидный эликсир с правильным синтаксическим деревом — можно. Более того, любая чушь может быть запихана вunquote, если это правильное синтаксическое дерево. Сие дает внештатную редкоиспользуемую возможность протащить доunquoteсовсем уж невалидный эликсир и по месту его преобразовать в валидный. До вызоваunquoteтам может быть что угодно. Например, макрос запросто может принимать на вход спеку наподобиеboolean() | integer(). И да, это часто востребовано в библиотечном коде, который я пишу.
С вашей точки зрения parse_transform, с прикрученной сверху библиотекой, вынужденный обрабатывать всё синтаксическое дерево модуля — аналог макросов эликсира. Данное утверждение означает, что про макросы эликсира вы знаете понаслышке. Он, с некоторой натяжкой, является аналогом хука времени компиляции before_compile/2.
Если покажете хоть одну библиотеку, в которой parse_transform используется для пост-обработки чужих модулей — буду максимально признателен; я как-то искал такой пример для коллег, но сдулся часу на третьем.
P. S. Вы бы спеллчекером обзавелись, что ли, а то ведь глаза вытекают.
У слова «аналог» есть словарное значение...
Мы - судя по всему - "уходим на второй круг"...
Я нигде не называл parse_transform аналогом макросов. И мне странно, что вы так с чего-то решили.
Речь вообще-то - всего лишь - о том, что вы утверждаете наличие в elixir некого "метапрограммирования, аналогов которому нет ни в одном языке даже близко" (tm), а я вам пытаюсь показать, что с именно метапрограммированием в erlang очень даже.
Единственны момент, который - имхо - хоть как-то можно притянуть за "аналогичность" parse_transform erlang'а макросам elixir'а - это ваши возгласы про "это другое", и мои попытки указать вам, что оно "не настолько уж другое", что это уже не раз обсуждалось, и т.п.
Макросы просто работают. С их композицией нет никаких проблем вообще.
Ну если вы считаете что они "просто работаю" и "с композицией нет никаких проблем вообще" - я рад за вас.
А я вот помню, например, весьма старую статью на эрлангисте, где разбирали traceable на elixir. И зайдя вчера на elixirforum, первое что я вижу, вбив macros в поиск - вопрос от мая текущего года, где человек тыкает в эту статью с "а у меня вот вопрос" - и дальше пару экранов текста. А Жозе ему на полном серьезе отвечает, забей: "... define a macro that stores AST in module attributes and injects them during in a @before_compile".
Для меня - это прям весьма показательно, что с композицией макросов "всё прям отлично".
Покажите проблему — я объясню, что вы делаете не так, и как надо.
Да я понимаю, "как нада". Выше, вон, написано :-)
Сначала вы говорите «parse_transform, штатный инструмент», а когда я в ответ заикаюсь про несуразный бойлерплейт, выясняется, что вы имели в виду сторонние библиотеки. Да, я знаю про parse_trans.
Вы опять заставляется меня сомневаться в том, что "вы знаете".
parse_transform - это действительно механизм. Это не библиотека, не код - если хотите. Это вот - буквально - "флажок компилятора".
И в чем проблема в том, чтобы использовать "сторонние библиотеки"?! Ну не хотите - не используйте... пишете весь разбор AST и т.п. "ручками". Я вам лишь указывал на то, что для "ручками" должны быть веские причины, ибо практически весь ваш "бойлерплейт" написан уже давно.
Нет, он не решает моих проблем тоже.
Мог бы процитировать вас же... но - промолчу :-)
В quote нельзя пихать «любую чушь», но невалидный эликсир с правильным синтаксическим деревом — можно.
Ну дык и для работы parse_transform - требуется только синтаксическая корректность. В чем проблема-то?!
С вашей точки зрения parse_transform, с прикрученной сверху библиотекой, вынужденный обрабатывать всё синтаксическое дерево модуля — аналог макросов эликсира.
?! С чего вы так решили-то? Где я вас пытался убедить, что PT аналогичен "макросам"?
parse_transform - это штатный инструмент метапрограммирования в ernalg. Того самого "метапрограммирования" - по вашим же словам - "аналогов которому нет ни в одном языке даже близко". Я вам лишь указываю, что вот: и язык, и метапрограммирование на этом же языке. Если хотите - можем подискутировать о том, какое из них более "мета". Но, лично я, особого смысла в этом не вижу. Мне вполне достаточно старых фидбэков от traceble, и того знания, что за десяток лет никуда "оно" не делось.
Если покажете хоть одну библиотеку, в которой parse_transform используется для пост-обработки чужих модулей — буду максимально признателен ...
А что есть "пост-обработка", в вашем понимании? Так-то, мне обратное как раз представить сложно. В том смысле, что трансформация AST - это всегда внешний, по отношению к текущему, модуль. Так что любой модуль, указанный в parse_transform - обрабатывает как раз "чужие модули".
P. S. Вы бы спеллчекером обзавелись, что ли, а то ведь глаза вытекают.
И вам - не хворать
— метапрограммирования, аналогов которому нет ни в одном языке даже близко
— есть
parse_transform
Я, вроде бы, тоже нигде не утверждал, что в других языках нет метапрограммирования. Я утверждал, что нет аналогов. Вы сами трижды повторили, что не считаете parse_transform аналогом. Мне больше нравятся макросы эликсира, потому что я в них умею (и в parse_transform тоже умею, и в некоторых местах, где уместно, использую). Вам больше нравится parse_transform — тоже прекрасно. Аналогов метапрограммирования как в эликсире (при помощи макросов) — в эрланге (как и в любом другом языке из примерно тридцати мне известных) — нет. Неясно, если честно, что тут может быть непонятно.
А Жозе ему на полном серьезе отвечает […]
Я не поленился найти ссылку. И не поленился прочитать вопрос: как мимикрировать под реализацию def/2 макроса, сиречь не разворачивать его по месту. Это, конечно, прям ежедневная задача каждого разработчика: обойти хаком дефолтное поведение. И конечно, есть миллиард других способов, но самый простой — ваш любимый парстрансформ: вставить AST после его парсинга. Но тут парстрансформ почему-то вызывает у вас смех. Бывает. Или в эрланге не AST придется в PT вставлять? Почему там это — круто, а тут — нет?
Для меня — это прям весьма показательно, что с композицией макросов «всё прям отлично».
Причем тут композиция вообще? Человеку нужен хак, позволяющий обойти механизм обработки макросов в языке. Какая нахрен композиция? Вы вообще у курсе, что такое композиция?
И вообще, вам человек, собаку на макросах съевший, говорит, что все отлично — вы в ответ откапываете какой-то вопрос на форуме, проглядываете его по диагонали, не понимаете, что спрашивается, и на основе этого строите своё мировоззрение. Вот это — показательно, это да.
Так что любой модуль, указанный в
parse_transform— обрабатывает как раз «чужие модули».
Угу, я в курсе. Чужой — в смысле непредсказуемый. Не свои соседние три с половиной модуля, которые подработаны напильником, чтобы пройти указанный PT, а какой угодно валидный, но очень хитровыкрученный. Ну и трансформ чтобы там все case нашел и аннотировал.
Неясно, если честно, что тут может быть непонятно.
Теперь - всё понятно.
Я не поленился найти ссылку. И не поленился прочитать вопрос ...
Отлично! Вам - как я понимаю - осталось найти "с чего всё начиналось". Топикстартер же не просто так пришёл - типа "хочу такой хак". Правда ведь? Он даже, вон, ссылочку не забыл прицепить... цитат, вот, со статьи надергал. Не просто так, наверное. Нет?
Человеку нужен хак, позволяющий обойти механизм обработки макросов в языке.
А вы подумайте, зачем - спустя больше десяти лет - ему всё ещё таки нужен этот хак?
Вы вообще у курсе, что такое композиция?
Спасибо, я "у курсе" :-)
И вообще, вам человек, собаку на макросах съевший, говорит ...
Мне не надо "говорить". Я вполне способен заглянуть в код и увидеть насколько всё "отлично".
Чужой — в смысле непредсказуемый. Не свои соседние три с половиной модуля, которые подработаны напильником ...
Блин... ну гляньте qlc какой-нибудь, или eunit (там авто экспорт, емнип, на PT сделан). Это из того, что в otp входит. lagger - какой-нибудь из стороннего. Это то, что прям сразу в голову приходит.
А вы подумайте, зачем — спустя больше десяти лет — ему всё ещё таки нужен этот хак?
Конкретно ему — чтобы понять написанное Юричем. Но это не главное: мы либо разворачиваем AST по месту (и тогда оно выполнится согласно дизайну, который я считаю правильным), либо отдаем всё пост-процессору, про который Джо сказал «done wrong». Плюсы обоих решений совместить не удастся, это не значит, что есть какие-то проблемы «с композицией». Это значит, что вам лично такой дизайн не нравится. Бывает.
Я вполне способен заглянуть в код и увидеть насколько всё «отлично».
Да-да, конечно.
eunit
Тьфу, блин, точно, спасибо.
... это не значит, что есть какие-то проблемы «с композицией»
Не-не-не... в конечном счёте, это как раз это и значит. Точнее, в том числе, и это.
Начинается там всё с того, что "композиция" (точнее, то, что, порой, так называют в elixir) макросов - её результат - не есть макрос. Ну и дальше оно одно за другое, и приводит к вот таким вот "штукам".
Означает ли это, что "макросы в elixir" какие-то плохие? Нет. Вообще - нет.
Означает ли это, что отличная (а так и есть) макросистема elixir - плохой (или, скорее, не удачный) инструмент (способ, если хотите) метапрограммирования - с моей точки зрения, таки да.
Т.е. пока "некоторые вещи" не сильно важны - ну например, мы делаем какой-то "embedded DSL" а-ля ecto queries, например - т.е. вещи, которые слабо (или вообще не) зависят от контекста - то всё не просто хорошо, всё - замечательно. Нас вполне устраивает "локальность", нам вполне достаточно такой "композиции" и т.п. Но - я это уже говорил - называть "это" метапрограмированием, с моей точки зрения, это "такое".
И это становится сразу видно, например, когда "локальность" начинает мешать, когда важен становится контекст (и глобальный) и т.п. - т.е. когда дело таки доходит до "программа, которая пишет программу ..." - что, собственно, и есть метапрограммирование. А т.к. в рамках самой макросистемы (отличной, ещё раз повторю) elixir эти "ограничения" не снимаются в принципе, то приходится искать "обходные пути". Без относительно того, как они "done".
Собственно, всё что хотел сказать - сказал :-) No offence, "респетк", "ужавение" и всё такое.
Нет, не приходится, потому что существует хук before_compile/2, в качестве кувалды — который, повторюсь в третий раз, — и есть тот самый parse_transform.
Макросы — это тот самый единственный инструмент, который позволил создать эликсир как таковой. def/2, defmodule/2, даже defmacro/2 — это макросы. Everything is a macro.
No offence, "респетк", "ужавение" и всё такое.
Да ладно, право слово, отлично и интересно пообщались, какой нафиг оффенс.
Ну и в завершение.
defmacro quote and unquote
Love 'em. This is parse transforms done right.
— https://joearms.github.io/published/2013-05-31-a-week-with-elixir.html
Действительно, 2013. У меня наложилось на мою длительную дискуссию с Джо в конце 2018, когда я на примерах доказывал, что эликсир лаконичнее, а он тут же переписывал на эрланг гораздо изящнее — но на квотах как раз споткнулся.
Ну, вы меня сразили на повал этим примером.
Сегодня прочитал статью https://habr.com/ru/articles/483592/
Вот цитата, которая мне понравилась:
"80% статей в технических журналах, которые вообще-то были раньше предназначены для освещения технологических новинок, посвящены теперь «самым полезным в разработке навыкам, так называемым софтскиллам»
Мне кажется, что к этому надо стремиться вернуться, хотя это невозможно.
И ещё цитата:
"Еще в 1970 году были отличные разработчики, которые построили фундамент для всего, что мы используем сейчас. Они были невероятно талантливы и чрезвычайно скромны. И то и другое одинаково важно. Они выполняли свою работу как самые ранние исследователи, в пустыне знаний и под ураганами ошибок, простите уж мне мой высокопарный слог. "
Тяжело признаться в этом, но я застал ту атмосферу.
Love 'em. This is parse transforms done right.
Это, конечно, прям «это очень круто, нам нужно такое в эрланге». Но не суть. Теперь надо найти "эпик", который это эссе вызвало. Я - правда - чот теряюсь. Попытался на обновленном erlang forum'е что-то найти - но там, такое ощущение с какого-то момента "начали жить заново". Попробую в рассылке поискать.
У меня наложилось на мою длительную дискуссию с Джо в конце 2018, когда я на примерах доказывал, что эликсир лаконичнее,
Если где-то остались следы, яб с удовольствием бы почитал.
Это, конечно, прям «это очень круто, нам нужно такое в эрланге».
Простите, вы в курсе, как переводится «done right» с бусурманского?
следы
Не, это на λ days было, вживую. Они с Вирдингом откровенно скучали, вот мы и развлеклись.
Простите, вы в курсе, как переводится «done right» с бусурманского?
Очевидно, «это очень круто, нам нужно такое в эрланге» :-)
Я готов рупь к тысяче спорить, что я где-то видел (или слышал) ровно такую цитату: «We need that in erlang.» Но откопать в интернетиках не смог. Так что либо поверьте мне на слово, либо нет. До erl2, по крайней мере, не докатилось.
И вообще, чтобы поставить жирную точку: идеальное метапрограммирование сделал в результате не Майк Вильямс, не Джо, и не Жозе. Вирдинг — вот наш герой! https://lfe.io/learn/
Интересный разворот! Имхо, soft scills не так важен, сколько свежие идеи, меняющие качество.
В этом раскладе метапрограммирования вы можете оценить, какое место занимает старый РЕФАЛ . Я полагал, что его уровень сохраняется очень высоким.
Не очень понял, причем тут soft skills. Свежих идей вокруг полно́, с реализацией сложнее :)
Рефал как раз из этой серии: идея блистательная, но как только дело доходит до реализации — код превращается в трудночитаемое месиво. Точно так же и с Prolog’ом (который был более известен вне территории СССР) — идей, подаренных миру — вагон и маленькая тележка, но в качестве рабочего инструмента для повседневной работы он не годился.
Кроме того, потом всяческие евангелисты от математики пришли со своими доказываемыми леммами наперевес — и сейчас нестрогий матчинг оказался полностью вытеснен всяческими Agda’ми и Coq’ами. Создатели Хаскеля не осилили зависимые типы — появился Idris, на котором я пишу все прототипы более-менее сложных систем. Но Idris и близко не production-ready, поэтому приходится терять доказательства времени компиляции и переводить код на эликсир/эрланг после подтверждения работоспособности.
Короче, идеальных языков не существует: каждую задачу нужно решать теми средствами, которые наиболее подходят, причем иногда их будет больше одного.
причем тут soft skills
У вас с gbear диспут был, имхо, в этом русле. Я не осуждаю ни в коем случае, но для меня всегда важной была полнота отражения прикладной задачи на абстракцию инструментария. Пока Elixir меня устраивает своей универсальностью.
всяческие евангелисты от математики
Это мне было знакомо по ИПС РАН, куда я перешёл из оборонки. Там было много ребят, знающих РЕФАЛ и лично Турчина. Была лаборатория функционального программирования, но она, кажется, не сохранилась: после 22 года я спросил по старой памяти, какой функциональный язык у вас готов для использования. А в ответ - тишина.
Принимал участие в разработке Micro-Prolog. Зав. лаба Николай Кондратьев ставил задачу встроить графику в Prolog. Наверное, литература по логическому программированию была куцей и я не увидел органического объединение графики и Prolog.
А вот теперь я бы с удовольствием разместил "функциональную" графику поверх Elixir. И это не wxWidget.
Я готов рупь к тысяче спорить, что я где-то видел (или слышал) ровно такую цитату: «We need that in erlang.»
Ну, например, в той же "неделе с", чуть выше есть: «Sigils are great - love 'em. We should add these to Erlang.»
До erl2, по крайней мере, не докатилось.
?! erl2 вообще "про другое".
Я видел на россии вакансии по Elixir... Может быть Вы плохо искали?
Маркетинг есть даже в ИТ. И он, к сожалению, работает. Сегодня у технологии, за которой не стоит крупная компания, шансы на взлет небольшие. А в бизнесе вообще беда. Если фронт, почти безальтернативно react (Facebook, vercel), если бэк, то какой нибудь go (google), python (вроде многие компании поддерживают), c# (MS). Особенно удивляет стремление всюду все сделать на микросервисах, ведь у всех, абсолютно у всех, только hiload.
Отсюда и проблемы у эликсира. Если прийти в компанию и сказать, что ты сделаешь то же самое, только без микросервисов (или меньшей декомпозицией) тремя разработчиками на эликсире вместо десяти go-разработчиков, с тобой не будут разговаривать, подумают, что сумасшедший. Hiload же
Спасибо за анализ, интересно наблюдать за данным языком.
На мой взгляд, у эликсира несколько проблем и первой я бы назвал производительность в CPU-bound задачах. Да, эликсир даёт оч хорошую сеть без особых затрат, но с другой стороны, а где её сейчас нет? С популяризацией асинхронного программирования в последние годы сложно уже найти язык, который бы не завёз в том или ином виде асинхронку или какое-то другое неплохое решение для сети, которое покрывает бОльшую часть потребностей. И поэтому, когда я читаю, что в CPU-bound задачах эликсир показывает себя на уровне интерпретируемых языков, то у меня возникает вопрос - а зачем мне его тогда брать? Мне нужен более серьезный повод.
Вторая - тот самый нестандартный BEAM - подход к решению многих задач. В наш век, когда большинство языков используются либо для написания бизнес-логики, либо в качестве клея между готовыми и обкатанными решениями эликсир говорит - ребят, вот тут не нужна вам готовая очередь, вот тут вам не нужен редис, у меня всё есть. И возникают вопросы. А точно есть? А насколько они хороши? А что будет с проектом, если мы пойдём этим путём? И, конечно, ввиду отсутствия каких-то неоспоримых доказательств в пользу elixir/BEAM-way большинство сделает более прагматичный выбор.
Третий - функциональщина. Это и плюс и минус, но, однозначно, на сегодняшнем рынке это является проблемой, т.к. для перехода на функциональный язык надо приложить некоторое количество усилий.
Сообщество Elixir показывает интересные идеи, тот же liveview или phoenix стоят того, чтобы на него обратили внимание и это бустит его по-немногу, но всё же у него пока нет какого-то мощного дифференциатора на рынке языков.
И поэтому, когда я читаю, что в CPU-bound задачах эликсир показывает себя на уровне интерпретируемых языков, то у меня возникает вопрос - а зачем мне его тогда брать?
Вот это zigler - https://github.com/E-xyza/zigler Он позволяет вставлять zig код прямо в elixir код. Даже не отдельным файлом. Скорость этой функции должна быть на уровне компилируемых языков.
Вот это rustler - https://github.com/rusterlium/rustler Надо писать в отдельном файлике, но зато это уже точно скорость и гарантии раста. Кстати эта либа широко используется в продакшине.
А вот это Nx - https://github.com/elixir-nx/nx Можно писать математику прямо на эликсире, которая потом автоматически скомпилируется под CUDA или ROCm. Другими словами можно, не выходя из эликсир кода, сделать тензор на 100500 килобайт и посчитать какой нить softmax на 10 тысячах GPU ядер моей Nvidia RTX 4090 за считанные микросекунды, за которые и rust и C на 6-ти CPU даже "мама" сказать не успеют.
Проблемы с CPU-bound задачами в эликсире есть только у:
тех, кому религия запрещает смешивать языки в проектах
тех, кто соревнуется в бесполезных бенчмарках
тех, кто по бесполезным бенчмаркам делает выводы.
Всё это я могу проделать и в питоне и в ноде и наверняка почти в любом другом языке с проблемами в CPU-bound задачах, да и вообще с таким подходом мне никто не мешает написать небольшой сервис на расте и ходить в него. Только вот я именно так и сделаю скорее всего, а не буду ничего вызывать в эликсире)
Но я ни в коем случае не запрещаю делать этого вам. Если вы сделаете эликсир популярнее - я буду только рад.
На питоне да, а вот про поддержку XLA в ноде я что-то не слышал. Хотя всегда можно из ноды вызвать питон с JAX.
Но раз мы дружно вычеркнули CPU-bound задачи из недостатков на практике, то наверное и тезиса для спора нет.
С интересом наблюдал за вашим высоко теоретическим обменом мнений. Хочу подбросить в обсуждение один "hard" вопрос:
Известно, что Elixir применяется для систем "мягкого" реального времени.
Возможны архитектурные решения в языке, или в BEAM, которые позволят управлять системами жесткого реального времени? Причем, считаю, что посылка сообщений между процессами - идеальная продуктивная идиома.
Слышал про atomvm - там вроде как сделали BEAM для микроконтроллеров, без прослойки в виде операционки. Но я там не нашел ничего про hard realtime.
Не то чтоб я специализировался в этих вещах, но мне кажется, что идея кучи процессов, которые кидают друг в друга сообщения, и работают на нескольких шедулерах, лежит в противоположной стороне от бесконечных циклов и прерываний, характерных для hard realtime (как я это все представляю в своем ламерском воображении).
Насколько я могу судить исходя из здравого смысла, при разработке систем реального времени важнейшим моментом является определение детерминированного времени реакции на событие.
Для традиционных систем время реакции оценивается достаточно однозначно - это переключение прерывания.
Для механизма посылки сообщения точно гарантировать время обработки очереди сообщений не удаётся...
Может быть применить QOS?
Ну, это просто завиральные мысли.
тот же liveview или phoenix стоят того
А знаешь в чем вся прелесть liveview?
Такое можно сделать только в stateful бекенде, потому что liveview - это актуальная копия клиентского DOM-а, но на стороне сервера. Т.е. в бекенде есть код, который держит эту копию, на стороне бекенда же рендерится новая версия DOM-а, когда обновляются данные, на стороне бекенда считается разница, и бекенд отправляет разницу в вебсокет клиенту. Т.е. это типичный SPA, как Angular, React и прочие, но backend-side.
И это масштабируется. А ведь нельзя так просто взять и отмасштабировать stateful бекенд.
Чтоб отмасштабировать stateful бекенд (на обычном языке), надо или сделать его stateless и вынести состояние во внешнюю базу (как делают все), но тогда на каждое обновление и клик по сути надо делать SQL запросы (как минимум update), что уже латенси и лютый бред (для SPA). Или терять весь DOM, если клиент вдруг внезапно переподсоединится к другой ноде в кластере.
И уже никак нельзя допускать рестарта пода от к8s. Потому что если куб или докер рестартанул stateful бекенд, который в памяти держит копии DOM-а для 100500 клиентов, то все эти клиенты внезапно потеряли всю свою навигацию и откатились в home page.
Liveview - он снаружи обманчиво простой, но если попробовать его повторить на другом языке, то внезапно начинаешь понимать зачем нужно дерево супервизоров а не просто кубернетис, зачем нужна изоляция ошибок, почему нужны иммутабельные данные (а значит и функциональный подход), и вообще вылезает огромная куча проблем и откровений, после которых начинаешь по другому смотреть на Erlang/Elixir а также BEAM и OTP.
Спасибо за статью. Я как человек писавший на эликсире несколько лет назад, могу сказать свое мнение.
Язык и среда сами по себе отличные, но с точки зрения бизнеса не практичные.
И на это есть несколько причин:
С появлением кубера приложение становится похоже на кубер в кубере. В случае с кубером за него отвечают девопсы, в случае эликсира разработчики —размывается ответственность.
Эликсир был вдохнавлен ruby, а phenix - rails. Многие начали на него переходить по причине "умирания" ruby и rails, но удобство разработки схожих с рельсой так и не получилось достичь. Те же полиморфные связи отсутствовали в фениксе на тот момент, когда я на нем писал.
Эликсир очень плох в однопотоке, большие массивы данных обрабатывать не удобно, поэтому что приходится в многопоток, код из-за этого становится плохочитаемым. (например парсинг csv файла)
Наконец стоимость найма. Эликсир разработчики стояли так же, как и рельсовики, но сама разработка из-за этого не становится дешевле(см. пункт 2). Легче было уйти в эрланг и получать в 2 раза больше.
Эликсир был вдохновлен ruby, а phoenix — rails.
Это очень поверхностный и абсолютно неверный взгляд.
удобства разработки схожих с рельсой так и не получилось достичь
Я могу написать три экрана кода на руби, который заведется с первой попытки, но на эликсире/финиксе у меня то же самое получится в полтора-три раза быстрее и пуленепробиваемее.
например парсинг csv файла
Откройте для себя Flow https://hexdocs.pm/flow.
Эликсир разработчики стояли так же, как и рельсовики, но сама разработка из-за этого не становится дешевле
Во-первых, становится даже просто по срокам, а во-вторых — дело в качестве кода, а не в цене рабов. Плохой код на эликсире написать примерно в пятьсот раз сложнее, чем на руби.
Автор слегка голосам по европам…
Erlang сей час не в телекоме используется а в основном в трейдинге. По крайней мере в области торговли электричеством в Европе.
RabbitMQ написа не erlang и активно используется много где.
Ещё на erlang много пишут в игровой индустрии - онлайн казино и им подобные.
Просто автор не в том месте и не в то время находится.
Плюс компании особенно не распространяются про использование erlang :)
Elixir примерно там же но больше там где нужен фронт енд.
Книг на русском нет так как они не нужны. Если клиенты на западе -читайте на английском. :)
Язык, платформа и экосистема прекрасна;
Вы не одиноки;
Вакансии в РФ есть и не одна;
Есть хорошие видеокурсы курсы на русском, например от Юрия Жлобы и Ильи Краковского;
Сейчас я прохожу замечательный курс от Thinknetica с крутым спикером Алексеем Матюшкиным;
В этом году я познакомился Эликсир, изучил и нашел работу на нем.
Наверное, не всё так просто у меня. Я пришёл к Elixir из области управления технологическими процессами. Есть идеи, которые хочу реализовать.
Честно говоря не понимаю в чем преимущество elixir перед erlang? Единственное что приходит в голову - народ который с ruby пересаживается находит синтаксис более знакомым. В остальном по мне оригинал лучше :)
Мне Erlang тоже представляется концептуально чище. Стандартный ответ обычно такой: синтаксический сахар.
Мне ещё импонирует в Elixir механизм макросов, при помощи которого можно разработать свой DSL.
Стандартный ответ обычно такой: синтаксический сахар.
На efene, емнип, Жозе сразу указывали. Но, "мы не ищем легких путей" :-)
Мне ещё импонирует в Elixir механизм макросов, при помощи которого можно разработать свой DSL.
Можно подумать, что parse_transform в erlang, кто-то запретил :-) Куда уж мощнее.
Нашёл в Интернет Алексея Матюшкина. Учит Phoenix-у.
Рассказывает ли он о каналах на WebSocket, не понял. Подписчики канала пишутся на JS, имхо. Такие каналы открывают дверь в мир EDA. А это уже другой мир.
Вот как раз в том курсе который я прохожу о фениксе не много, там в основном про язык, платформу, подходы. Ценно, рекомендую купить запись если можно. Я в основном записи смотрю и домашки делаю.
Наверное, речь идет об OTP. Рекомендую книгу Саши Юрич. Методически очень хороший материал для обучения.
Я в основном читаю и перевожу книги с англ.
#перенес в правильную ветку
Как говорится, найди язык программирования, который тебе по душе, и тебе не придётся работать ни дня в своей жизни, потому что вакансий на этом языке нет.
А Elixir точно enterprise-ready?
Я ковырял его некоторое время назад, оказалось, что у него нет рабочей реализации телеметрии, в лучшем случае что-то написанное на коленке:
Указанные вами приложения не из коробки. Вроде в книгах попадалось приложение для телеметрии из hex.pm. Если интересно, то могу поискать и восстановить информацию.
А что вы имеете в виду, говоря, "Корпоративно готово"?
С телеметрией в эликсире получше чем в остальных, которые считаются enterprise-ready.
Решение так и называется - telemetry (https://hex.pm/packages/telemetry) и уже практически стало стандартном дефакто в экосистеме. Т.е. с ним интегрируются библиотеки и фреймворки, когда есть смысл выдавать телеметрию. И когда такую либу подгружаешь в проект, то достаточно посмотреть какие данные она может отдать и "включить" их.
Пример: phoenix (типа рельс), ecto (вместо orm в фениксе), absinthe (graphql api), finch (http client)
Это всё отлично, но как эти внутренние метрики и спаны экспортировать в общепринятом формате?
Это еще не метрики, это больше сигналы. Надо сначала с помощью Telemetry.Metrics превратить сигналы в метрики (и включить их), а дальше уже что угодно. Например, для прометея (самый общепринятый формат как я понимаю) есть https://hexdocs.pm/telemetry_metrics_prometheus/TelemetryMetricsPrometheus.html
Очень странно видеть жалобы на русское Elixir коммьюнити и ни слова про вполне живой чатик в телеге в который летят вакансии в том числе. Ну и ни слова про те же курсы от Юрия Жлобы или Алексея Матюшкина, которые исправно развиваются и обучают народ. Как-будто из параллельного мира голос.
Ну а насчет нашего рынка разработчиков бекендов - там засрано гошкой. Куча компаний, видимо, решило, если писать на go, то вот точно станут Гуглом, ну в крайнем случае Яндексом! Ведь там же пишут, значит решение норм! Западные компании уже немного осознали подставу, и что язык для лямбд не очень подходит для не-лямбд бекендов, но у нас как всегда с диким латенси.
"Как-будто из параллельного мира голос"
Я действительно из "параллельно мира".
Вспомнил, что один раз был в чате телеге. Спросил:
"Нужен специалист по БПФ. Конкретно: вычленение из потока прихода звуковой волны, обработки 30млс семпла, а затем идентификации звука."
Где-то часа 1,5 обсуждали вопрос. Потом, выяснилось, что модераторы не то обсуждали:
"Я думаю что БПФ - это быстрое преобразование фурье"
"Так а бип-бип тут тогда что-то обсуждать, если есть 1000 и 1 либа для этого"
"Видимо чувак хочет понять какую либу взять для nerves
Правда я понятия не имею
И даже не знаю есть ли они"
Больше я на телегу не ходил.
Буду признателен, если кинете в меня линком на этот чат.
Спасибо
Не готов спорить о достоинствах/недостатках Elixir, мы выбрали его как основу нашей разработки и очень довольны. Но с чем не могу не согласиться - это с очень небольшим количеством специалистов. Уже довольно давно ищем людей - но достойных кандидатов очень мало.
Если читает кто-то, кто заинтересован в интересном проекте на Elixir - стучитесь в личку, буду рад пообщаться и, возможно, предложить сотрудничество.
Назначение языка программирования Elixir