реализующий идеи Common Lisp и CLOS в более привычном синтаксисе без скобочек

чего только не сделают, лишь бы не юзать емакс с функцией подсветки соответствующего элемента

OCaml использовать не пробовали? Создаётся впечатление, что творцы этого поделия про OCaml даже не слышали, но зато переизобрели многое оттуда.

Каким образом ты сопоставил окамль и «динамический язык программирования, реализующий идеи Common Lisp и CLOS в более привычном синтаксисе без скобочек.» ?

творцы этого поделия про OCaml даже не слышали

Конечно не слышали, ведь Dylan появился раньше.

чего только не сделают, лишь бы не танцевать голой задницей на углях

починил

Интересно. И давно ли? И если он такой древний, то почему такой мёртвый?

Список изменений, конечно, впечатляет. За 5 лет-то.

давно ли?

С 1992 года

если он такой древний, то почему такой мёртвый?

Для OCaml вопрос так же актуален

Окамл используется в коммерческих структурах. Под него регулярно пишут библиотеки, хотя бы те же Батарейки, всего около 400 живых проектов. К нему есть биндинги для ряда общеизвестных либ вроде lapack, gsl, plplot, gtk2, причём они поставляются в пакетированном виде во многих дистрибутивах. Наконец, регулярно выходят новые версии компилятора. Да, это не самый популярный, быстрый и продвинутый язык, но он точно живой. На нём, кстати, часто пишут компиляторы на начальной стадии.

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

реализующий идеи Common Lisp и CLOS в более привычном синтаксисе без скобочек

Чего только не сделают, чтобы скобочки не писать!

а мне скобочки нравятся

Вот это поворот.

Скобочки и в Objective-C есть!

А что там с асинхронной многопоточностью? Даже в горбатом CL и то вроде есть.

Кто-нибудь может объяснить мне почему у лиспа такое огромное количество диалектов? Даже не почему, а зачем?

Как разработчик на Ruby скажу: скобочки и разделители строк - портят внешний вид твоего быдлокода. Вот убрали бы из питона "():" - это был бы самый красивый синтаксис :)

Вся суть в скобочках!

«Красота» - понятие относительное.

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

Его легко реализовать и каждый видит его хорошим по своему.

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

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

А ты на каком языке пишешь, Одалист? Ты программистом работаешь?

«Красота» - понятие относительное.

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

С тех пор каждый школьник пишет свой лисп

Rober, вот лучше бы в доту играли

нам и аниме кажется красивым

Пойдешь со мной в субботу в сауну?

Чем они помешали?

«К несчастью злые хакеры украли последний мегабайт кода жутко секретной программы на Лиспе, к счастью там были только закрывающие скобки.»

если он такой древний, то почему такой мёртвый?

Для OCaml вопрос так же актуален

https://reasonml.github.io/ru/ — стильная, модная, молодёжная инкарнация окамла.

https://github.com/revery-ui/revery — гуйня под это дело

А subj — да, музейный экспонат, новость выглядит почти как новость о выходе очередного релиза Algol68G (а ведь наверное ещё будет такой релиз, крайнему — меньше трёх лет)

Если писать говнокод, где всё в одной простыне, то лисп как бы и не при чём.

Известный пример на lua — дефолтный конфиг awesome

Как не пиши, все равно куча скобочек, и их надо считать еще.

Окамл используется в коммерческих структурах.

В каких?

Как не пиши, все равно куча скобочек

А что, в JS или C++ фигурные скобочки куда-то делись? То что я запостил на lua, это жутко неидеоматично, так то в lua (end-ы без begin-ов) скобочек мало, но, как видишь, и из lua при желании можно сделать стукнутую по голове Clojure с кучей скобочек нескольких видов.

и их надо считать еще

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

Окамл используется в коммерческих структурах.

В каких?

Facebook как минимум, судя по сайту ReasonML.

А что, в JS или C++ фигурные скобочки куда-то делись?

Да, их скрыли за нормальным, человеческим синтаксисом.

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

Но редактировать все равно неудобно.

реализация ISLISP

этот автор пишет книжки по лиспу, прологу, ардуине и роботам.

есть реализация ISLISP под названием Easy-ISLisp, исходники на гитхабе, рядом лежит реализация пролога opl

примеры исходников на ISLISP: по ссылкам отсюда, вторая половина ссылок отсюда, блог по тегу ISLISP

ISLISP — это реализация лиспа, альтернативная Scheme и Common Lisp. там есть: ILOS, объектная система как в CLOS; более точный и понятный стандарт; выведение типов и более простая компиляция, чем в CL.

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

ещё есть открытые OK!ISLISP, TISL и прочие.

вот, недавно и Easy-ISLISP открыли исходники, есть книжки (всё на японском, конечно же).

примеры кода на ISLISP: раз два, три

