clojure после common lisp - насколько омерзительно и в чём именно?

openj9?

А, да. Это ж он на AOT сфокусирован. Я под нём эклипс на 2Гб планшете запускаю.

Понятия можно и функциями описать

Ну да. Набор методов класса или функций модуля — тоже своего рода DSL. Правда, без возможности запилить новый синтаксис, то есть более ограниченный.

Common Lisp жив, Tcl тоже. C++, Ruby и Rust вообще очень сильно распространены.

По первым двум ничего не скажу, хотя насчёт живости можно поспорить. Но в С++ метапрограммирование весьма специфическое и повсеместно им не пользуются.

В расте тоже возможности по созданию DSL весьма ограничены и те проекты, в которых этим увлекались, оставили неоднозначное впечатление. Ещё как-то смотрел сравнение ECS и там автор явно выделял в плюсы проекта, если там не злоупотребляют макросами. Мне кажется, что в языке в целом сложился подход когда к макросам прибегают только когда без них нельзя обойтись и стараются не злоупотреблять.

Хотя лично я не уверен, что «буйное метапрограммирование» - это плохо. Опять же, в расте этот инструмент специально сделан ограниченным - когда люди делают что-то сложное, то результат пугает неокрепшие разумы. В итоге мысль «макросы - крайняя мера» только закрепляется. Возможно, будь инструмент другим, то и воспринималось бы оно иначе. В прям мейнстримных языках действительно мощных макросов нет, но не уверен, что одно следует из другого.

Смущает версия 0.25.0. Он случаем не предназначен специально для Эклипса? Для полноты картины - была прекрасная российская компания Excelsior, гордость нации. И у них был коммерческий AOT компилятор Явы за 1500 долларов. Теперь она принадлежит Huawei.

Но мне казалось, что это впилили в мейнстрим. Или я ошибаюсь? Или это только в Оракле?

Это древняя IBM jdk, порт которой на Linux был сертифицирована на Java чуть ли не раньше оригинальной... Но это было четверть века назад.

Спасибо, надо попробовать.

Но в С++ метапрограммирование весьма специфическое и повсеместно им не пользуются.

Пользуются, начиная с stl: cout << "Hello" << endl — чистый DSL.

А в современном всякие enable_if, index_sequence и прочее.

В расте тоже возможности по созданию DSL весьма ограничены

Разве? Что там нельзя? Вроде процедурным макросом можно что угодно разбирать

let user_component = html!(div[
    h2["A list of users"]
    // Insert users in a unordered list
    ul[{ 
        users.iter()
            .map(|u| html!(li[u]))
            .collect::<String>() 
    }]
]);

Мне кажется, что в языке в целом сложился подход когда к макросам прибегают только когда без них нельзя обойтись и стараются не злоупотреблять.

Так это в любом языке с макросами так. Варьируется только значение «нельзя обойтись».

Опять же, в расте этот инструмент специально сделан ограниченным - когда люди делают что-то сложное, то результат пугает неокрепшие разумы.

??? Можно пример?

Хотя лично я не уверен, что «буйное метапрограммирование» - это плохо.

Я разделяю подход Racket: если что-то можно сделать функцией, лучше делать функцией, потому что её можно сохранить в переменную. Но макрос вокруг функции для упрощения синтаксиса — это хорошо.

Пользуются, начиная с stl: cout << «Hello» << endl — чистый DSL.

Пусть DSL, но не имеющий к макросам никакого отношения. Ну и стримы, вроде как, считаются не самой удачной идеей.

А в современном всякие enable_if, index_sequence и прочее.

Вот это уже ближе, да. Но я думаю, что ты не будешь спорить с тем, что «шаблонное метапрограммирование» - это отдельная часть языка, к которой далеко не все прибегают. Ну в целом это направление развивается не то чтобы прям сильно быстро. Есть всякие пропозалы вроде статической рефлексии, но дело движется медленно.

Что там нельзя?

