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

С чего это? Колбэки прекрасно передаются.

Честно слово, я не знаю как это работает, потому что, опять же, http://www.sbcl.org/manual/index.html#Calling-Lisp-From-C Официальная документация. И, кстати, если в CCL есть defcallback, то в SBCL его нет. Так что я думаю, что cffi идёт по hackish way. Доверять такой реализации системы, работающие 24 часа в сутки, мне страшновато. :-)

Ну и кто же это ушёл на Си?

С PL/1? Насколько я знаю, все. Или ты знаешь того, кто до сих пор пишет на PL/1?

Я не люблю цепепе, но с выходом C++11 я отчётливо вижу рост его популярности.

Тем не менее, Java в два раза популярней. При полном отсутствии стандартов.

Честно слово, я не знаю как это работает, потому что ...

В cffi с 2005 года прекрасно работает такой код:

(defmacro %defcallback (name rettype arg-names arg-types body
                        &key convention)
  (declare (ignore convention))
  `(setf (gethash ',name *callbacks*)
         (alien-sap
          (sb-alien::alien-lambda ,(convert-foreign-type rettype)
              ,(mapcar (lambda (sym type)
                         (list sym (convert-foreign-type type)))
                       arg-names arg-types)
            ,body))))

Гм... почти прекрасно: через sb-alien::alien-lambda нельзя делать замыкания и нельзя вызывать полученный callback в другом потоке.

Так что я думаю, что cffi идёт по hackish way. Доверять такой реализации системы, работающие 24 часа в сутки, мне страшновато.

А какая версия Common Lisp доподлинно не идёт по hackish way? Везде, как в iterate: делай как в примерах и всё будет хорошо, а если передашь на вход функции что-то не совсем стандартное, так чем закончится попытка отстрелить себе сразу голову предсказать трудно

С PL/1? Насколько я знаю, все. Или ты знаешь того, кто до сих пор пишет на PL/1?

А, ты про этот переход. Я просто подумал, что все ушли с C++ на C.

Тем не менее, Java в два раза популярней. При полном отсутствии стандартов.

Здрасте, приехали. В Java стандарт называется спецификацией https://docs.oracle.com/javase/specs/, которой обязаны следовать разработчики виртуальных машин во исполнение «написано однажды, работает везде» :-) Только в отличии от цепепе, спецификация контролируется одной крупной корпорацией. Вот и вся разница :-)

sb-alien::alien-lambda

А я правильно понимаю, что два двоеточия говорят об использовании неэкспортированных символов? Не знаю, для кого как, а для меня это сигнал того, что в один чорный вторник это перестанет работать. И нет никакого желания копаться ни в коде SBCL, ни в коде CFFI, если накроется система, обеспечивающая меня хлебом с маслом :-)

А какая версия Common Lisp доподлинно не идёт по hackish way?

Я не уверен абсолютно, но мне думается, что это LispWorks или Allegro. Потому что главным стимулом их разработчиков является денежная прибыль. Коммерческий софт всегда предполагает ответственность со стороны компании, потому что за него уплачены деньги. И компании, которые дорожат своим имиджем и не хотят завтра положить зубы на полку будут стараться делать софт качественным. Хорошего бесплатного софта не бывает. Везде нужна та или иная форма финансирования - хоть от прямых продаж, как у LispWorks/Allegro и т.д., хоть от спонсоров как у Linux/Postgres. А бесплатный софт лишь для фана. Эдакий заменитель судоку и кроссвордов. Хочется время прожечь (типа думая, что в этот момент происходит саморазвитие) - пожалуйста, бери бесплатный софт и хакай, делай бестолковку для саморазвития. Так что не hackish way - коммерческий софт. Точка. :-)

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

Причём заставить они могут только судебным путём. Помним Visual J++.

А в Common Lisp можно использовать переносимые библиотеки. Сейчас под «Common Lisp» фактически подразумевается система, для которой есть реализации bordeax-thread, trivial-garbage, cffi, swank.

И, к слову, наличие стандарта не помогает. Для того же C++14 вроде ни одного компилятора нет. GCC, судя по https://gcc.gnu.org/onlinedocs/libstdc /manual/status.html#status.iso.2011 до сих пор не поддерживает C++11.

Хорошего бесплатного софта не бывает. Везде нужна та или иная форма финансирования - ... хоть от спонсоров как у Linux/Postgres.

Противоречащие параграфы?

Так что не hackish way - коммерческий софт.

Ещё академический бывает. Тот же Racket. Или Ocaml с Haskell'ом.

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

Опа! Мы ещё на ЛОРе? Вроде да... То есть ты хочешь сказать, что Windows, AIX и Solaris качественней Linux'а и FreeBSD? А MS C++ Compiler качественней, чем GCC? Уверен?

А в Common Lisp можно использовать переносимые библиотеки.

Ну и что, спич о том, что эти «переносимые библиотеки», сменившие по пачке мэйнтэйнеров, будут, скорее всего, использовать hackish way с той или иной реализацией. Со стандартом такой бардак исключён.

И, к слову, наличие стандарта не помогает. Для того же C++14 вроде ни одного компилятора нет.

Глянь сюда. Полностью C++14. http://clang.llvm.org/cxx_status.html

Противоречащие параграфы?

Нет тут противоречия. Деньги - главный стимул. Каким образом они будут заколачиваться зависит лишь от модели бизнеса.

Ещё академический бывает. Тот же Racket. Или Ocaml с Haskell'ом.

Академический софт, вроде Racket, - это тоже коммерческий софт. Просто финансируется он, например, гос. бюджетом. (Если государство заинтересовано в развитие науки.) Неужели ты считаешь, что Racket или OCaml с хаскелем были созданы на голом энтузиазме? :-)

Опа! Мы ещё на ЛОРе? Вроде да... То есть ты хочешь сказать, что Windows, AIX и Solaris качественней Linux'а и FreeBSD? А MS C++ Compiler качественней, чем GCC? Уверен?

А ты хочешь сказать, что Linux, FreeBSD и GCC - это не коммерческий софт? :-) Лучше взгляни на коммитеров - они из RedHat, Google, Oracle, Intel, IBM и т.д. Это многомиллиардный бизнес. Надо быть наивным и совсем ничего не понимающим юнцом, чтобы верить в сказки про бесплатный качественный и благородный софт, который лучше коммерческого злого :-) Гыг.

Академический софт, вроде Racket, - это тоже коммерческий софт.... А ты хочешь сказать, что Linux, FreeBSD и GCC - это не коммерческий софт?

Тогда приходим выводу, что SBCL тоже коммерческий софт.

спич о том, что эти «переносимые библиотеки», сменившие по пачке мэйнтэйнеров, будут, скорее всего, использовать hackish way с той или иной реализацией. Со стандартом такой бардак исключён.

Будут, если реализация не поддерживает нужную функцию нормально. Вот существует пачка браузеров. И есть библиотеки, типа jquery, которые позволяют писать код так, чтобы на всех браузерах получался (почти) одинаковый результат. И в некоторых случаях там такой hackish way, что лучше на него не смотреть.

Или про тот же C++. Всё равно в большей части случаев лучше использовать boost, а не надеяться, что твою программу будут собирать исключительно clang'ом.

А что если я сделают два птреда и один из них дернет гц?

Да ладно. Вот свеженькая идея/возможность, опубликованная 21 мая сего года

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

Тогда приходим выводу, что SBCL тоже коммерческий софт.

Ну он такой же коммерческий, как LISP популярный. Размах «коммерции» SBCL по сравнению с Linux/GCC - это как капля в море. Так что ТАКОЙ коммерцией можно пренебречь :-)

А то расстановка syntax-marks механически проста, но весьма трудно делать ризонинг на счет результата.

Ага, макры Common Lisp куда практичней, несмотря на отсутствие гигиены :-)

Вот существует пачка браузеров. И есть библиотеки, типа jquery, которые позволяют писать код так, чтобы на всех браузерах получался (почти) одинаковый результат. И в некоторых случаях там такой hackish way, что лучше на него не смотреть.

Ты сравнил моську и слона. Во-первых, браузеры финансируют богатейшие компании мира. Сотни разработчиков так или иначе пыхтят над тем, чтобы всё это более менее сносно работало, ибо Интернет-индустрия позволяет зарабатывать миллиарды. Во-вторых, меня многим меньше беспокоит hackish way на стороне клиента, потому что клиентов много, а бэкэнд всего один. Крах какого-го процента браузеров в определённых ситуациях как эффект от hackish way, скорее всего, никак не отразится на моём бизнесе. Ну придёт кучка жалоб от определённого числа клиентов, баги будут исправлены в рабочем порядке. А если упадёт бэкэнд от hackish way фонатиков, то нужно будет просыпаться ночью, чтобы этот hackish way колупать с бешеными глазами от кофе и с торчащими волосами. :-)

А что если я сделают два птреда и один из них дернет гц?

птред дёрнуть гц не может. Для этого там написано #:async-apply

макры Common Lisp куда практичней, несмотря на отсутствие гигиены

В Racket есть и «макры Common Lisp». Только ими никто не пользуется, так как на шаблонах всё выглядит гораздо компактней и понятней. Поэтому, сомневаюсь в «практичности». Легче изучить — это да. Но и Бейсик легче изучить, чем Лисп или Си. Или VB тоже «куда практичней», чем Лисп или Си/Си++?

А если упадёт бэкэнд от hackish way фонатиков, то нужно будет просыпаться ночью, чтобы этот hackish way колупать с бешеными глазами от кофе и с торчащими волосами

Пока максимальное количество неожиданностей получал от Windows, причём на брендовых серверах. То HyperV отвалится, то процессоры вырубятся... а все советы сводятся к «переустановите Windows», попробуйте поставить не все обновления, переберите все комбинации обновлений. Так что коммерческая поддержка не панацея.

SBCL хотя бы имеет открытые исходники и в случае чего можно самому посмотреть, что там написано не так (или где использовал не так, как ожидает разработчик). Racket гораздо стабильней, но не потому, что он коммерческий, а из-за других приоритетов. Если есть выбор «будет работать быстро, но при непрерывной работе раз в год может упасть» и «будет работать на 30% медленней», то в SBCL всегда выберут первый вариант, а в Racket — второй. Из-за этого SBCL в среднем быстрее, чем Racket, но менее стабильный.

Поэтому, сомневаюсь в «практичности». Легче изучить — это да. Но и Бейсик легче изучить, чем Лисп или Си. Или VB тоже «куда практичней», чем Лисп или Си/Си++?

Не правильная аналогия. Бейсик вообще ни с чем не сравнимый язык. Даже с Коболом его нельзя сравнивать. (Кстати! Даже стандарт Кобола последний раз вышел в 2014 году!) Common Lisp и Racket это не как Бейсик или Си, но как Си и Си++. Своими наворотами Racket смахивает на Си++, в то время как Common Lisp остаётся таким же непосредственным, как Си.

Windows
Так что коммерческая поддержка не панацея.

Не панацея. Но я и не говорил о поддержке, а о том, что только коммерческий софт (софт, созданный профессионалами, которые этим зарабатывают на жизнь, а не студентами или фонатами) может обеспечить приемлемое качество функционирования системы. То, что Windows падает - это проблемы Microsoft и её пользователей. Альтернативы есть, и их разработка поддерживается группой огромных компаний. Ты же не будешь утверждать, что кто-то использует в продакшене ОС, созданную энтузиастами? Гыгы :-)

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

Можно, но лично у меня нет столько времени, чтобы изучать потроха SBCL. Зачем мне это? Я инвестировал время в изучение языка Common Lisp. Далее я хочу возврата инвестиций, и хочу просто писать на Common Lisp свои программы, которые будут приносить мне доход, а не ковыряться в реализации, чтобы заставить её работать так, как я ожидаю, или так, как описано в стандарте. Если бы я научился ваять потолки и короба из гипсокартона, мне бы непременно понадобился шуруповёрт. Я мог бы взять кустарный шуроповёрт, сделанный в подвале на соседней улице почти за даром с чертежами, чтобы потом постоянно чинить его, а мог бы купить какой-нибудь Makita, и с удовольствием делать короба и потолки. С такой философией лучше купить LispWorks и заниматься реализацией своих идей, а не выводить SBCL на новый уровень инженерного успеха.

Racket гораздо стабильней, но не потому, что он коммерческий, а из-за других приоритетов. Если есть выбор «будет работать быстро, но при непрерывной работе раз в год может упасть» и «будет работать на 30% медленней», то в SBCL всегда выберут первый вариант, а в Racket — второй. Из-за этого SBCL в среднем быстрее, чем Racket, но менее стабильный.

Эти приоритеты продиктованы как раз тем, что он коммерческий. Не могут позволить себе разработчики, получающие финансирование, выдавать продукт, который будет на 30% быстрее, но будет падать. Потому что инвесторы этого не поймут. :-)

Ага, макры Common Lisp куда практичней, несмотря на отсутствие гигиены :-)

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

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

Своими наворотами Racket смахивает на Си++

Какими наворотами-то? По-моему это миф какой-то. Все время говорят о наворотах, но не могут их назвать.

Все время говорят о наворотах, но не могут их назвать.

Спасу твое изнуренное любопытство: http://docs.racket-lang.org/reference/index.html

Чето я в доках не нашел ничего про невозможность вызова гц.

Смотри про async-apply. Если вкратце, то на самом деле функция Racket будет выполняться в основном потоке, а в птред уйдёт только результат выполнения. А значит гц будет запущен (если надо) тоже в основном потоке.

Common Lisp и Racket это не как Бейсик или Си, но как Си и Си++

Даже, наверное, соглашусь. И споры вокруг макросов аналогичны спорам вокруг указателей в Си и Си++.

Какими наворотами-то? По-моему это миф какой-то.

Видимо, имеется в виду:

> (length (namespace-mapped-symbols (make-base-namespace)))
1442

* (length (let ((lst ()))
   (do-symbols (s (find-package 'cl)) (push s lst))
   lst))
978

А, ок:

If async-apply is a procedure, the call in the foreign thread is transferred to the OS-level thread that runs Racket

В чем смысл-то тогда? Параллельно два куска racket-кода, значит, не запустить?

С такой философией лучше купить LispWorks и заниматься реализацией своих идей, а не выводить SBCL на новый уровень инженерного успеха.

Согласен. Жаль, Lispworks (и Allegro) отсутствует на http://benchmarksgame.alioth.debian.org/. Интересно было бы сравнить скорость.

И где там навороты?

В чем смысл-то тогда?

Есть у тебя многопоточная библиотека на Си. Ей надо передать колбэк из Рэкета. Данный финт позволяет передать колбэк и не рисковать падением системы.

Параллельно два куска racket-кода, значит, не запустить

Через pthread — нет. Только через place или future.

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

Есть у тебя многопоточная библиотека на Си. Ей надо передать колбэк из Рэкета. Данный финт позволяет передать колбэк и не рисковать падением системы.

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

Через pthread — нет. Только через place или future.

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

(define gc-enable! (get-ffi-obj "scheme_enable_garbage_collection" lib (_fun _int -> _void)))
(define gc-minor! (get-ffi-obj "GC_gcollect_minor" lib (_fun -> _void)))

Не думаю, что будет существенная разница. SBCL при выдрочке оптимизаций и на (safety 0) генерит часто практически оптимальный код в рамках семантики, там особо некуда улучшать.

Только через place или future.

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

это по-моему какой-то плохой критерий

А какой хороший? Посчитать страницы стандарта/спецификации? Так будет ещё хуже — раздутым будет считаться язык с лучшей (подробной) документацией.

общепризнанно bloated-плюсы

bloated на фоне жабки и сисярпа? Сомневаюсь.

А какой хороший? Посчитать страницы стандарта/спецификации? Так будет ещё хуже — раздутым будет считаться язык с лучшей (подробной) документацией.

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

SBCL при выдрочке оптимизаций и на (safety 0) генерит часто практически оптимальный код

Я не спорю. Я сомневаюсь в том, что Lispworks и Allegro генерят оптимальный код. Так как «Не могут позволить себе разработчики, получающие финансирование, выдавать продукт, который будет на 30% быстрее, но будет падать».

Хотя кривой код Lispworks роняет. Причём не в отладчик а совсем.

bloated на фоне жабки и сисярпа?

Ну вот, тут важно что подразумевается под bloated. Потому я и спросил о каких наворотах речь. Наличие ООП - это наворот? Или юнит-тесты в стандарте - наворот? Или что по его мнению «навороты»? Я хз.

Я сомневаюсь в том, что Lispworks и Allegro генерят оптимальный код.

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

в котором искаробки батареек больше

Я не считал батарейки. Я считал неотключаемые возможности. Для CL это пакет CL, для Racket — модуль racket/base.

Я не считал для CL пакеты sb-* (в которых те же потоки, FFI, управление сборщиком мусора и т.д.), а для Racket полный пакет racket (в котором действительно достаточно много «батареек») и тем более racket/gui, ffi/*, net/*, ....

Хотя кривой код Lispworks роняет.

От оно (safety 0) во всей красе. Вообще, кстати, его хоть кто-то в продакшене ставит? На мой взгляд просто классический отстрел обеих ног.

Я не считал батарейки. Я считал неотключаемые возможности. Для CL это пакет CL, для Racket — модуль racket/base.

Есть еще '#%kernel. Ну и такт-то в racket надо тогда считать весь racket, потому что racket/base - это не то что неотключаемые возможности, это просто понабрали то, что наиболее нужно, и выделили чтобы память не жрало.

От оно (safety 0) во всей красе

SBCL не падает:

* (proclaim '(optimize (safety 0) (speed 3)))

* (defun should-flip-block (rowlist)
  (declare ((vector number) rowlist))
  (if (= (length rowlist) 0) (eval nil) 
    (let* ((exithigh (= (car (last rowlist)) 2))
           (enterhigh (= (first rowlist) 2)))  
      (and exithigh enterhigh))))
; in: DEFUN SHOULD-FLIP-BLOCK
;     (LAST ROWLIST)
; ==>
;   (SB-KERNEL:%LAST1 ROWLIST)
; 
; caught WARNING:
;   Derived type of ROWLIST is
;     (VALUES (VECTOR NUMBER) &OPTIONAL),
;   conflicting with its asserted type
;     LIST.
;   See also:
;     The SBCL Manual, Node "Handling of Types"
; 
; compilation unit finished
;   caught 1 WARNING condition

SHOULD-FLIP-BLOCK
* (should-flip-block '(1 2 1 2 1))

debugger invoked on a SIMPLE-TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1003B864D3}>:
  Value of ROWLIST in(SB-KERNEL:%LAST1 ROWLIST) is (1 2 1 2 1), not a LIST.

Вообще, кстати, его хоть кто-то в продакшене ставит?

Что понимать под продакшеном? Если веб-сервис или что-то подобное, то, думаю, дураков нема. А если, например, вычисление физического процесса или ещё какая вычислительная фигня, то после отладки на живых данных запускают с максимальной оптимизацией. Так как 5 часов вычислений или 50 — разница большая.

SBCL не падает:

Мне так кажется, что lispworks и ворнинг там не ставит. А сбцл не падает именно потому что ворнинг - то есть понимает, что оптимайзить там чегото нельзя.

А если, например, вычисление физического процесса или ещё какая вычислительная фигня

Не думаю, что кто-то на лиспе подобные вещи пишет. Я бы точно не стал.

Я бы точно не стал.

Отладка благодаря разработке в образе существенно быстрее. То есть если время разработки неделя (на лиспе), а время запуска 5 часов, то лучше написать за неделю на лиспе, чем писать две недели на Си++ и сэкономить 3 часа на времени запуска.

А сбцл не падает именно потому что ворнинг - то есть

Нет. Не падает, так как записи по адресу переменной не производится, а cl:last вызывает SB-KERNEL:%LAST1, который проверяет тип параметра всегда (разве что ядро SBCL тоже перекомпилировать с safety = 0)

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