Какую реализацию Lisp учить?

Берись за теорию категорий категорий - будет интереснее

> Берись за теорию категорий категорий - будет интереснее

извиняюсь за неровный подчерк

> извиняюсь за неровный подчерк

... пишу на спине убитого товарища^W лиспера, он ещё дергаётся.

Common Lisp.

Как наиболее практичный из лиспов.

Боюсь, Clojure будет ещё практичнее, если ничего не имеете против jvm или .net.

> Боюсь, Clojure будет ещё практичнее, если ничего не имеете против jvm или .net.

Имеем. jvm и .net - тормоза.

> Имеем. jvm и .net - тормоза.

Но практичность же!

+1 к Common Lisp

Qi очень хороший вариант, по крайней мере задумка.

Common Lisp хорошо поддерживает обычное императивное программирование и ООП, по нему много литературы.

Clojure - лучше поддерживает функциональное и конкурентное программирование, чем Common Lisp. В кложе макросы чуть поудобнее и очень простые и удобные базовые структуры данных - вектора, хэши и т.п., и она такая же практичная, как Java. Но - мало литературы (одна книга вышла, 2 - на подходе), она вся на английском.

Так что, учи оба.

Common Lisp

Common Lisp хорошо поддерживает обычное императивное программирование и ООП,

И метапрограммирование. А ООП в нём такое, что зашатаешься.

по нему много литературы.

И шарящих людей. И совершенно разных компиляторов, от сурового энтерпрайз типа Аллегро или ЛиспВоркс, до эмбедида.

Clojure - лучше поддерживает функциональное и конкурентное программирование, чем Common Lisp.

Оно работает на jvm (и .net, если допилили), и в нём больше сахара прямо из коробки. Причём, кложура выше жвм прыгнуть не может, а в том же SBCL компилятор прямо из программы курочить можно.

Но ведь Qi мертв?
Common Lisp или Scheme по сравнению с ним очень даже живо выглядят
И вообще есть еще языки и с метапрограммированием, и с функциями как объектами первого класса, и с идентичностью кода и данных. Например, tcl

Но ведь Qi мертв?

Opensource не может быть мёртвым. Просто на данный момент им никто заниматься не хочет.

>И вообще есть еще языки и с метапрограммированием, и с функциями как объектами первого класса, и с идентичностью кода и данных.

И какие лиспы есчё имеют статическую типизацию? Ведь хороший лисп - лисп с типизацией.

PS сам то я на scheme переходить пытаюсь

Scheme

И какие лиспы есчё имеют статическую типизацию? Ведь хороший лисп - лисп с типизацией.