Ну, например, сделать макрос без восклицательного знака. (:

??? Можно пример?

Например, всякие decl_module и decl_storage из субстрата.

Ну и в расте макросы далеко не идеально дружат с IDE.

Пусть DSL, но не имеющий к макросам никакого отношения.

В ruby тоже DSL не на макросах. Но, фактически, DSL.

А метапрограммирование не в операторе сдвига, а в реализации потоков.

Но я думаю, что ты не будешь спорить с тем, что «шаблонное метапрограммирование» - это отдельная часть языка, к которой далеко не все прибегают.

К ней и в Common Lisp далеко не все прибегают.

Ну и в расте макросы далеко не идеально дружат с IDE.

Гм… хорошо дружат с IDE только макросы Racket. Если нормально написаны.

Можешь предложить написание сайтов дешевле без всяких рельсов и прочих фреймворков?

До эпохи вездесущих спрингов и рельсов у каждой конторы был свой доморощенный «фреймворк». У многих и сейчас такое, и это обходится не дороже мегакомбайнов, которые имеют свойство раздуваться до неприемлимых величин или тихо умирать. Проблема этих скелетов в том, что это обычно типовой скелет бегемота. Когда люди допёрли до микросервисов, то сразу стала видна нелепость такого гигантизма.

Когда люди допёрли до микросервисов, то сразу стала видна нелепость такого гигантизма.

Микросервисы страдают гигантоманией гораздо сильнее. Потому что если функцию вытащили в микросервис, это значит, что добавили кучу накладных расходов на сериализацию/десериализацию/докер-контейнер + кучу библиотек, чтобы всё это как-то работало.

Доморощенный же фреймворк плох тем, что если появилась новая задача для сайта, то в типовом можно взять типовой модуль и чуть-чуть настроить, а в доморощенном надо сначала самому этот модуль написать.

Если не использовать монады и ленивое вычисление, проще не использовать Haskell

Большинство кодеров так и делает.

В SQL внутри SELECT тоже нельзя сделать вывод строки при чтении строки из таблицы. Ты им тоже стараешься не пользоваться?

SQL — это очень ограниченное решение. И его ограниченность много кому не нравится, отсюда идут расширения и вообще слабо похожие на SQL языки, а в сами клиент-серверные СУБД вводят возможность писать серверную логику на Java/C#, и даже Python/Tcl, как в PostgreSQL.

И да, я согласен, что хаскель сильно ограничивает программиста.

На чистые функции гораздо легче пишутся тесты

Тесты не помогут в разработке ненаписанного софта.

Пиши всё в IO и не парься. Тогда ничего просчитывать не надо

Какая-то такую цель и преследует MTL. Только зачем было усложнять язык с самого начала?

Common Lisp жив, Tcl тоже. C++, Ruby и Rust вообще очень сильно распространены

Отличная история, но я бы посоветовал вылезти из танка. CL мертв, Tcl почти мертв, Ruby нужен только в виде рельсов, в C++ метапрограммирование весьма ограниченное и полноценных макросов нет. Потому Rust — это единственный подающий надежды язык, однако же, его будущее неясно.

Был еще Nemerle, который представлял из себя F# с макросами — и он провалился.

Также как в Си иногда проще пропустить через cpp, чем искать во что раскрывается define. Но часто ли так делаешь?
К слову, для незнакомой функции быстро получить её раскрытый исходник (с инлайном всех не библиотечных функций) гораздо сложнее. Или для шаблона C++ получить во что он раскрывается

И сложные шаблоны крестов я тоже не приветствую, и бессмысленные однострочные функции. Но понять нестандартный макрос значительно сложнее, чем простой вызов функции. А если макрос делает то же, что делает вызов функции, то это уже не макрос и он не нужен.

Что проще читается:
(loop for i from 5 to 15 collecting i)
или
(let ((acc nil))
(dotimes (i1 11 (nreverse acc))
(push (+ i1 5) acc)))

Я не могу вспомнить языка, где нужно было бы поверх языка лепить самому for. Даже в хаскеле в базовой либе есть for. А теперь представь себе, что в твоем проекте кто-то сделал другую реализацию макроса loop-for. А если нельзя так делать и есть обязательства использовать единый язык, то зачем тебе какие-то фантазии про DSL? Да, иногда, очень редко, они нужны и полезны. Но если каждый будет лепить свои собственные циклы — это будет боль.

По идее DSL просто вводит новые понятия, которые позволяют тебе описывать решение твоей проблемы в соответствующих ей терминах, а не в терминах перекладывания байтиков с места на место. Что положительно сказывается на понятности кода, пример выше привели

Никто не отменял операции с AST и собственные фронтенды для LLVM. Другое дело, что они нужны весьма редко.

Разница только в том, что лисп может DSL сразу компилировать в код при компиляции программы, а в других языках приходится DSL делать в строке, а компилировать во время работы программы

Ничто не мешает сделать транслятор DSL в AST/IR/bytecode.

Ну да. Набор методов класса или функций модуля — тоже своего рода DSL. Правда, без возможности запилить новый синтаксис, то есть более ограниченный

Более того, в рамках лиспа синтаксис тоже весьма и весьма ограничен, а чтобы его расширить, нужно уже делать свой транслятор. Который можно сделать на любом ЯП.

Более того, в рамках лиспа синтаксис тоже весьма и весьма ограничен

В смысле ограничен s-выражениями? Но в рамках этого ограничения ведь можно резвиться как угодно, запиливать новые управляющие структуры и все такое.

На любом ЯП так не получится, я не могу самостоятельно запилить в JS, скажем, новое ключевое слово, нужно ждать, пока это сделают разработчики движка.

Я не могу вспомнить языка, где нужно было бы поверх языка лепить самому for.

Ну да, приходится как в C++ 10 лет ждать, пока это соизволят сделать авторы компилятора. Может ещё лет через 10 добавят collecting и accumulating из лиспа. Или велосипедить my_data_foreach(f) на каждую коллекцию.

А в Haskell линзы в качестве продвинутого for придумали.

Велосипедные макросы: Qt moc, Go generate.

А теперь представь себе, что в твоем проекте кто-то сделал другую реализацию макроса loop-for.

Для Common Lisp есть библиотеки iterate и snakes. Ах да, ещё hu.dwim.reiterate. Если кто-то их использует, никакого дискомфорта. Также как если внутри какого-то модуля на C++ используется QString. Главное, чтобы в пределах одного модуля было единообразие.

Какая-то такую цель и преследует MTL. Только зачем было усложнять язык с самого начала?

Чтобы добавить возможность писать чистые функции. И нормальный параметрический полиморфизм и ссылочную прозрачность. Если тебе это не нужно, тебе не нужен Haskell. Если нужно, альтернатив практически нет.

Был еще Nemerle, который представлял из себя F# с макросами — и он провалился.

Нынче провал языков определяется не языком, а пиаром языка (или крупной корпорацией за ним). Можно ещё Nim вспомнить. По всем параметрам лучше, чем Python, но корпорации продвигают Python (предоставлением библиотек).

Никто не отменял операции с AST и собственные фронтенды для LLVM.

Это если в компиляторе есть месту, где можно получить AST: покажешь, как это сделать в g++. А собственный фронтенд = собственный компилятор.

Ничто не мешает сделать транслятор DSL в AST/IR/bytecode.

Так этот транслятор и будет написанным на коленке обработчиком макросов. Препроцессор Си так и работает. Языки с макросами имеют только то преимущество, что макрос может вызывать функции самого языка.

Более того, в рамках лиспа синтаксис тоже весьма и весьма ограничен, а чтобы его расширить, нужно уже делать свой транслятор.

Нет. Достаточно сделать макрос чтения: получишь строку из программы, которую можешь преобразовать в AST лиспа. Полноценный транслятор делать не надо.

Для полноты картины - была прекрасная российская компания Excelsior, гордость нации. И у них был коммерческий AOT компилятор Явы за 1500 долларов. Теперь она принадлежит Huawei.

Спасибо за прекрасный пример.

Вот именно в этом и есть одна из главных причин, по которым я всем замышляющим написание российских ОС первым делом задаю вопрос: будет она свободной или проприетарной? Если второе — это будет всего лишь ОС какого-то дяди, который повесил на свою ОС лейбл «российская» и будет на этом пиариться, пока звание «российский» приносит ему дивиденды. Вне зависимости от фантазий тех, кто этот проект начинал.

Нет, кроме «свободная» и «проприетарная в руках дяди» теоретически есть ещё третий вариант — «проприетарная в руках государства». Не в руках какого-то олигарха, «друга государства» из десятки журнала Форбс, а именно в руках государства Российская Федерация. И положим, в СССР такое действительно могло бы быть, если бы СССР дожил до наших дней.

Но мы не в СССР. Мы в Российской Федерации, где государство тщательно избавляется от госсобственности во всём, в чём только может. Тот же АвтоВАЗ, напоминаю, окончательно сбыли с рук в 2013 году, за полгода до украинско-российского кризиса, санкций и всего вот этого вот. Даже большинство космических предприятий акционировали (за исключением Хруничева, и то там что-то непонятное мутили). Что бы там не говорили, идеология у государства сейчас рыночная. Разумеется, не рынка времён Адама Смита, а более нового. Поэтому чтобы рассуждать о государственной ОС в России, сначала надо общественный строй сменить. :) А пока что — два стула на выбор, см. выше.

