Какой Lisp лучше в каких случаях и почему? И вообще в чём принципиальна разница между ними.

Вся прекрасность лиспа в том, что лисповая программа может работать в терминах маш.кода, и это не слишком по внешнему виду отличается от GAS-вставок в GCC или Watcom - смотри исходники бакэндов у SBCL, например. А может быть и рекурсивными макросами. Или совсем нифига не лиспом, и даже не для последовательного исполнения на обычно процессоре, а какой-то параллельный DSL для ПЛМ-железки.

Это ты так многословно сказал «Lisp можно скомпилировать в разные цели»?

Первый раз такое вижу. В среднем больше одного неправильного предположения на предложение.

Судя по комменту ниже твоего, он для первой группы первороден =)

Что ты пришел такой деловой и правильный как всегда, у нас тут пятница, лиспера вот понесло так, что теперь это не тред а просто праздник. Наслаждайся!

Я тот ещё затейник ::)

Неа. Нет подвижек.

Это ты так многословно сказал «Lisp можно скомпилировать в разные цели»?

У тебя как-то непонятно и даже не по-русски получилось :)

Смотря какой лисп. CL - прекрасен почти во всех аспектах.

Я елисп использовал, а зачем нужны остальные? И нужны ли?

Ну, тогда это какие-то бесполезные стандарты, если они никому не нужны.

Тред про лисп и такой мелкий

Мы тут интеллигентно )

Тащемто CL — единственный из перечисленных имеет две успешные коммерческие реализации. Так что сам думай на чём предпочитают писать лисперы-профи.

Common Lisp разрабатывался и используется в предположении, что пользователь программы — программист. Поэтому в языке мощнейший отладчик, позволяющий без остановки программы переопределять функции и вообще делать что угодно.

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

И многим юзерам-непрограммистам пригодится такая возможность?

Clojure: привязка к JVM, много синтаксического сахара.

То есть ещё два типа скобок для структур данных это много синтаксического сахара?

И опять же по поповду привязки, Clojure is designed to be a hosted language. И это одно из ключевых качеств Clojure

То есть ещё два типа скобок для структур данных это много синтаксического сахара?

Конечно. В два-три раза больше, чем у остальных участников сравнения.

И опять же по поповду привязки, Clojure is designed to be a hosted language.

То есть, кложура изначально спроектирована привязанной к JVM?

Ну монк так и написал: привязка к JVM.

И это одно из ключевых качеств Clojure

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

То есть, кложура изначально спроектирована привязанной к JVM?

Наоборот, она спроектированна быть привязанной к любой платформе и на данный момент имеет две активные реализации, а именно Clojure и ClojureScript

В смысле, кложура не может и никогда не будет отвязана от JVM

Конкретная реализация Clojure под JVM не может и никогда не будет отвязана от JVM

Наоборот, она спроектированна быть привязанной к любой платформе

Хм, загуглил «Clojure is designed to be a hosted language». Полная цитата:

Clojure is designed to be a hosted language, sharing the JVM type system, GC, threads etc.

Как она, с учётом «sharing the JVM type system, GC, threads etc» может быть отвязана от JVM?

ClojureScript

Так это не host, а target-платформа. Чтобы откомпилировать ClojureScript, всё равно нужна JVM и Clojure.

Наоборот, она спроектированна быть привязанной к любой платформе

Похоже, неправда ваша. Clojure спроектирована (с одним «н», кстати) привязанной к JVM. Это и заложено во фразе «Clojure is designed to be a hosted language».

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

Конкретная реализация Clojure под JVM не может и никогда не будет отвязана от JVM

Единственная существующая реализация Clojure привязана к JVM. Причём «это одно из ключевых качеств Clojure». Так что других реализаций, вероятно, никогда и не будет, потому что отвязывать кложуру от JVM весьма трудоёмко и вряд ли кому-то нужно.

Ещё раз, это конкретная реализация, которая привязана к JVM, помимо этой реализации из мне известных ещё есть https://github.com/clojure/clojure-clr, https://github.com/clojerl/clojerl

Чтобы откомпилировать ClojureScript, всё равно нужна JVM и Clojure

