Какой из лиспов лучше взять?

Chicken. Есть яйца и честная компиляция.

компиляции в нативный код

Common Lisp. Racket тоже вроде компилируется в натив, но там это через JIT.

батарейки

Говорят, в LispWorks их есть.

Сколько можно срать в теги своими идиотскими тредами.

Сделай свой Лисп, чо как не пацан спрашиваешь ?

Взять для чего, кокретный проект? Если да, то какого рода, какие батарейки нужны?

А абстрактно - я бы лучше пива взял.

А пиво компилируется в нативный код? Насчет батареек - ну хотя бы HTTP.

А пиво компилируется в нативный код?

у меня оно интерпретируется в исходный :)

Насчет батареек - ну хотя бы HTTP.

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

Не, серьёзно, тебе писать что-то конкретное или для изучения?

Не трожь теги.

Так это не я трогаю.

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

Интероперабельность-с-жабой — батарейки. Отсюда вытекают Clojure, Kawa, Bigloo.

Таких не существует. Учи джаву.

Ну ты и не трогай. Теги - не категории, в них писать что угодно можно и нужно. Главное, чтобы теме соответствовало.

предлагаете Clojure, хотелось бы услышать обоснование

• наличие приятного *синтаксиса*
• иммутабельные и ленивые коллекции искаробки
• stm туда же
• lisp-1
• нормальное коммунити
• куча либ
• clojurescript
• .... ииииинтероперабельность с жабой, пабабабам!

racket умеет jit в x86, amd64 и arm. батарейки есть.

если не тянет блевать от jvm, то можешь и на clojure посмотреть.

Интероперабельность-с-жабой — батарейки.

Кривые там батарейки... Всё-равно приходится обёртки строить.