Какой тип у такого списка: (1 «foo» 'bar) ?

>Какой тип у такого списка: (1 «foo» 'bar) ?

не каждый язык такое допускает

не каждый язык такое допускает

Лисп допускает. Лисп вообще состоит из одних только списков (исключая странный макрос loop).

Вернее сказать «диалект», а не «реализация». Если ради интереса, то я бы выбрал scheme как самый простой и чистый диалект. Литературы много, не сложно самому и интерпретатор/компилятор сделать. По стандарту есть такие важные (для академического интереса особенно) фичи, как continuations и хвостовая рекурсия. Если для практического применения, то CL или Clojure, наверное.

>Лисп допускает. Лисп вообще состоит из одних только списков (исключая странный макрос loop).

Да и loop тоже список, в который входят объекты, которые рассматриваются как symbol. Так тоже, кстати, работает:

(loop :for i :from ... :to ... :collecting ... ...)

Да и loop тоже список, в который входят объекты, которые рассматриваются как symbol.

Согласись, iter выглядит более по-лисповски?

> Согласись, iter выглядит более по-лисповски?

Он не только выглядит, он и по-сути ближе.

> И какие лиспы есчё имеют статическую типизацию?

Typed Scheme (один из проектов в PLT).

>> И какие лиспы есчё имеют статическую типизацию?

Typed Scheme (один из проектов в PLT).

Значит я не ошибся с выбором :)

Я недавно озаботился таким же вопросом, выбрал CL. Трудноватно поначалу, но со скрипом и гигаобезьяной дело пошло.
В моем понимании очень важно: должна быть конкретная задача.

>Согласись, iter выглядит более по-лисповски?

Да, выглядит более по-лисповски.

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

Arc сразу из списка.

Лучше всего, ИМХО, выучить Common Lisp почитав что-нибудь из приличного числа отличных книг: PCL, Successful Lisp, On Lisp...

А потом перейти на Clojure как действительно практичный.

> jvm и .net - тормоза.

Бред. Я тоже не фанат всего этого, но вы либо не в курсе, либо врете.

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=java&lang2=...

Причем самое забавное, что и по памяти отличия не большие.

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

И сборщика мусора сравнимого нет ни в одной открытой реализации CL.

Ruby, конечно же. Тот же Лисп, только с человеческим лицом.

Что меня всегда отталкивалов от CL - так это отсутствие какой-либо документации по различным фрэймворкам и их постоянное умирание. Долго искал что-нибудь толковое по Uncommn Web - вся документация устаревает быстрее чем развивается проект, по Weblocks вообще ничего путевого не нашел кроме нескольких хелловорлдов

У Clojure производительность *очень* *отличается* от таковой у собственно Жабы. Перестаем подменять факты, к.

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

Что касается веб-фреймворков, то archimag делает свой restas.

Учить - CL, конечно.
Остальные диалекты это либо непрактичная и академическая Scheme, либо скриптота(newLISP, Emacs Lisp, Autolisp и т.п.), либо Clojure, но она на жабомашине(соотв. то, что оно ф.п. поддерживает лучше cl - спорно как минимум - ввиду всякого ублюдства вроде recur и т.п.) и тормозит; да, clojure интересна своим подходом к параллелизму(STM etc.), но тогда уж лучше взять Erlang.
CL - единственный живой, практичный и вменяемый general-purpose диалект лиспа.

Откуда дровишки?

Одной из своих основных задач Хики видит то, чтобы на Clojure можно было писать такой же эффективный код, как и на Java. То есть это является одной из заявленных целей разработки языка, что зачастую отражено и в его дизайне. И такое написание почти всегда возможно (использование нативных типов, деклараций типов, модификации на месте, и т.д) — а что еще нужно для оптимизации узких мест?

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

и в чем же непрактичность схемы заключается?

> ф.п. поддерживает лучше cl

А таки Clojure поддерживает лучше. Именно ФП лучше.

но тогда уж лучше взять Erlang.

Извините, но коим боком Erlang к STM? Там совсем другой подход, имеющий свои преимущества и недостатки. Для многих задач STM выгоднее.

CL - единственный живой, практичный и вменяемый general-purpose диалект лиспа.

Clojure живой, практичный и вроде вполне себе general-purpose. Вы сомневаетесь в его вменяемости?

Бери Scheme. Гораздо чище и логичнее CL.

>Clojure живой, практичный и вроде вполне себе general-purpose. Вы сомневаетесь в его вменяемости?

И что, он кем-то используется практически?

> по Weblocks вообще ничего путевого не нашел

читай код - он документирован и достаточно понятен, задавай вопросы в mailing list - Polzer тебе ответит

и в чем же непрактичность схемы заключается?

Стандарт слабоват по части фич, а в реализации различных SRFI там такой цирк...

язык это язык, а библиотеки - это библиотеки. SRFI покрывают достаточно большое кол-во нужных задач

> Бред. Я тоже не фанат всего этого, но вы либо не в курсе, либо врете.

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=java&lang2=...

ну и зачем мне эти синтетические тесты? Доказано на практике, на реальном проекте, жаба — тормозит. точка.

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

Хаха. Как всем не нравятся синтетические тесты! Главный разработчик HotSpot -server жаловался на то, что конкретно эти тесты не дают показать себя JIT-компилятору во всей красе.

Но вообще эти тесты дают хоть какое-то представление. А знаете научную ценность заявлений «доказано на практике»? И даже если это так, да, видал я кровавый энтерпрайз (прерогатива Java)... ИМХО в таких проектах, с таким подходом к разработке будет тормозить на любом языке.

SRFI покрывают достаточно большое кол-во нужных задач

Ну да, только часть нужных SRFI есть только в одной схеме, часть - в другой. В CL в стандарте нужных фич несравнимо больше, а куча нужных библиотек гладко поддерживает почти все живые реализации. По части практичности использования языка для обычного программирования (не встроенный специализированный язык) Common Lisp лучше.

Я уж не говорю, что не дай бохх в программе потребуется скорость...

> Clojure живой, практичный и вроде вполне себе general-purpose. Вы сомневаетесь в его вменяемости?

да. Если было бы возможным собирать нативные бинарники + такие же плюшки, как у CL-ного компилятора, тогда было бы что-то вменяемое.

Как много open-source реализаций CL умеют собирать нативные бинарники и каково качество этих реализаций?

Какие плюшки? У Clojure есть свои плюшки.

> И вообще есть еще языки и с метапрограммированием, и с функциями как объектами первого класса, и с идентичностью кода и данных.

Factor, например, или Joy

Например, tcl

ненене. Интертрепаторы фтопку.

Если хочется практичности — CL, ибо он отражает консенсус инженерной части Lisp-сообщества.

Если хочется красоты и академичности — Scheme.

Если хочется современных ФПшных трендов и не пугает jvm/.net — Clojure.

Если хочется экзотики — picolisp (Lisp с динамическим скопом и напрямую вычисляемым списками а-ля Tcl).

Если хочется Emacs — elisp.

Arc, Newlisp и т.п. — в печь.