Состояние экосистемы Common Lisp на 2015 год

Мне нужен ECL. Это факт. :-)

Зачем тебе он? Судя по постам, ты CL не знаешь. Так, пофапать?

а твой взвяк про ненужность вызовов Lisp и C говорит об обратном

Да что-ты? Кроме callback-ов более ничего и не нужно. Я где-то соврал?

Но всё иначе. SBCL прекрасно работает.

Ну да, сначала прекрасно работает, а потом по неизвестным причинам, прекрасно падает :-)

PS. cl-async - вынужденная потуга из-за импотенции реализаций CL в части асинхронного ввода/вывода. :-)

Меня смущает информация о «poorly supported as of SBCL 0.7.5» из первых рук. Меня предупредили, я кивнул гривой и намотал на ус, и сделал вывод, что мне не нужны какие-то хаки в системе, претендующей на надёжность эксплуатации.

Okay. Ну то есть ты живёшь в мире, где летают феи и какают бабочками? Чем сложнее софт, тем больше в нём багов и технических долгов. Никто не говорит, что SBCL идеален и абсолютно надёжен. Это далеко не так. SBCL достаточно надёжен (как минимум для моих задач). Между технологичностью/производительностью и дрочбой на «надёжность» (часто, мнимую), я всегда выберу первое. Если мне нужен будет софт 24/7 и из-за надёжности этого софта будет зависеть судьба человечества, я вообще Lisp не возьму. Никакой, ни LispWorks, ни SBCL.

Да что-ты? Кроме callback-ов более ничего и не нужно. Я где-то соврал?

Ты про обратные вызовы ни слова не сказал, когда публиковал вот эту чушь:

Дёргать Lisp функции их C? Знаешь почему это «is extremely hackish», сопливый ты антон? Потому что это нафиг никому не нужно. Когда говорят о FFI, конечно же имеют ввиду С из Lisp.

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

Ну да, сначала прекрасно работает, а потом по неизвестным причинам, прекрасно падает :-)

Хватит может пусто пиздоболить? Давай ссылки на конкретные баги уже.

hunchentoot+cl-sql И вообще, советую почитать дискуссию целиком :-)

скорее из за ЦАПИ и мультиплатформенности

cl-async - вынужденная потуга из-за импотенции реализаций CL в части асинхронного ввода/вывода. :-)

А с чего ты взял, что язык (достаточно старый, кстати), обязан поддерживать асинхронный ввод/вывод? Расскажи-ка мне про языки/реализации, которые умеют это из коробки? (Node.js). cl-async - это не потуга, а нормальный frontend к libuv.

Node.js не в счёт.

Возьми на сей раз ник, скажем, palendrom, чтобы видно было лиспера, прочитавшего книжечку про Лисп издалека :-)

Нечего сказать по делу? Все раскусили, что ты анонимный пиздобол. Выход есть - доебись до nickname автора.

автора

fix: оппонента

hunchentoot+cl-sql И вообще, советую почитать дискуссию целиком :-)

И вообще, советую не вырывать из контекста (от monk)

Использовал hunchentoot, cl-sql, postgresql.

для посгреса надо брать родной постмодерн

А с чего ты взял, что язык (достаточно старый, кстати), обязан поддерживать асинхронный ввод/вывод?

Не язык, крикун, а реализация среды выполнения :-) Ну вот тебе C, C++, Erlang, Java, Node.js.

PS. В CMUCL был serve-event. В SBCL он, вроде как есть, но вроде как его и нет :-) Короче, опять hackish way :-)

PS. cl-async - вынужденная потуга из-за импотенции реализаций CL в части асинхронного ввода/вывода. :-)

В последней версии LW добавили асинхронный API для UDP и TCP сокетов, которым я уже в продакшене пользуюсь.

В последней версии LW добавили асинхронный API для UDP и TCP сокетов, которым я уже в продакшене пользуюсь.

Ну так вот это уже другое совсем дело. Тогда добавляем в вышеупомянутый список ещё и LispWorks. :-) LispWorks рулит.

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

И вообще, советую не вырывать из контекста (от monk)

Советую не вырывать из контекста. Тут речь идёт о падениях SBCL и некто просит ссылки на падения. monk поймал падение и выложил ошибку. Так что всё по-честному. :-)

Тут речь идёт о падениях SBCL и некто просит ссылки на падения. monk поймал падение и выложил ошибку

да. я посмотрел бектрейс и похоже что на сайте встречаются разные кодировки. я с таким сталкивался (от виндовых сайтов). просто monk не предусмотрел такого случая.

и причём здесь СБЦЛ?

C, C++

Ну-ка ссылочки.

Node.js