А если без обёрток, так в SBCL и Racket все *.so/*.dll — батарейки. И их больше, чем Java-библиотек.

меня интересуют батарейки

Если интересует максимальное разнообразие батареек, то SBCL + quicklisp. Например, для http/html там есть и hu.dwim и web4r и weblocks и restas...

Если хочется, чтобы батарейки были единообразны и стабильны, то Racket. + есть call/cc, нормальные модули, юниты...

Кривые там батарейки... Всё-равно приходится обёртки строить.

У кложуры комьюнити большое — оберток уже много. И с каждым днем больше становится.

ТС, а для http везде полно батареек — бери что угодно.

Значит, лиспа с батарейками нет.

lisp-1

Lisp-1 не является преимуществом. Это скорее недостаток.

нормальное коммунити

Нормальное community у Clojure? :) Да ну, это же не правда.

куча либ

Не больше чем для CL (а если взять ACL или LW — меньше).

иммутабельные и ленивые коллекции искаробки

Вот это да. Что есть, то есть.

Определите «батарейки», пожалуйста.

Отключаемый набор сторонних библиотек сносного качества

Не больше чем для CL (а если взять ACL или LW — меньше).

На яве что ли меньше либ написано, чем на цоммонлишпе?

Одного interoperability не достаточно. Чтобы можно было использовать java-вские либы нужно из положить на адекватный Lisp-у дизайн. Это всё равно что сказать, что все сишные библиотеки, ввиду cffi, являются и lisp-овскими.

Вам всё бы только по бабам, поручик.

http://docs.hylang.org/en/latest/

ты как раз питонячер

Там другая проблема. Явовские библиотеки не thread-safe и структуры данных мутабельные. А вызов кода выглядит как вполне «адекватный Lisp-у дизайн».

А вызов кода выглядит как вполне «адекватный Lisp-у дизайн».

Хм. Вызов defcfun cffi тоже выглядит как «адекватных Lisp-у дизайн», только вот это нифига не адекватный Lisp-у дизайн по сути. Ведь Lisp предоставляет абстракции отличные от Java-вских и, в связи с этим, подход к проектированию библиотек отличается. Разве это не очевидно?

Ты прав лишь отчасти

Ведь Lisp предоставляет абстракции отличные от Java-вских

Ты про какой лисп? Я про кложуру, например. А, поскольку она изначально проектировалась для jvm, то у неё с java очень много общего. Про основные отличия я уже упомянул. Именно из-за них делают обертки. Которые, кстати, делать легко и удобно.

Значит есть и в CL, и в Racket, и в Clojure, хотя в последнем есть сомнения насчёт качества.

Lisp-1 не является преимуществом. Это скорее недостаток.

Ну конечно же нет. Lisp-2 это крест на написании в функциональном стиле. Во _всех_ вменяемых лиспах (куда CL конечно же не входит) lisp-1: racket, scheme, clojure. И любой другой новый лисп будет с lisp-1.

Нормальное community у Clojure? :) Да ну, это же не правда.

Очень похоже на python-коммунити, только более продвинутое.

куча либ

Не больше чем для CL (а если взять ACL или LW — меньше).

Для вебни и написания серверов приложений сильно больше и стопицот раз продашнее, так же как для обработки больших объемов данных (ленивые коллекции рулят). Да и js на клиент-сайде часто идет в треш.

Ты про какой лисп? Я про кложуру, например.

Ну когда говорят Lisp, имеют ввиду в первую очередь CL. Конечно же в плане технологичности CL в разы мощнее, чем Clojure, но тем не менее Clojure — диалект Lisp-а и сильные стороны, такие как метапрограммирование, Clojure умеет.

А, поскольку она изначально проектировалась для jvm, то у неё с java очень много общего.

Совершенно не верно. От JVM в Clojure прилетели лишь ограничения. Но, например, те же макросы накладывают сильный отпечаток на программирование и подход к дизайну библиотек в целом. Если Clojure написана с расчётом работы на jvm, совершенно не означает что Clojure и Java похожи — это совершенно разные языки.

Именно из-за них делают обертки. Которые, кстати, делать легко и удобно.

Никогда не понимал сути термина «обёртка». Это такая тонкая штуковина — интерфейс к низкоуровневым вызовам? Такие «обёртки» писать и на CL очень легко, только вот подобный интерфейс не является полноценной lisp-библиотекой, по вышеизложенным причинам. Средства взаимодействия с Java не сгенерируют за тебя грамотные, соответствующие предметной области и традициями Lisp: интерфейсные функции, классы, макросы...

Ну конечно же нет.

Ни нет, а да.

Lisp-2 это крест на написании в функциональном стиле.

Во-первых, это не правда, ибо адекватные элементы ФП присутствуют в CL в должной степени. А во-вторых, написание «в функциональном стиле» (чистом) ставит крест на написании пригодного в промышленности кода (в большинстве случаев).

Очень похоже на python-коммунити, только более продвинутое.

Ох. Python community известна своей ущербностью и фактически является днищем (даже Perl community грамотнее). Надеюсь, что обрыганы из python не повалят в Clojure. Они и не осилят, как бы.

так же как для обработки больших объемов данных (ленивые коллекции рулят).

Хм. С какого это перепуга? Написанный в лоб код будет эффективнее по памяти и не более того.

Если Clojure написана с расчётом работы на jvm, совершенно не означает что Clojure и Java похожи — это совершенно разные языки.

Я и не спорю, совершенно разные языки. Но совместимые на низком уровне.

Какой из лиспов

JavaScript

Никогда не понимал сути термина «обёртка». Это такая тонкая штуковина — интерфейс к низкоуровневым вызовам?

Может быть, слово wrapper тебе ближе?

интерфейс к низкоуровневым вызовам?

Да, если ты считаешь java языком низкого уровня.

Средства взаимодействия с Java не сгенерируют за тебя грамотные, соответствующие предметной области и традициями Lisp: интерфейсные функции, классы, макросы...

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

общелисп с сишкой, значит, тоже совместимые на низком уровне?

Всё относительно. Ты можешь на CL написать библиотеку, чтобы использовать её из сишечки? inb4 костыли вроде ecl

Да и видел я код лавсанчега, для взаимодействия с directX — закат солнца вручную. При взаимодействии java <--> clojure такого ужаса нет.

Какие именно батарейки нужны?

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

Да, если ты считаешь java языком низкого уровня.

Именно. Относительно Clojure.

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

Хм. Язык что-то не поворачивается разработку библиотеки назвать обёрткой, даже если на низком уровне осуществляется взаимодействие с библиотекой низкоуровневого языка, ибо само взаимодействие это самая простая часть; что действительно сложно, так это дизайн. Ни Clojure, ни CL, ни чего либо ещё не позволяют сделать дизайн автоматически — ведь это сложнейший творческий процесс.

В CL они сомнительной свежести. При всем уважении, и как бы мне ни хотелось, чтобы все было иначе.

Что есть, то есть :( Крайне мало людей в community. Нужно помогать...

Да и видел я код лавсанчега, для взаимодействия с directX — закат солнца вручную.

Это от того, что сишка совсем низкоуровневая и C++ всё ещё более усложняет.

В clojure замечательные собственные библиотеки с грамотной немутабельностью.

Это не отменяет фактов.

Ни Clojure, ни CL, ни чего либо ещё не позволяют сделать дизайн автоматически — ведь это сложнейший творческий процесс.

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

Говно со слабой типизацией.