Это не обязательно на самом деле

Если вы хотите от меня услышать, что Clojure всегда будет привязана к кой-либо платформе, то это абсолютно верно, будь это JVM, CLI или любая другая

Ещё раз, это конкретная реализация, которая привязана к JVM, помимо этой реализации из мне известных ещё есть https://github.com/clojure/clojure-clr, https://github.com/clojerl/clojerl

Ок, я был неправ. Вижу, есть реализации Clojure, не привязанные к JVM.

Чтобы откомпилировать ClojureScript, всё равно нужна JVM и Clojure

Это не обязательно на самом деле

Любопытно. Не обязательно чисто теоретически? Или уже на практике кто-то компилирует ClojureScript в JS не устанавливая JVM в систему?

https://github.com/anmonteiro/lumo может такое делать, есть ещё что-то, но я не особо интересуюсь ClojureScript

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

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

Поэтому в их узком понимании языки отличаются количеством конструкций для циклов и условных операторов.

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

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

Call/cc и статическую типизацию с типизированными коллекциями в CL добавишь? Или гигиенические макросы? Да хотя бы разрешить методам CLOS иметь разное число аргументов (как у перегружаемых функций в C++).

Но когда у тебя синтаксис жесткий и топорный, да еще и не расширяемый

Не расширяемых синтаксисов не бывает с 1977 года, когда придумали m4.

То есть ещё два типа скобок для структур данных это много синтаксического сахара?

В смысле, вектор и хэш? Кроме них

#{...}
#"..."
#(... % %2 %4 ...)
#'
##
#inst
@x
^{:debug true}
::x
#::{:a 1, :b 2}
#:x{:a 1, :b 2}
a/b
a$b
a#
#?(...)
#?@(...)
x,

Может что-то пропустил.

А разницы между диалектами лиспа нет никакой, ибо они одинаково не нужны

Лорчую.

Call/cc и статическую типизацию с типизированными коллекциями в CL добавишь? Или гигиенические макросы? Да хотя бы разрешить методам CLOS иметь разное число аргументов

Судя потому что в DrRacket для подсветки синтаксиса и автозаполнения кода нужно нажать кнопку, а в процессе ввода кода всё это почему-то работать не способно, все перечисленные тобой фичи годны только для написания 100500-й реализации Кобола.

А вот в CL помимо Slime есть Allegro IDE и LispWorks IDE, которые практически идеальны.

Судя потому что в DrRacket для подсветки синтаксиса и автозаполнения кода нужно нажать кнопку, а в процессе ввода кода всё это почему-то работать не способно

ЩИТО??? Работает, вообще-то. C 2011 года

А вот в CL помимо Slime есть Allegro IDE и LispWorks IDE, которые практически идеальны.

Хоть один из них может показать все использования переменной?

Для фанатов Slime у Racket есть Geiser. Имеет тот же интерфейс, только позволяет ещё и изображения в текст вставлять (в том числе как значения переменных).

https://docs.racket-lang.org/reference/reader.html не сильно меньше

...кроме ITA/QPX например

Для сравнения https://clojure.org/reference/reader

Вот C можно считать «диалектом» C++ (не наоборот!), потому что компилятор C++ может переварить сишный код

На самом деле не сможет.

Call/cc и статическую типизацию с типизированными коллекциями в CL добавишь?

Call/cc напрямую не добавить, вроде, но в диалекте где не будет работать unwind-protect можно.

Статическую типизаций коллекций (своих) вполне, как часть статически типизированного диалекта, например.

Гигеенические макросы тоже не проблема: http://www.ccs.neu.edu/home/dorai/mbe/mbe-lsp.html

Не расширяемых синтаксисов не бывает с 1977 года, когда придумали m4.

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

Вот кстати. Как ты думаешь, а ради чего можно было бы пожертвовать гомоиконностью? А расширяемостью?

По-моему, вопрос интересный.

Дахе можно канпелировать их одним канпелятром

ноуп

В моем понимании синтаксическая расширяемость это главная фича языка в долгосрочной перспективе (думаю возраст лиспа это подтверждает).

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

