ABCL 1.4.0

К хорошему языку библиотеками можно допилить всё. Хороших языков не существует. :)

К CL библиотеками нельзя допилить продолжения, сопрограммы или полноценные грин треды (любые два из них реализуются через оставшийся). Остальное рано или поздно пишется библиотекой и появляется де-факто стандарт. И обычно от Eitaro Fukamachi.

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

Читать и разбирать программы в Lisp часто очень трудно, но менять что-то в них очень легко. В других языках обычно наоборот, кроме python, где сочетаются легкость чтения и модифицирования кода.

Константность как по мне — минус. Времена меняются, возникают новые технологии.

Стандарту CL 22 года :-) За последние 22 года ничего принципиально нового в программировании не возникло :-) Хотя стандарт хорошо бы обновить и устранить некоторое безобразие :-)

Кложа тоже не реактивно меняется
И то, что работа над языком ведётся это хорошо, потому что кто-то пытается решить вставшие перед ним (языком) проблемы

В каждом новом релизе её создатель может захотеть презентовать обратно-несовместимые изменения :-) Лично мне такого счастья не надо :-)

Библиотек в quicklispe сильно меньше, чем в мавене, а их актуальность зачастую вызывает большие сомнения.

Фундаментальные решения, такие, как cl-ppcre или alexandria какая-нибудь, или тот же quicklisp обновляются постоянно :-) И вообще, количество никчёмных библиотек характеризует язык или платформу не с лучшей стороны :-) Что толку с тысяч «библиотек» для Node.js, состоящих из нескольких строчек? :-)

Читать и разбирать программы в Lisp часто очень трудно, но менять что-то в них очень легко. В других языках обычно наоборот, кроме python, где сочетаются легкость чтения и модифицирования кода.

Вкусовщина. Мне на любом более-менее популярном лиспе программа понятнее, чем на питоне (напомню, на котором я кодил 8 часов в сутки в течение 8 месяцев). Питон субъективно уступет CL по легкости чтения, и совершенно объективно уступает CL по легкости модификации.

Константность как по мне — минус. Времена меняются, возникают новые технологии.

Стандарту CL 22 года :-) За последние 22 года ничего принципиально нового в программировании не возникло :-) Хотя стандарт хорошо бы обновить и устранить некоторое безобразие :-)

Треды, грин треды... СОКЕТЫ *facepalm*

Там не безобразие устранять надо, а именно стандартизировать принципиально новое в программировании. Реализация в SBCL сразу становится стандартом де-факто, но это не очень хороший^W^W^Wдерьмовый подход к стандартизации.

За последние 22 года ничего принципиально нового в программировании не возникло

У нас с вами, боюсь, разный взгляд на вещи. Я не хочу десятилетий стабильности, я хочу регулярной работы и развития языка.

может захотеть презентовать

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

количество никчёмных библиотек

Язык характеризует только удобство написания на нём кода. А платформу да, характеризует количество качественных библиотек. Я вот webdav клиент хочу чтобы в свои диски облачные ходить скриптом. Что мне предлагает quicklisp и гугл? Webdav сервер, не обновлявшийся два года, и парсер xml. ОК.

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

Треды,

Термин 1967 года :-)

грин треды...

Термин из Java 1.1 1997 года :-) А вообще, это всегда называлось LWP, и появился термин задолго до гринов в Java :-)

СОКЕТЫ

1983 год :-)

Реализация в SBCL сразу становится стандартом де-факто

Что стало стандартом из реализации в SBCL? :-)

Там не безобразие устранять надо

Там безобразие надо устранить :-)

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

Ну так развивайте :-) Или кто-то должен это делать другой? :-)

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

Ну вон, цепепе, при всех плевках в его сторону, обратную совместимость он не ломает :-) И это ему в третий плюс :-)

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

Язык много что характеризует :-) Главная характеристика - какой выхлоп для машины можно сгенерить из этого языка :-)

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

А что у тебя за прод? :-) Откровенно говоря, Лисп лучше всего подходит для написания компиляторов/генераторов, для исследовательского программирования и для прототипирования, а не для написания каких драйверов, ОС или реал-тайм серверов :-)

1. Скорость работы кода

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

2. Независимость от JVM