не мешай человеку фантазировать о make russia great computer derzhava again )

Поэтому чтобы рассуждать о государственной ОС в России, сначала надо общественный строй сменить.

Так ведь есть государственная ОС в России, даже две: МСВС и Заря.

А метапрограммирование не в операторе сдвига, а в реализации потоков.

Можешь развернуть мысль?

Гм… хорошо дружат с IDE только макросы Racket.

Но всё-таки, насколько я понимаю, в лиспе для этого более удобные инструменты есть, чем те, которыми приходится пользоваться в расте.

Признаюсь честно: я на макросах чего-то прям сложного не делал, так что мог и упустить из внимание развитие инструментов, но вот тут предлагают пользоваться штуками, которые вообще в найтли только доступны. Ну и удобство такое себе. cargo-expand тоже выплёвывает кучу кода. И это всё ещё только о macro_rules. Когда мне надо было в процедурном макросе что-то поправить, то проще было прийти к человеку, который его писал и попросить подсказать.

Можешь развернуть мысль?

Если читать iostream, то там несколько слоёв шаблонов, которые в конце концов пакуются в компактный API.

в лиспе для этого более удобные инструменты есть, чем те, которыми приходится пользоваться в расте.

Если брать Common Lisp, то не особо. macroexpand — это тот же cargo-expand. В Racket лучше — там есть Macro stepper.