отличия ISLISP от Common Lisp

в целом, Easy-ISLISP занятная реализация: реализован вывод типов, есть компиляция в си и связь с си FFI (см. примерытут, тут либо на гитхабе)

в общем и целом: Easy-ISLISP неплохая реализация ISLISP. сам по себе ISLISP (Easy-ISLISP, OpenLisp) — неплохая реализация лиспа, встраиваемого в си, транслируемого в си, объектно-ориентированного в духе CLOS.

реализация пролога и лиспа занятная. ещё у него где-то в примерах есть реализация схемы на ISLISP, довольно компактная. а в примерах пролога — лисп на прологе, парсер DCG грамматик в несколько строк, пролог на прологе.

ну, и чтоб два раза не вставать: MonaOS гитхаб — ОС на схеме MoSH

Euslisp EusLisp,гитхаб обучалка по установке и примерам старое, обучалка — среда программирования роботов на CommonLisp (на гитхабе появляются плагины к ROS, assimp, collada и прочему, визуализация в примерах простая, язык не совсем CL)

Первыми полагается вспоминать Jane Street

Я про фигурные. Которых в JS/C++ будет ровно, как в аналогичном лисп-коде, за минусом текста выражений (в смысле expression). А в эти самые экспрешены, чтобы обеспечить условный оператор внутри, ввели такое уродство, как тернарный оператор.

В тех, которые пишут роботов, чтобы на бирже играть.

Там во первых разные скобки, а во вторых их будет намного меньше.

скорее из Dylan слизали ряд идей в Swift.

а мёртвый потому что ему не повезло. Apple Research ( Apple Cambridge ) изобрело лисп с алгольным синтаксисом, Dylan. думало, что это будет такой дельфи, только на самом деле лисп. примерно в то время, когда был Newton, ноутбук J-L. Gasse и прочее. потом пришли эффективные менеджеры и все R&D проекты зарезали. к тому моменту у них было 2 реализации компилятора (Gwydion и Harleqiun), часть IP выкупило LispWorks и пыталось продавать в конце 90х-начале 2000х, сделав упор на кроссплатформность. не взлетело: когда дельфи с батарейками стоил $800, тут предлагали отдельно $1500 среду и отдельно за 500..1500$ батарейки. хотя GUI там вариант CLIM, IDE позволяет строить GUI в REPL, программу можно в отладчике поставить на паузу и поковыряться в REPL, затем перезапустить рестарты, и прочее.

при этом из dylan программы генерировался исходник на си, компилировалось си компилятором. FFI, батарейки, модульная лисп-система в куче нескольких отдельных dll-ек. то есть можно например компилятор в dll-ку не включать для production, для dev может быть другой набор dll-ек.

потом с gwydion dylan стало хз что. вроде бы он перестал собираться под 64 бита, вроде бы там что-то допилили, но в целом среда сборки довольно хрупкая — на перле даже не cons, а свой велосипед. из плюсов — элементарно портируется под новые платформы. из минусов — среда сборки хрупкая, где её там донастроить в конфигах не совсем очевидно.

а Apple Dylan стал Lispworks/Harlequin/Functional Objects Dylan, потом примерно в 200х году открыли исходники. собирался под визуал студией, pelles C и gcc, mingw. компилятор там был свой специфический, даже два. один с нативным кодогенератором, написанный сам на себе. другой кодогенерировал через си компилятор. в первом по-моему только x86-32, 64-битность делали тогда через си компилятор.

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

рад, что они вроде как допилили нормальный LLVM бекенд.

И сколько там их? 2 калеки?

Ясно торгаши сломали хороший проект из за жадности как там был язык с контрактами....

Ну вот только за счёт текста выражений. При том, что в C и потомках отказались от удобной концепции «всё есть выражение» (если не говорить про «всякие лиспы» в Algol-68 она уже есть, как есть и возможность писать вместо управляющих структур скобочки специального вида). Чтение оно может и упрощает (хотя как сказать — многословие в стиле java — точно нет) но не написание кода. А вообще, подозреваю, можно, к примеру, на макросах КоммонЛиспа сделать компиляцию инфиксных выражений. Да и в Racket есть Algol-60 как один из входных языков поверх лисп-ядра.

Главный калека известен в мире JavaScript как разработчик React.

Всё же между Алголом 60 и Алголом 68 огромная пропасть. Первый — достаточно удачный и современный язык для своего времени. Второй — монстр, в котором есть всё, в том числе много того, чего до сих пор нет в современных языках.

Ну вот только за счёт текста выражений.

Ну так компактнее же намного выходит.

При том, что в C и потомках отказались от удобной концепции «всё есть выражение»

Чем она удобна?

А вообще, подозреваю, можно, к примеру, на макросах КоммонЛиспа сделать компиляцию инфиксных выражений.

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