И плюс и минус. В плюсы CL, насколько я понимаю, идёт меньший оверхед по памяти, более шустрый startup time, да и наверное всё что могу придумать навскидку. В плюсы к JVM идёт тьма библиотек (не всегда хороших кстати), хороший сборщик мусора, профилировщики, отладчики.

И кстати, для любителей странного - clojurescript можно запускать на nodejs - вот вам и независимость.

3. Константность языка (есть стандарт, который не меняется)

Стандарт не меняется не от хорошей жизни, а просто от того, что никто денег на это не даёт. Стандарт кобола тоже наверное образец стабильности.

Кстати кложура тоже весьма стабильна. Я краем глаза следил за ней где-то с версии 1.1 (2009 год) и с тех пор никаких глобальных переделок не было - разработчики тянут обратную совместимость. Никаких «революций», аля питон3, руби2 не было. Справедливости ради питон и руби сильно старше, так что поживём - увидим.

Нужно больше разных лиспов, так победим!

Потоки в Питоне есть. Модули thread и threading из «батареек» (thread, емнип, даже вшит в интерпретатор Питона, т.е. входит в число немногочисленных «frozen» модулей). Есть «зелёные» треды в реализации сторонних библиотек. А если под

«потоков в питоне нет и не будет»

подразумевался GIL, то так и надо писать, а не наводить тень на плетень.

Нужно больше разных лиспов, так победим!

Где больше то? Тот же CL что и был 22 года назад.

Ну так развивайте :-)

Не хочу, хочу свои проекты пилить.

А что у тебя за прод?

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

Лисп лучше всего подходит для ...

Да я и хочу веселое средство для прототипирования и экспериментов. В принципе, меня устраивает, минусы я выше описал. Мы же с кложа против коммона начинали. И далеко не ушли.

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

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

Коммерческие реализации. Я в продакшен LispWorks тащу.

Какой нафиг аффтар? Есть стандарт которому все следуют.

Не хочу, хочу свои проекты пилить.

Покупайте коммерческую реализацию CL и пилите :-)

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

Здесь рулит Java :-)

Мы же с кложа против коммона начинали. И далеко не ушли.

Почему, всё прояснилось :-)

Здесь рулит Java :-)

Или Franz с его AllegroGraph/AllegroCache.

Стандарт кобола тоже наверное образец стабильности.

буквально только что наткнулся на статью про Visual COBOL :)

Там безобразие надо устранить :-)

ну мне вот более другой лисп больше нравится: ISO ISLISP. там стандарт короче, и вообще умозрительно приятнее. часть проблем CL там решена. другое дело, что реализаций его кот наплакал.

и да, пользуются им -3.5 анонимуса.

Стандарт уже умеет компилировать и запускать программы?

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

it now supports JSR-223 (Java scripting API): it can be a scripting engine in any Java application. Additionally, it can be used to implement (parts of) the application using Java to Lisp integration APIs

Т.е. допустим я купился на этот интерворкинг с джавой и вовсю завязался на JSR-223 и Java to Lisp integration APIs, а аффтар взял и сказал «я устал, я ухожу». Как меня утешит стандарт 22х летней давности, которому все следуют?

Или Franz с его AllegroGraph/AllegroCache.

Это другой уровень совсем :-) Это как мейнфрейм со среднестатистическим сервером в стойке сравнивать :-)

:-)
:-)
:-)

Я просто перечисляю чего не хватает в стандарте.

:-)

sb-bsd-sockets, хотя usocket имеет уже сильно другой API
sb-threads, полностью скопированный в bordeaux-threads
Какие-то из CDR вроде бы написаны по реализации в SBCL.

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

Автор реализации, полагаю, а не языка? Тогда SBCL, CCL, Allegro, Lisp Works этому критерию удовлетворяют полностью. Юзабельны, но с риском забивания автором - ECL и сабж (ABCL).

Стандарт уже умеет компилировать и запускать программы?

Нет, просто в вашем комментарии проскочило «автор языка». Авторы языка забили на язык ровно 22 года назад, сразу после сдачи стандарта.

Т.е. допустим я купился на этот интерворкинг с джавой и вовсю завязался на JSR-223 и Java to Lisp integration APIs, а аффтар взял и сказал «я устал, я ухожу». Как меня утешит стандарт 22х летней давности, которому все следуют?

Аффтар ABCL - это автор ABCL, а не «автор языка».

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

