А вы видели чтобы кто нибудь когда нибудь синхронизировался на value-based типах.
Ну т.е. таки надо за не "на пустом месте"? :-) Если не лень - ну можете начать, например, с осени 2014 года. Ссылку сознательно дал на начало ветки, чтоб был ясен контекст. И даже в этой ветке уже есть упоминания о synchronized на строке, которая "внезапно была интернирована".
Что это может быть за кейс?
А что необычного-то?! Есть экземпляр ссылочного типа. Где-то было сказано, что его нельзя использовать для? До "восьмерки", в смысле. Да и в "восьмерке" это было сделано настолько, скажем так, "деликатно", что многие и не заметили даже. :-)
JEP 390 для подготовки к valhalla ...
Это что-то меняет?! Да львиная доля jep'ов - это "для подготовки к valhalla". Тем не менее, тот же 390й уже целиком и полностью в "стандарте" начиная с 16ой редакции (а "кусками" - так и раньше).
Во втором случае всё совсем полностью понятно: сравнение ссылочного типа с примитивным принципиально невозможно, значит должен быть анбоксинг.
В каком смысле "принципиально невозможно"? То, что в Java "принципиально невозможно" - в принципе, не компилируется :-)
В том-то и дело, что этот вариант вполне себе возможен, и то, что при разрешении там к операнду применяется (ко всему прочему) unboxing conversion, а не - к примеру - boxing conversion (а почему, собственно, нет?) - четко прописано в спецификации на equality operators.
И там же, кстати, есть за а почему этого не происходит в первом случае (хотя - казалось бы, что мешает?!)
Замечу, что первый пример в реальной жизни я встречал 0 раз за 20 лет.
Дык он же примечателен не тем, что "могут быть кэши". А тем, что есть ("неуловимая", ага) разница между ним и
Integer.valueOf(x) == new Integer(x);
Всё "просто и понятно" (tm)
Не просто же так конструкторы у этих "штук" помечены depricated начиная, емнип, с "девятки"? Ведь так? :-)
В "реальной жизни" оно вообще обычно стреляет не через if'ы, а, например, через упрятанный "в глубинах JDK" synchronized, в которой прилетает "такое" и всё внезапно ломается.
Второй примерно 1.5 раза.
Ну это просто самый простой способ показать:
Что == у ссылочных типов не всегда берет "ссылку" для сравнения;
Что не "просто и понятно" и - самое главное - сильно непросто контролировать.
Или вы реально считаете, что тот же JEP 390 на пустом месте родился, и его зря в "стандарт" потянули?!
Если речь про п. 1, то речь о том, что в языках, где есть перегрузка операторов, поведение оператора - конечно, сильно упрощая - определяется типом левого операнда.
В Java "ссылочные типы" всегда сравниваются по значению.
А с этим никто и не спорит. :-)
Возможно вы про эффекты наличия объектов в Constant Pool? Или про кэши Integer? Это ничего не меняет, это всё ещё равенство ссылок.
Нет, не про них (хотя это тож из разряда "красивое"). Я - скорее - про то, что equality operators в Java:
Не имеют привязки (явной) к типу левого операнда, как обычно мы привыкли и ожидаем. К типу правого - если что - оно тож не привязано;
Конкретное "поведение" выбирается исходя из спецификации (часть языка). И оно не такое простое и понятное, как хотелось бы;
В этой спецификации как раз есть пункт, который описывает когда "значение" ссылочного типа - которое будет использовано для сравнения - это не значение его "ссылки".
Оператор == в яве нельзя переопределить, у него постоянная семантика ...
?! Хотя, если имеется ввиду, что (его семантика) - это всегда т.н. equality check, то да - постоянная. Но, с этой точки зрения - она и в C# ровно такая же "постоянная".
А, на самом деле, как раз с equality check в java всё настолько просто и понятно (нет), что сразу вспоминается "самый популярный вопрос" и некоторые JEP'ы.
И да... если под "постоянная" подразумевается, что в Java == для ссылочных типов всегда проверяет "ссылки" - то это не так. Внезапно, не всегда.
А в шарпе как раз тот случай, когда содрали "как у явы", но не поняли зачем именно там сделали два разных оператора сравнения.
У них перед глазами был - например - процесс мучительно рождения Objects.equals в Java. Они - имхо, совершенно верно - решили не наступать на грабельки.
А в "мире разработки программного обеспечения" мы пока даже не можем однозначно сказать, к какой области деятельности этот самый "мир" относится - производство это, или искусство, и, быть может, как выше упоминали, вообще наука. Не... большинство, конечно, сильно надеется, что таки производство, но "единства в умах" тут пока нет. Так что, например, я не рискнул бы эти "практики", "принципы" и т.п. записывать в "хорошие".
Во-первых не столько много времени прошло, чтоб мы могли говорить о каких-либо объективных оценках. Прошедшего времени не хватило даже для того, что бы просто выработать хоть сколько-нибудь объемлющие критерии этой "хорошести". В том числе, и потому, что вопрос с "областью деятельности" до сих пор открыт.
А во-вторых, на данный момент, весь опыт развития "мира разработки программного обеспечения" показывает нам, что этот "мир" развивается (если таки развивается) путём - "теперь мы точно знаем, что так делать не надо". И для этого тоже есть множество причин (и даже объективных). Но суть-то в том, что уже даже этот опыт указывает нам, что определенная доля, скажем так, скептицизма "в подходах" - "это есть хорошо".
Это я всё к тому, что ваше "стандарт де-факто", "скорее выполняются, чем игнорируются" и прочие "не буква, то дух" - это, мягко говоря, не совсем так. Как раз наоборот. Мы знаем кучу полезного (и коммерчески успешного) программного обеспечения (в том числе, и enterprise уровня), которое создано в нарушение всех этих "хороших практик". По разным причинам "так получилось". Но, при этом оно вполне себе хорошо живёт и развивается (и продается) по сей день.
Т.е. в целом - всё, о чем сейчас можно говорить применительно к этим "хорошим практикам", что они (эти "практики") возможно применимы в каких-то весьма узких областях "мира разработки программного обеспечения".
... это не значит, что есть какие-то проблемы «с композицией»
Не-не-не... в конечном счёте, это как раз это и значит. Точнее, в том числе, и это.
Начинается там всё с того, что "композиция" (точнее, то, что, порой, так называют в elixir) макросов - её результат - не есть макрос. Ну и дальше оно одно за другое, и приводит к вот таким вот "штукам".
Означает ли это, что "макросы в elixir" какие-то плохие? Нет. Вообще - нет.
Означает ли это, что отличная (а так и есть) макросистема elixir - плохой (или, скорее, не удачный) инструмент (способ, если хотите) метапрограммирования - с моей точки зрения, таки да.
Т.е. пока "некоторые вещи" не сильно важны - ну например, мы делаем какой-то "embedded DSL" а-ля ecto queries, например - т.е. вещи, которые слабо (или вообще не) зависят от контекста - то всё не просто хорошо, всё - замечательно. Нас вполне устраивает "локальность", нам вполне достаточно такой "композиции" и т.п. Но - я это уже говорил - называть "это" метапрограмированием, с моей точки зрения, это "такое".
И это становится сразу видно, например, когда "локальность" начинает мешать, когда важен становится контекст (и глобальный) и т.п. - т.е. когда дело таки доходит до "программа, которая пишет программу ..." - что, собственно, и есть метапрограммирование. А т.к. в рамках самой макросистемы (отличной, ещё раз повторю) elixir эти "ограничения" не снимаются в принципе, то приходится искать "обходные пути". Без относительно того, как они "done".
Собственно, всё что хотел сказать - сказал :-) No offence, "респетк", "ужавение" и всё такое.
Это, конечно, прям «это очень круто, нам нужно такое в эрланге». Но не суть. Теперь надо найти "эпик", который это эссе вызвало. Я - правда - чот теряюсь. Попытался на обновленном erlang forum'е что-то найти - но там, такое ощущение с какого-то момента "начали жить заново". Попробую в рассылке поискать.
У меня наложилось на мою длительную дискуссию с Джо в конце 2018, когда я на примерах доказывал, что эликсир лаконичнее,
Неясно, если честно, что тут может быть непонятно.
Теперь - всё понятно.
Я не поленился найти ссылку. И не поленился прочитать вопрос ...
Отлично! Вам - как я понимаю - осталось найти "с чего всё начиналось". Топикстартер же не просто так пришёл - типа "хочу такой хак". Правда ведь? Он даже, вон, ссылочку не забыл прицепить... цитат, вот, со статьи надергал. Не просто так, наверное. Нет?
Человеку нужен хак, позволяющий обойти механизм обработки макросов в языке.
А вы подумайте, зачем - спустя больше десяти лет - ему всё ещё таки нужен этот хак?
Вы вообще у курсе, что такое композиция?
Спасибо, я "у курсе" :-)
И вообще, вам человек, собаку на макросах съевший, говорит ...
Мне не надо "говорить". Я вполне способен заглянуть в код и увидеть насколько всё "отлично".
Чужой — в смысле непредсказуемый. Не свои соседние три с половиной модуля, которые подработаны напильником ...
Блин... ну гляньте qlc какой-нибудь, или eunit (там авто экспорт, емнип, на PT сделан). Это из того, что в otp входит. lagger - какой-нибудь из стороннего. Это то, что прям сразу в голову приходит.
Я нигде не называл 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. Вы бы спеллчекером обзавелись, что ли, а то ведь глаза вытекают.
Зачем тогда загонять про "метапрограммированием, аналогов которому нет ни в одном языке даже близко"?!
С ним все в порядке, в принципе, да вот беда: он вызывается после парсинга в синтаксическое дерево. На полном 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" метапрограммированием, да ещё и "аналогов которому нет" - это "такое", имхо.
Вот и всё.
Тыкать в ответ одним редкоиспользуемым даже в коммьюнити инструментом, о котором известно каждому третьекласснику — ну так себе манера дискуссии.
По поводу, "редко"/"часто"-используемый он... уж не знаю, про какое "коммьюнити" вы тут утверждаете... нормально он используемый :-) Именно на уровне библиотечного кода - вполне себе.
Метапрограммированием, аналогов которому нет ни в одном языке даже близко.
Даже не смешно. Квазицитирование 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 :-)
... наличии у разработчиков неясности в вопросе выгоды от его применения.
Самое важное, имхо. Жозе в 11'ом не мог внятно ответить на вопрос "зайчем?". Даже когда его прямо спрашивали про "efene" и прочие "erlog"'и. Но тогда хоть можно было списать на "молодой/горячий".
Прошло больше десяти лет - как я понимаю - мало что поменялось с тех времен :-)
Т.е. "чем лучше", какой-нибудь - условный - haskerl/hamler - понять я способен... да даже "чем лучше" разные ML-диалекты, живущие на beam.
Но "чем лучше" elixir - лично я, например - понять не способен :-( Лично для меня это как была "поделка уровня efene", так и осталась.
Уверен, хотя не думаю что смогу вам привести подробности 6-летней давности.
А на чём базируется ваша уверенность?! Я - грешным делом - с Erlang знаком хорошо. И ваше утверждение что проблема в "копировании binary" - лично для меня выглядит ну очень странно.
Binary (это вот "такое" <<>>... вы же про него?) - отдельный, специальный тип данных. Он - by desing - сделан так, чтоб избежать копирования в пределах VM. И то, для чего Erlang и был придуман, как бы и есть обработка "непрерывного потока" binary. Поэтому - "странно всё это" (с)
Или возьмите второй пример и сделайте так чтобы он работал в 5-10 раз быстрее. Это будет конструктивно и интересно
Дык вся "прелесть" в том, что вы - как иллюстрацию - почему-то взяли решение, которое - в принципе - в декларативном виде выглядеть будет плохо.
Хм... "странное" (tm). А меня - как раз toolbox - её "не ловит", чему я был рад.
Ну т.е. таки надо за не "на пустом месте"? :-) Если не лень - ну можете начать, например, с осени 2014 года. Ссылку сознательно дал на начало ветки, чтоб был ясен контекст. И даже в этой ветке уже есть упоминания о synchronized на строке, которая "внезапно была интернирована".
А что необычного-то?! Есть экземпляр ссылочного типа. Где-то было сказано, что его нельзя использовать для? До "восьмерки", в смысле. Да и в "восьмерке" это было сделано настолько, скажем так, "деликатно", что многие и не заметили даже. :-)
Это что-то меняет?! Да львиная доля jep'ов - это "для подготовки к valhalla". Тем не менее, тот же 390й уже целиком и полностью в "стандарте" начиная с 16ой редакции (а "кусками" - так и раньше).
В каком смысле "принципиально невозможно"? То, что в Java "принципиально невозможно" - в принципе, не компилируется :-)
В том-то и дело, что этот вариант вполне себе возможен, и то, что при разрешении там к операнду применяется (ко всему прочему) unboxing conversion, а не - к примеру - boxing conversion (а почему, собственно, нет?) - четко прописано в спецификации на equality operators.
И там же, кстати, есть за а почему этого не происходит в первом случае (хотя - казалось бы, что мешает?!)
Дык он же примечателен не тем, что "могут быть кэши". А тем, что есть ("неуловимая", ага) разница между ним и
Всё "просто и понятно" (tm)
Не просто же так конструкторы у этих "штук" помечены depricated начиная, емнип, с "девятки"? Ведь так? :-)
В "реальной жизни" оно вообще обычно стреляет не через if'ы, а, например, через упрятанный "в глубинах JDK" synchronized, в которой прилетает "такое" и всё внезапно ломается.
Ну это просто самый простой способ показать:
Что == у ссылочных типов не всегда берет "ссылку" для сравнения;
Что не "просто и понятно" и - самое главное - сильно непросто контролировать.
Или вы реально считаете, что тот же JEP 390 на пустом месте родился, и его зря в "стандарт" потянули?!
Ну вы чего?!
Ожидаем вычисление в false. Так?
А тут? А что поменялось? Ссылочный же тип :-)
Если речь про п. 1, то речь о том, что в языках, где есть перегрузка операторов, поведение оператора - конечно, сильно упрощая - определяется типом левого операнда.
А с этим никто и не спорит. :-)
Нет, не про них (хотя это тож из разряда "красивое"). Я - скорее - про то, что equality operators в Java:
Не имеют привязки (явной) к типу левого операнда, как обычно мы привыкли и ожидаем. К типу правого - если что - оно тож не привязано;
Конкретное "поведение" выбирается исходя из спецификации (часть языка). И оно не такое простое и понятное, как хотелось бы;
В этой спецификации как раз есть пункт, который описывает когда "значение" ссылочного типа - которое будет использовано для сравнения - это не значение его "ссылки".
Вот такая вот "постоянная семантика" (tm)
Такая же, такая же... "только ещё хужее" (с)
?! Хотя, если имеется ввиду, что (его семантика) - это всегда т.н. equality check, то да - постоянная. Но, с этой точки зрения - она и в C# ровно такая же "постоянная".
А, на самом деле, как раз с equality check в java всё настолько просто и понятно (нет), что сразу вспоминается "самый популярный вопрос" и некоторые JEP'ы.
И да... если под "постоянная" подразумевается, что в Java == для ссылочных типов всегда проверяет "ссылки" - то это не так. Внезапно, не всегда.
У них перед глазами был - например - процесс мучительно рождения Objects.equals в Java. Они - имхо, совершенно верно - решили не наступать на грабельки.
А в "мире разработки программного обеспечения" мы пока даже не можем однозначно сказать, к какой области деятельности этот самый "мир" относится - производство это, или искусство, и, быть может, как выше упоминали, вообще наука. Не... большинство, конечно, сильно надеется, что таки производство, но "единства в умах" тут пока нет. Так что, например, я не рискнул бы эти "практики", "принципы" и т.п. записывать в "хорошие".
Во-первых не столько много времени прошло, чтоб мы могли говорить о каких-либо объективных оценках. Прошедшего времени не хватило даже для того, что бы просто выработать хоть сколько-нибудь объемлющие критерии этой "хорошести". В том числе, и потому, что вопрос с "областью деятельности" до сих пор открыт.
А во-вторых, на данный момент, весь опыт развития "мира разработки программного обеспечения" показывает нам, что этот "мир" развивается (если таки развивается) путём - "теперь мы точно знаем, что так делать не надо". И для этого тоже есть множество причин (и даже объективных). Но суть-то в том, что уже даже этот опыт указывает нам, что определенная доля, скажем так, скептицизма "в подходах" - "это есть хорошо".
Это я всё к тому, что ваше "стандарт де-факто", "скорее выполняются, чем игнорируются" и прочие "не буква, то дух" - это, мягко говоря, не совсем так. Как раз наоборот. Мы знаем кучу полезного (и коммерчески успешного) программного обеспечения (в том числе, и enterprise уровня), которое создано в нарушение всех этих "хороших практик". По разным причинам "так получилось". Но, при этом оно вполне себе хорошо живёт и развивается (и продается) по сей день.
Т.е. в целом - всё, о чем сейчас можно говорить применительно к этим "хорошим практикам", что они (эти "практики") возможно применимы в каких-то весьма узких областях "мира разработки программного обеспечения".
Ну, например, в той же "неделе с", чуть выше есть: «Sigils are great - love 'em. We should add these to Erlang.»
?! erl2 вообще "про другое".
Очевидно, «это очень круто, нам нужно такое в эрланге» :-)
Не-не-не... в конечном счёте, это как раз это и значит. Точнее, в том числе, и это.
Начинается там всё с того, что "композиция" (точнее, то, что, порой, так называют в elixir) макросов - её результат - не есть макрос. Ну и дальше оно одно за другое, и приводит к вот таким вот "штукам".
Означает ли это, что "макросы в elixir" какие-то плохие? Нет. Вообще - нет.
Означает ли это, что отличная (а так и есть) макросистема elixir - плохой (или, скорее, не удачный) инструмент (способ, если хотите) метапрограммирования - с моей точки зрения, таки да.
Т.е. пока "некоторые вещи" не сильно важны - ну например, мы делаем какой-то "embedded DSL" а-ля ecto queries, например - т.е. вещи, которые слабо (или вообще не) зависят от контекста - то всё не просто хорошо, всё - замечательно. Нас вполне устраивает "локальность", нам вполне достаточно такой "композиции" и т.п. Но - я это уже говорил - называть "это" метапрограмированием, с моей точки зрения, это "такое".
И это становится сразу видно, например, когда "локальность" начинает мешать, когда важен становится контекст (и глобальный) и т.п. - т.е. когда дело таки доходит до "программа, которая пишет программу ..." - что, собственно, и есть метапрограммирование. А т.к. в рамках самой макросистемы (отличной, ещё раз повторю) elixir эти "ограничения" не снимаются в принципе, то приходится искать "обходные пути". Без относительно того, как они "done".
Собственно, всё что хотел сказать - сказал :-) No offence, "респетк", "ужавение" и всё такое.
Это, конечно, прям «это очень круто, нам нужно такое в эрланге». Но не суть. Теперь надо найти "эпик", который это эссе вызвало. Я - правда - чот теряюсь. Попытался на обновленном erlang forum'е что-то найти - но там, такое ощущение с какого-то момента "начали жить заново". Попробую в рассылке поискать.
Тут?
Если где-то остались следы, яб с удовольствием бы почитал.
Теперь - всё понятно.
Отлично! Вам - как я понимаю - осталось найти "с чего всё начиналось". Топикстартер же не просто так пришёл - типа "хочу такой хак". Правда ведь? Он даже, вон, ссылочку не забыл прицепить... цитат, вот, со статьи надергал. Не просто так, наверное. Нет?
А вы подумайте, зачем - спустя больше десяти лет - ему всё ещё таки нужен этот хак?
Спасибо, я "у курсе" :-)
Мне не надо "говорить". Я вполне способен заглянуть в код и увидеть насколько всё "отлично".
Блин... ну гляньте qlc какой-нибудь, или eunit (там авто экспорт, емнип, на PT сделан). Это из того, что в otp входит. lagger - какой-нибудь из стороннего. Это то, что прям сразу в голову приходит.
Мы - судя по всему - "уходим на второй круг"...
Я нигде не называл 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 - это действительно механизм. Это не библиотека, не код - если хотите. Это вот - буквально - "флажок компилятора".
И в чем проблема в том, чтобы использовать "сторонние библиотеки"?! Ну не хотите - не используйте... пишете весь разбор AST и т.п. "ручками". Я вам лишь указывал на то, что для "ручками" должны быть веские причины, ибо практически весь ваш "бойлерплейт" написан уже давно.
Мог бы процитировать вас же... но - промолчу :-)
Ну дык и для работы parse_transform - требуется только синтаксическая корректность. В чем проблема-то?!
?! С чего вы так решили-то? Где я вас пытался убедить, что PT аналогичен "макросам"?
parse_transform - это штатный инструмент метапрограммирования в ernalg. Того самого "метапрограммирования" - по вашим же словам - "аналогов которому нет ни в одном языке даже близко". Я вам лишь указываю, что вот: и язык, и метапрограммирование на этом же языке. Если хотите - можем подискутировать о том, какое из них более "мета". Но, лично я, особого смысла в этом не вижу. Мне вполне достаточно старых фидбэков от traceble, и того знания, что за десяток лет никуда "оно" не делось.
А что есть "пост-обработка", в вашем понимании? Так-то, мне обратное как раз представить сложно. В том смысле, что трансформация AST - это всегда внешний, по отношению к текущему, модуль. Так что любой модуль, указанный в parse_transform - обрабатывает как раз "чужие модули".
И вам - не хворать
Зачем тогда загонять про "метапрограммированием, аналогов которому нет ни в одном языке даже близко"?!
Ну мы можем, конечно, возобновить дискуссию по поводу "насколько локальность такого рода трансформаций more right thing"... только смысл?! В прошлый раз (как раз когда Армстронг опубликовал свое "неделя с элексиром"), если мне не изменяет мой склероз, всё закончилось тем, что "да, заманчиво, но вот как быть с" и ниже "списочек". Специально вот сейчас заглянул на elixirforum - как я понимаю, вопросы с "правильной" композицией "макросов" до сих пор "будоражат умы". Там уже такие "костыли со стразиками" рисуются, что реально не знаешь плакать или смеяться.
Т.е. - лично для меня - это выглядит так, что то, о чём предупреждали десять лет назад, сбывается с "пугающей точностью", как говориться.
А по поводу "бойлерплейта"... ну если каждый раз всё делать "с нуля" и "ручками", то таки да - "а что вы хочите?!". И если вы таки знаете за parse_transform, то зачем делать "с нуля"?! Какой-нибудь parse_trans, например, написан Ульфом уж точно больше десяти лет назад. И до сих пор жив и развивается. Емнип, даже на github'е с некоторых пор лежит. Т.е. для того, чтоб "всё писать с нуля" таки должны веские основания. Так что - в реальности - "бойлерплейта" там, скажем так, в меру. Не так чтобы вообще без... но "всё по делу".
?! Можно подумать что в quote можно любую "чушь" пихать :-) Естественно, модуль, который подвергается трансформации должен быть синтаксически корректным.
С чего бы?!
Ну да, ну да. Сразу вспомнил как увидел первые попытки нарисовать элементарный traceable на "тех самых макросах". "Воспоминание разблокировано", как говориться :-)
?! И то ("разворачивание макросов elixir" ), и другое (erlang parse_transorm) - происходит на одном и том же этапе компиляции. Вся разница в "локальности"... в "объеме контекста", если хотите.
Как бы в том, чтоб "триста раз подумать" нет ничего плохого, как мне кажется. А по поводу "громоздкости" - тут на вкус и цвет. Он полностью прозрачен, логичен, лаконичен и внутренне не противоречив :-)
Про препроцессор эрланга я вообще ничего не говорил. Он к метапрограммированию не относится вообще никак.
В какой теме вы мне "рекомендуете разобраться"? :-) Всеж просто - вы, в "зачем нужен elixir" на первое место поставили "метапрограммирование, аналогов которому нет ...". Упомянули, например, квазицитирование LISP, кучу всего ещё, вспомнили Джо, который типа "хвалил за quote/unquote"... но - почему-то - не вспомнили о parse_transform erlang'а. Это как?!
Для меня это выглядит так, что вы либо не знаете, что он есть, либо не считаете его "метапрограммированием".
Я лишь отвечал на ваш - сугубо не верный, с моей точки зрения - посыл. Эрланговский parse_transofrm - именно как инструмент метапрограмирования - лично с моей точки зрения (да и не только с моей), тут далеко впереди "макросов", которые - опять же, по моему личному мнению. - вполне имеют свою нишу... они хороши, например, как инструмент для создания различного рода "embedded DSL". По крайней мере, тут их "локальность" имеет смысл быть.
А называть "embedded DSL" метапрограммированием, да ещё и "аналогов которому нет" - это "такое", имхо.
Вот и всё.
По поводу, "редко"/"часто"-используемый он... уж не знаю, про какое "коммьюнити" вы тут утверждаете... нормально он используемый :-) Именно на уровне библиотечного кода - вполне себе.
Даже не смешно. Квазицитирование LISP вы упомянули сами. А в Erlang - например - есть parse transform. Я хз "полечили" ли уже в Elexir его "танцы" с композицией макросов, но прикол в том, что в parse tranform такого рода "танцев" нет в принципе. "Программа, которая пишет программу, которая пишет программу, которая захватывает мир" - это и про erlang тож. Так что не надо нам тут за "метапрограммирование" :-)
Если я правильно понимаю, о чём речь, то "увидел" он их году так в 2013ом (если мне мой склероз не изменяет). И сказал совсем не это :-) Грубо говоря (хотя можно и поискать цитаты, если сильно надо), по его мнению, наличие механизма квазицитирования сделало бы parse transform более "right thing". О чём даже была дискуссия, в рамках которой было установлено что дело не в "наличие отсутствия" quote/unquote. Дело - если "на пальцах" - в возможности описывать такого рода трансформации, что называется, "по месту". Но, является ли это действительно "more right" так и не было установлено. Выглядит оно действительно привлекательно, но ведёт к весьма очевидным "приседаниям" с гигиеной и композицией.
И если уж говорить "вообще" за "Джо Армстронг и Elexir", то хвалил он (а он таки хвалил) Elexir не за его "метапрограммирование".
Не совсем понятно причет тут "rust"... но если говорить о "выставленным наружу родном AST" и о механизмах (штатных, причем) работы с ним, то parse tranform если и уступает в чём-то квазицитатам LISP'а, то только в "элегантности". Всё-таки "макрос" в erlang это отдельный модуль, со всеми вытекающими.
Ещё раз... вы вообще в курсе наличия в erlang такого механизма как parse tranform? Судя по всему - нет. Для erlang вполне обыденно делать "такое". Это штатный - повторюсь - механизм.
Ну вы просто - насколько я понимаю - не в курсе про возможности метапрограммирования в erlang :-)
На efene, емнип, Жозе сразу указывали. Но, "мы не ищем легких путей" :-)
Можно подумать, что parse_transform в erlang, кто-то запретил :-) Куда уж мощнее.
#перенес в правильную ветку
Самое важное, имхо. Жозе в 11'ом не мог внятно ответить на вопрос "зайчем?". Даже когда его прямо спрашивали про "efene" и прочие "erlog"'и. Но тогда хоть можно было списать на "молодой/горячий".
Прошло больше десяти лет - как я понимаю - мало что поменялось с тех времен :-)
Т.е. "чем лучше", какой-нибудь - условный - haskerl/hamler - понять я способен... да даже "чем лучше" разные ML-диалекты, живущие на beam.
Но "чем лучше" elixir - лично я, например - понять не способен :-( Лично для меня это как была "поделка уровня efene", так и осталась.
А на чём базируется ваша уверенность?! Я - грешным делом - с Erlang знаком хорошо. И ваше утверждение что проблема в "копировании binary" - лично для меня выглядит ну очень странно.
Binary (это вот "такое" <<>>... вы же про него?) - отдельный, специальный тип данных. Он - by desing - сделан так, чтоб избежать копирования в пределах VM. И то, для чего Erlang и был придуман, как бы и есть обработка "непрерывного потока" binary. Поэтому - "странно всё это" (с)
Дык вся "прелесть" в том, что вы - как иллюстрацию - почему-то взяли решение, которое - в принципе - в декларативном виде выглядеть будет плохо.
Канонически, тут "поиск простых чисел" делается - вот буквально - на "решете" и ленивых последовательностях. И память не жрет, и работает быстро.
первые две строки :-)