Кто-нибудь может объяснить мне почему у лиспа такое огромное количество диалектов? Даже не почему, а зачем?

1. исторически так сложилось. потому что программируемый язык программирования. каждый набор макросов уже диалект. другая объектная система — ещё один.

2. Гай Стил и Сассман писали схему. потому что увлекались акторами и self, обернули их в лямбда исчисление. оттуда эта идея про единое пространство имён, замыкания как объекты. потом добавили гигиены в макросы и понеслась, ещё один диалект.

3. Common Lisp получился, когда стандартизировали диалекты различных InterLisp, MacLisp, Multics Lisp, Lisp 1.5. поэтому он получился такой абстрактный, комитет напроектировал как бы всем угодить в исторически сложившиеся наборы макросов, объектных систем. типа Flavors, Common Objects и прочие, с посылкой сообщений. потом CLOS, MOP и рефлексия в рантайме. наиболее гибкое, универсальное. но и накладные расходы на метауровень, мульти диспетчеризацию.

4. потом в 80-х годах в Европе делают Le Lisp, EuLisp, XLISP и прочие. гибрид схемы и CL, упрощённый. тот же XLISP на базе которого AutoLisp что в автокаде. воткнули затычку сращенную с базой данных. временное оказалось на постоянное.

5. японцы в 90-х экспериментируют с прологом, лиспом, компьютерами 5 поколения. делают встраиваемый лисп. сначала Kyoto Common Lisp и прочее, откуда ноги растут у ECL, MKCL. лисп генерирует си код, собирается си компилятором. в целом, проблему интеграции с си батарейками FFI, а также лисп-образа и си dll-ек и батареек — решили.

6. японцы в 90х пытаются упростить Common Lisp, который сложный, громоздкий, стоглав и лаяй. ISO комитет стандартизирует новый лисп, который бы имел чёткую семантику, first class objects объектную систему, допускал эффективную компиляцию и решение ромбовидного наследования, например. получается ISLISP, у которого спецификация страниц 60 (в отличие от 1300+ страниц как в CLtL, + MOP тоже довольно объёмный). ILOS, объектная система ISLISP — по образу и подобию CLOS, есть в стандарте языка, а не библиотекой. все формы являются объектами конкретных типов. минимизировано по сравнению с CL количество специальных форм, и оговорок специальных случаев. в целом ISLISP, более ортогонализированый, понятный, и разумно структурированный, более продуманный стандарт чем CL.

реализация ISLISP есть например внутри BricsCAD. по-моему, это OpenLisp.

7. отдельные реализации спокойно себе живут на LISP 1.5 или около того: PicoLisp, тот же XLISP, ещё какой лисп для обработки статистики, newlisp и т.п. у них свои отдельные преимущества, например PicoLisp сращен с базой данных (читай про RAD radical approach и примеры), позволяет элементарно дёргать си функции через .so .dll.

Lush например, реализация из которой раскрутили DjVu. написали программу распознавания отсканированного, на нейросетях. на лиспе. затем этот лисп Lush использовали в качестве шелла, для того чтобы прикрутить GUI, для того чтобы разработать документацию в litprog стиле. затем, когда прототип отладили — взяли и медленные места lush интерпретатора заменили на откомпилированные, скодогенерированные в си, или переписанные в си руками версии. сам lush относительно прозрачно позволяет заменять такие реализации. например, откомпилировать код на лиспе кодогенерируя си версию, собрать её в .so .dll и подгрузить и выполнить через dlopen.

всё тоже самое позволяет и lush, picolisp, twinlisp, и прочие, scheme и прочие реализации.

8. kernel — ещё одна интересная реализация лиспа (схема) на vau-expressions. в плане «ортогонализации» и минимализации стандарта.

9. в SICL ведётся некая работа по RFC, в плане доработки стандарта CL. Clasp это реализация CL на LLVM, вроде бы неплохо умеет компилировать и оптимизировать. в каком-то смысле пытаются сократить трудоёмкость реализации, продумать и упростить стандарт. но так радикально, как в ISLISP у них не получается.

лиспы разные нужны, лиспы разные важны

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

Кажется уже нет. Всё что есть в Algol68 есть во многих современных языках, наверное не так сложно найти и такой язык, где есть всё это.

Ещё в A68 нет ООП (а в Симуле, которая расширенный алгол-60 — есть). И достаточно неудачно сделано взятие элемента структуры (field of record вместо record.field) что, даже если слепить какое-то ООП из того что есть, будет не только жутко непривычно выглядеть, но и мешать сделать автодополнение в IDE.

и их надо считать еще.

Зачем?

Что бы поставить ее где надо, и не поставить там где не надо. Вставлять какой нибудь код в середину это вообще каеф, надо найти вершину блока, progn вставить, итд...