Ты упоротый?

Я просто перечисляю чего не хватает в стандарте.

Этого добра там полно :-) Там, в первую очередь, хорошо бы навести однообразие в именованиях операторов и функций и в порядке следования их аргументов :-)

sb-bsd-sockets, хотя usocket имеет уже сильно другой API
sb-threads, полностью скопированный в bordeaux-threads

Ты привёл 2 частных примерчика в качестве доказательства того, что SBCL диктует всем де-факто стандарт? :-) Лол :-) Обычно, usocket и bordeaux-threads, как это ни странно, используется только пользователями SBCL :-) Вряд ли кто-то в здравом уме откажется от API от LispWorks или ACL :-)

Автор реализации, полагаю, а не языка?

Допустим, но:

Если все реализации полностью одинаковые, то зачем такая фрагментация, почему нельзя сделать одну, но хорошо?

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

А я вот пишу на Clojure, и мне нахрен не нужен ваш CL.

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

Аффтар ABCL - это автор ABCL, а не «автор языка».

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

:-) Лол :-) :-) :-)

Ещё CCL и ECL. Да, представь себе у них есть пользователи. И ещё всеми библиотеками не привязанными к одной реализации. В конечных продуктах на ACL или LW, конечно, используются API ACL или LW соответственно.

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

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

Если все реализации полностью одинаковые, то зачем такая фрагментация, почему нельзя сделать одну, но хорошо?

*facepalm* А зачем много дистрибутивов когда есть LSB? Upstart и OpenRC практически идентичны по функциональности. Почему их две?

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

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

А, расширения *языка* стандартизуются CDR, хотя это процесс медленный и уникальные и несовместимые тоже есть.

UPD: Вру. Имею в виду расширения стандартной библиотеки. Расширений *языка* у реализаций уникальных нет.

Отличная статья.

Glue *language* examples:

Embeddable Common Lisp

Проходим по ссылке.

Embeddable Common Lisp (ECL) is a LGPL Common Lisp *implementation*

ещё один имеет славу неубиваемого, т.к. наследник использовавшейся в NASA реализации

Это который?

LispWorks на VxWorks

https://groups.google.com/d/msg/comp.lang.lisp/hcNg5EwiJO0/SwgvwFGDs90J

Да ты прав, Java не системный язык, значит скриптовый. Ещё там Erlang и XSLT в категории glue language. Coffeescript, макросы m4 там тоже glue.

Другие авторитетные статьи студентов-анонимусов?

ещё один имеет славу неубиваемого, т.к. наследник использовавшейся в NASA реализации

Это который?

http://ccl.clozure.com/history.html

JPL - Jet Propulsion Labs.

Надо сказать славу подтвердил. Однажды следующая версия софтины, которую вот-вот надо в продакшн начала ронять SBCL. После получасового выпиливания вызовов в sb-* всё просто заработало на CCL.

Да ты прав, Java не системный язык

Конечно нет, это ж не Сишечка.

значит скриптовый

С чего это значит?

Ещё там Erlang

Есть косяки, да. Но речь-то не о том, какие языки являются скриптовыми, а какие — нет. А о твоём упоротом посте, который я комментировал.

И? Что тебя смущает?

Но речь-то не о том, какие языки являются скриптовыми. А о твоём упоротом посте, который я комментировал.

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

Early mainframe computers (in the 1950s) were non-interactive

Java не интерактивный язык(нет REPL), значит всё таки не скриптовый.
И не системный.

Конечно нет, это ж не Сишечка.

Каким языком является Java? Дай определение.

Если «речь не об этом», то тем более не о мейнфреймах 50-60-х годов.
История персонального компьютера начинается в 1980-х.

а может, отсюда?

от Марвина нашего Минского:

The initial notion of Frames or Scripts as they were also called is that they would establish the context for a problem and in so doing automatically reduce the possible search space significantly.

а уже оттуда в боты геймдевские, и в частности, в скриптоту недопрограммерскую.

Schank, Roger; R. P. Abelson (1977). Scripts, Plans, Goals, and Understanding. Hillsdale, New Jersey: Lawrence Erlbaum.

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

нихрена. с 1965-го. машина «МИР» академика В. М. Глушкова, Советский Союз.

вики мурзилка

про ОГАС В. М. Глушкова