Я не совсем понимаю как какая-то фича может требовать отсутствия расширяемости чтобы нужна была жертва, скорее наоборот, если у тебя в языке есть крутая фича но выразить ее просто ты не можешь - это требует жертв. Вспомним опять же питон, в котором лямбды принисены в жертву (негибкому) синтаксису.

Также как и диалекты Си++: Java, Javascript, Go, Rust. Попробуй из них слепить один язык, хотя синтаксически они похожи.

Херня. Вообще не похожи.

Ну что это за херня? Как на этом писать? Как читать потом код? Там даже на читаемом языке - жопа, а тут ехали скобочки через скобочки.

Примером расширяемости (если мы её понимаем одинаково) без лисповой или ребольной гомоиконности наверно будет Template Haskell. И вообще все языки, где есть нетекстовые макросы.

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

Я просто допускаю, что нужность сахаров здесь и сейчас ценой универсальной расширяемости может перевесить. Ведь потенциал к расширению всё равно остаётся (плюсы нам это показывают), хоть и чем дальше, тем более франкенштейн.

Да, язык в таком случае станет не вечным. Но ведь ассемблер можно изобрести один раз. Лисп, как репрезентация АСТ - этой такой же ассемблер, только уровнем выше, «ассемблер синтаксиса». И есть у меня подозрение, что сама гомоиконность накладывает ограничения: интуитивно понятно, что гомоиконных языков можно придумать меньше, чем негомоиконных.

но в диалекте где не будет работать unwind-protect можно

Но «легко» его из CL не сделать. Только переписывая компилятор.

Статическую типизаций коллекций (своих) вполне, как часть статически типизированного диалекта, например.

Опять же, только переписывая компилятор.

Гигеенические макросы тоже не проблема: http://www.ccs.neu.edu/home/dorai/mbe/mbe-lsp.html

Ты сам это читал? «Common Lisp implementation does not provide hygiene. There are two ways out: ... A better alternative is to use a generated symbol that is guaranteed not to clash with anything Lisp or you can come up with before or after. To introduce this gensym, mbe.lsp provides a with-wrapper for the expansion pattern.». То есть они честно признались, что гигиену к CL прикрутить невозможно.

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

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

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

Можно так:

macro for (init, cond, change, body)
{
  <[ 
    $init;
    def loop () : void {
      if ($cond) { $body; $change; loop() } 
      else ()
    };
    loop ()
  ]>
}

В моем понимании синтаксическая расширяемость это главная фича языка в долгосрочной перспективе (думаю возраст лиспа это подтверждает).

А возраст Фортрана что подтверждает?

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

Гомоиконность уже ограничивает расширяемость. Запрещены любые негомоиконные синтаксисы.

Правильная расширяемость у Racket. Допустимыми синтаксисами являются:

#lang honu
for x = 1 to 10 do {
 var y = x + 1;
 printf("x ~a y ~a\n", x, y)
}

#lang racket
(for ([x (in-range 1 10)])
  (define y (+ x 1))
  (printf "x ~a y ~a\n" x y))

#lang planet dyoo/bf
++++++[>++++++++++++<-]>.
>++++++++++[>++++++++++<-]>+.
+++++++..+++.>++++[>+++++++++++<-]>.
<+++[>----<-]>.<<<<<+++[>+++++<-]>.
>>.+++.------.--------.>>+.

В моем понимании синтаксическая расширяемость это главная фича языка в долгосрочной перспективе

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

Я не совсем понимаю как какая-то фича может требовать отсутствия расширяемости

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

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

Гейзер не нужен. Если только для guile, etc... У ракетчиков есть прекрасный racket-mode https://github.com/greghendershott/racket-mode

Правильная расширяемость у Racket.

Плюсую. Единственная платформа, где метапрограммирование реализовано по уму.

Примером расширяемости (если мы её понимаем одинаково) без лисповой или ребольной гомоиконности наверно будет Template Haskell.

Haskell, с учётом его ленивости, и без TH вполне расширяемый язык. А чисто синтаксические конструкции в нём вообще неплохо бы свести к минимуму. Та же if then else, например, не нужна, поскольку вполне заменяется функцией.