Когда мне надо было в процедурном макросе что-то поправить, то проще было прийти к человеку, который его писал и попросить подсказать.

А на лиспе не так?

ОС какого-то дяди, который повесил на свою ОС лейбл «российская» и будет на этом пиариться, пока звание «российский» приносит ему дивиденды.

Этих дядь копнёшь, то дивиденды конечно у дяди. А за ответственность так все сразу валят на связи из кремля у которого народные бюджеты. Или может только вокруг меня такие дяди концентрируются.

Был еще Nemerle, который представлял из себя F# с макросами — и он провалился.

Почему F#, а не C#?..

Ну и справедливости ради, взлететь этому языку было бы сложно: занимались им несколько энтузиастов, которые друг с другом не всегда договориться могли. Плюс пиарили его весьма специфически. Их ведь даже джетбрейнс в какой-то момент взяли к себе, но и там дело заглохло. Мне кажется, что совсем не в первую очередь по техническим причинам.

Да и в целом языки на дотнете не от майкрософт не особо взлетают, в отличие от JVM-языков.

А на лиспе не так?

Не знаю. (:

На лиспе не писал, если hello world не учитывать. Возможно, сложилось наивное впечатление, что там макросы - вполне себе «инструмент первого класса».

Почему F#, а не C#?

Потому что класс-ориентированный C# вообще не похож на Nemerle. Я понимаю, что F# в итоге все равно транслируется в классы, но в итоге любой язык во что-то там транслируется, и конечного программиста волнует только «из чего» он транслируется, а не «во что». В данном случае трансляция идет в байткод CLR, к слову, что не есть C#.

Возможно, сложилось наивное впечатление, что там макросы - вполне себе «инструмент первого класса».

В Common Lisp макросы почти один-в-один соответствуют процедурным макросам Rust. Даже чуть хуже: в Rust макросы гигиенические (идентификатор имеют контекст), а в Common Lisp идентификатор имеет только имя.

Макросы Racket эквивалентны макросам Rust, но в Racket компилятор умеет в помощь IDE делать частичное раскрытие макросов с сохранением контекста.

В смысле ограничен s-выражениями? Но в рамках этого ограничения ведь можно резвиться как угодно, запиливать новые управляющие структуры и все такое

Ты не задумывался никогда, почему божественные скобочки лиспа променяли на отступы питона?

На любом ЯП так не получится, я не могу самостоятельно запилить в JS, скажем, новое ключевое слово, нужно ждать, пока это сделают разработчики движка

Вполне сбее запиливают новые ключевые слова, и используют трансляторы для преобразования в ванильный JS.

почему божественные скобочки лиспа променяли на отступы питона?

Кто променял? Существует SweetExpressions добавляющий в лисп синтаксис типа:

defun fibup (max count n-1 n-2)
 if {max = count}
    {n-1 + n-2}
    fibup max {count + 1} {n-1 + n-2} n-1

Популярностью не пользуется.

На отступы питона променяли божественные скобочки Си, унаследованные перлом и PHP.

Вполне сбее запиливают новые ключевые слова, и используют трансляторы для преобразования в ванильный JS.

Транслятор хорош до первой ошибки. Когда ты видишь, что ошибка в строке 42, но тебе надо угадать, какая это строка в исходнике.

Ну да, приходится как в C++ 10 лет ждать, пока это соизволят сделать авторы компилятора. Может ещё лет через 10 добавят collecting и accumulating из лиспа. Или велосипедить my_data_foreach(f) на каждую коллекцию

Проблема C++ была именно в отсутствии удобных механизмов описания этих самых foreach, вроде тех же лямбд. Подобную фундаментальную штуку и в лиспе не так-то просто ввести. Например, давай мне сделай динамическое связывание для идентификаторов замыканий в лиспе с лексическим связыванием. Вон, посмотри какую содомию придумали авторы eLisp, в котором не было лямбд с лексическим связыванием.

Чтобы добавить возможность писать чистые функции. И нормальный параметрический полиморфизм и ссылочную прозрачность. Если тебе это не нужно, тебе не нужен Haskell. Если нужно, альтернатив практически нет

Мне нужно писать программы. Люди не пользуются параметрическим полиморфизмом, ссылочной прозрачностью, чистыми функциями — люди пользуются работающими програмами.

Был еще Nemerle, который представлял из себя F# с макросами — и он провалился

Нынче провал языков определяется не языком, а пиаром языка (или крупной корпорацией за ним)

Даже не пиаром языка, а именно крупной корпорацией. И все-таки за Nemerle были корпорации, мелкие, но были. Не помогло.

Это если в компиляторе есть месту, где можно получить AST: покажешь, как это сделать в g++. А собственный фронтенд = собственный компилятор

Проблема конкретно C++ заключается в том, что его очень тяжело парсить, потому не так-то просто встроиться в его парсер. Но есть попроще языки.

потому не так-то просто встроиться в его парсер.

Так есть же готовые парсеры. Просто они не дают встроиться, да.

Но есть попроще языки.

То есть речь идёт не про встроиться, а про написание половины компилятора. Проще тогда вообще не разбирать, а работать со строками, как делает cpp или m4.

Так этот транслятор и будет написанным на коленке обработчиком макросов. Препроцессор Си так и работает. Языки с макросами имеют только то преимущество, что макрос может вызывать функции самого языка

Еще раз:

clojure после common lisp - насколько омерзительно и в чём именно? (комментарий)

DSL — зло, которое лишь изредка может быть оправдано большей пользой

Написанные на окамле парсеры превращают исходные коды, внезапно, в структуры самого языка окамль. И в чем проблема? Ты возразишь мне, что на лиспе при этом можно применять обычные функции к полученному отпаршенному коду вместо функций окамля, однако же, сама работа с AST по сути передставляет собой иной мир с иными правилами, потому требует наличия DSL, отличного от языка, используемого для написания низкоуровневых прикладных алгоритмов.

В том же JS, однако, исходный текст DSL превращается в объекты JS и дальше транслируется в JS — зачем им твой лисп?

Нет. Достаточно сделать макрос чтения: получишь строку из программы, которую можешь преобразовать в AST лиспа. Полноценный транслятор делать не надо

Макрос чтения — это и есть транслятор. Такой же, как можно написать на Си, JS, OCaml.

Написанные на окамле парсеры превращают исходные коды, внезапно, в структуры самого языка окамль.

В том же, в чём проблема нормального for в C++: если в конкретной программе понадобится этот парсер чуть-чуть расширить, надо взять исходник на OCaml, отредактировать и перекомпилировать.

А если парсер в виде макроса, то его можно доопределить сразу по месту для конкретной программы.

Макрос чтения — это и есть транслятор. Такой же, как можно написать на Си, JS, OCaml.

Только макрос чтения имеет доступ к функциям готового транслятора. Поэтому их не приходится писать повторно.

Существует SweetExpressions добавляющий в лисп синтаксис типа

Ну это же не макросы лиспа, а отдельный язык с отдельным парсером в лисповые структуры. В частности, в лиспе бида-бида с инфиксными операциями — в том числе эту проблему попытались пофиксить в SweetExpressions.

На отступы питона променяли божественные скобочки Си, унаследованные перлом и PHP

В Си/Perl/PHP точки с запятой используются намного чаще скобочек.

Транслятор хорош до первой ошибки. Когда ты видишь, что ошибка в строке 42, но тебе надо угадать, какая это строка в исходнике.

У меня в Vue.js ошибка выдается на исходную строку кода.

Ну это же не макросы лиспа, а отдельный язык с отдельным парсером в лисповые структуры.

Как это не макросы???

Обычные макросы: https://github.com/rebcabin/readable-lisp/blob/master/sweet.lisp

Включается синтаксис через

(asdf:load-system :readable)
(setq *print-escape* nil)
(setf (readtable-case *readtable*) :invert)
(readable:enable-sweet)

То есть речь идёт не про встроиться, а про написание половины компилятора. Проще тогда вообще не разбирать, а работать со строками, как делает cpp или m4

Ну кто же виноват в том, что C/C++ так плохо транслируются? Под паскаль, например, есть куча парсеров, и пишутся они очень просто:

https://wiki.freepascal.org/Make_your_own_compiler,_interpreter,_parser,_or_e...

В частности, в лиспе бида-бида с инфиксными операциями

Они тоже есть ещё с 1995 года. И тоже никому не интересны кроме неофитов.

У меня в Vue.js ошибка выдается на исходную строку кода.

А там разве JavaScript расширяется новыми операторами?

если в конкретной программе понадобится этот парсер чуть-чуть расширить, надо взять исходник на OCaml, отредактировать и перекомпилировать

И всё? Тебя не устраивает, что ты не можешь по десять раз на дню изменять свой язык?

Только макрос чтения имеет доступ к функциям готового транслятора. Поэтому их не приходится писать повторно

Транслятор, написанный на Си, имеет доступ к функциям стандартной либы и либы парсера. И чем функции специфичнее для трансляции, тем меньше шанс, что их можно будет использовать в цели трансляции, но и тем меньше шанс, что они там вообще будут нужны. А если цель — тоже программа на Си, то там тоже есть стандартная либа и твои сишные либы.

Обычные макросы: https://github.com/rebcabin/readable-lisp/blob/master/sweet.lisp
Включается синтаксис через

Обычные макросы?

; We can't portably overide "read" directly, we have to manipulate
; the readtable to implement sweet-expressions.
; This readtable basically redirects EVERY character to a specific procedure,
; effectively taking over "read":
(defvar *sweet-readtable*
  "This table redirects any input to sweet-expression processing")

Оно перехватывает штатный REPL.

И всё? Тебя не устраивает, что ты не можешь по десять раз на дню изменять свой язык?

Так суть макросов как раз в этом. Везде, где в обычных языках приходится использовать копирование/вставку, её можно заменить макросом.