Кстати, тоже использовала libuv, сейчас libev. Тоже, hackish way?

и причём здесь СБЦЛ?

SBCL падает, значит SBCL, ёпта. Логика гопника из шараги. Что ещё ожидать-то. Ему сказали SBCL, он и поверил.

C, C++
Ну-ка ссылочки.

Какие тебе ссылочки? man select, man epoll. Для C есть libevent, для C++ есть Boost.Asio. Для этих языков всё родное Никакого hackish way.

Node.js
Кстати, тоже использовала libuv, сейчас libev. Тоже, hackish way?

Нет, когда это поддерживается самой средой времени выполнения, хорошо описано в документации, то это не hackish way. А вот cl-async - это самый что ни на есть HACKISH WAY. :-)

Для C есть libevent, для C++ есть Boost.Asio.

Всё это сторонние либы. Точно также как и cl-async для CL. Hackish way?

SBCL падает, значит SBCL, ёпта.

Ну да, надёжная среда времени выполнения падать не должна. Значит SBCL - ненадёжная среда времени выполнения, а всё тот же hackish way :-) Что и требовалось доказать.

Логика гопника из шараги. Что ещё ожидать-то. Ему сказали SBCL, он и поверил.

Ну да, человек привёл доказательства, что SBCL усрался и вывалился, я и поверил :-) Проверять не охота. :-) Ведь monk поэтому и переписал сайт на Racket, теперь и горя не знает, как он говорит, всё работает :-)

Нет, когда это поддерживается самой средой времени выполнения, хорошо описано в документации, то это не hackish way.

cl-async поддерживается средой выполнения и достаточно хорошо документирован http://orthecreedence.github.io/cl-async/documentation. Но тем не менее:

А вот cl-async - это самый что ни на есть HACKISH WAY. :-)

Хм. С тобой всё ясно. Иди на хуй.

Ну да, надёжная среда времени выполнения падать не должна. Значит SBCL - ненадёжная среда времени выполнения, а всё тот же hackish way :-) Что и требовалось доказать.

Ну да. В Rust, например, могу использовать unsafe сишные вызовы и в Ada тоже. И всё завалить. Значит runtime Rust и Ada ненадёжны. Просто иди на хуй ещё раз.

Проверять не охота. :-)

Ну да. Тебе скажи что дерьмо - это конфетка. Ты скушаешь, облизнёшься и улыбнешься :) Просто иди на хуй в третий раз, долбоёб. В последний раз.

Всё это сторонние либы. Точно также как и cl-async для CL. Hackish way?

Нет, не точно так же. libevent - это библиотека, которая написана на C, вызывает системные вызовы на C, и используется в программах на C, ну а C++ изначально был спроектирован чтобы обеспечивать идеальную совместимость с C. Так что не hachish way. cl-async же является библиотекой на Common Lisp, которая: вызывает функции библиотеки на C, используя CFFI, который, как мы видели, использует сакральные знания о той/иной реализации Common Lisp, в частности, у которой «Calling Lisp functions from C is sometimes possible, but is extremely hackish and poorly supported as of SBCL 0.7.5» :-) Это hackish way :-)

Ну да, надёжная среда времени выполнения падать не должна.

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

как страшно жить!

В Rust, например, могу использовать unsafe сишные вызовы и в Ada тоже.

Причём тут Rust? Низкоуровневый язык, задуманный как замена C, совсем из другой оперы. Речь ведь идёт ни о внешних C вызовах, которые могут наломать дров, а о коде, который компилирует самая реализация Lisp. Если она падает от собою же сгенерированного кода, то она - говно :-)

В последней версии LW добавили асинхронный API для UDP и TCP сокетов

Это круто.

И как же тогда пишут на крестах, жабе и шарпе???

На крестах, жабе и шарпе пишут в поте лица. Сей труд нелегок, потому и незавиден :-) И я бы не стал сравнивать программирование на Lisp с крестами, жабой и шарпе :-)

они постоянно падают если писать не заботясь об исключениях.

Дитя, в Lisp исключений нет, поэтому Lisp программы падать не должны :-)

Речь ведь идёт ни о внешних C вызовах, которые могут наломать дров, а о коде, который компилирует самая реализация Lisp. Если она падает от собою же сгенерированного кода, то она - говно :-)

PS Это всё равно, что запуск кривой программы на компьютере приведёт к его зависанию :-)

твоя тупость столь велика, что просто неописуема!

Фтопку цапи - закрытые исходники, жуткие вопросы на Lispworks-HUG. tcl/tk рулит. Не постесняюсь снова прорекламировать вот это, потому что по итогам сегодняшнего дня у меня в дебаггере появился инспект локалов, поиск по стеку, гото фрейм сорсе, инспект кондишена, показ catch тегов. Зырим картиночку:

https://bitbucket.org/budden/clcon/wiki/Home

Ну и ещё как-то странно обнаружил, что почему-то работает вложенный вызов отладчика. Почему работает - ума не приложу.

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

Обсуждение здесь:

варим Эль (комментарий)

https://bitbucket.org/budden/clcon/wiki/Home

Молодец! Один вопрос. Что ты с этого поимеешь? :-) Или ты бесплатно?

Поимею возможность писать приложения на лиспе с гуем и скриптовым языком в виде лиспа же. А дальше не скажу :)

в Lisp исключений нет

Есть Conditons. Почти то же самое.

приватная alien-lambda в sb-alien ...
Поменяют в SBCL, изменят в cffi. Никаких проблем.

Неэкспортированая alien-lambda - просто обертка которая пакует &body в лямбду и передает экспортированому alien-callback. Чисто для ясности. Это все легко выясняется за несколько минут беганья по коду. Баг Никодимуса о том что это неразумие лучше заменить на что более стройное и ясное - висит с 2008-ого, на первой странице трекера:(

Есть Conditons. Почти то же самое.

Неужели? :-) Прям «Conditons»? :-) Ого! И что ты этим хотел сказать? Что среда времени выполнения может падать при сигнале условия? Она может вывалиться в отладчик, но не упасть. В этом отличие от всех этих жав и цепепе, в которых, конечно, можно поставить всеобщие try/catch, но так как там нет перезапусков, они мало полезны :-)

Хм. С тобой всё ясно. Иди на хуй.

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

ecl никому не нужен. Это факт. Хорошая попытка сделать Common Lisp встраиваемым.

Несмотря на название его встраивемость не твкая как в libpython например. Он compile-time кодогенератор типа boost-а. И без С/C++ комплятора может немногое. Сам по себе заточен на работу с хитрыми С-шными sdk, к которым цепляться снаружи очень муторно или просто маловозможно. Им напрмер собрали maxim-у для анроида. И твое «ненужен» здесь говорит скорее о недостаточном кругозоре.

Встраивать Common Lisp - это то ещё непонятное извращение.

Ну если в большом проекте уже встроен libpython, то после некоторых уровня страданий народ вполне начинвет смотреть вокруг в поисках альтернвтив. В том числе и на пиареный ЛОР-ом sbcl. Если бы возможность встраивания по аналогии с libpython и ему подобным, то мы могли бы иметь несколько интересных историй успеха, приток разработчиков и все такое. А так только твое «ненужно» - неравноценная заменв :( На самом деле звпрос не такой уж редкий, и странно что при всех понтах перед аноном, ты этого не знаешь.

прочая специальная скриптота.

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

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

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

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

Нет уж :) У меня к тебе встречное предложение - перерегестрируй свой анонимный пердак.

то мы могли бы иметь несколько интересных историй успеха

Сомнительных историй. Уровня, как там было у Нострадамуса:

Common Lisp в мозгах!
Common Lisp в горбах!
Common Lisp в глазах!
Common Lisp в гробах!
Common Lisp в могиле!
Common Lisp в ....!
Common Lisp на знамени,
Common Lisp везде!

:) Как-то так, да?

что при всех понтах перед аноном

Какие ещё понты, дружище? Меня просто выводят из себя анонимных питухи ведущие подрывную деятельность, очерняющие лучшую открытую реализацию CL - SBCL. Причём не имея при этом никаких адекватных аргументов. Это может вводить в заблуждение начинающих Lisp-еров. Я ещё понимаю, monk, который в принципе разочаровался в CL и ему по душе, как я понял, более строгая со своими священными коровами Racket. Ну так это его право, ему удобнее, кто ж его осудит? Конкретно мне конечно немного жалко, что monk сошёл с CL. Я читал его код, он весьма профессионально написан. Этот чувак многое мог бы сделать для community.

Ага. И ты полагаешь, что «встраиваемый» CL это вполне себе альтернатива? Язык, с достаточно большим runtime,

Удивись у того же стадартного питона он не сильно меньше. А если смотреть ускоренные варианты то и может быть более.

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

проектировался явно без учёта встраиваемости,

Это затасканое утверждение. Если бы еще таскающие за собой могли бы его раскрыть :(

В других случаях лучше встроить, например, Scheme.

Маленькие схемы ничем кроме эстетики не лучше питона, а большые таскают рантайм ничуть не меньше CL. Это общая печальная закономерность. И зачем оно тогда надо?

:) Как-то так, да?

Ну я надеялся, что до уровня анонимов опускаться не будем :( Видно, зря.