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

Open source далеко не всегда развивается исключительно на энтузиазме. Корпорации вкладываются в open source отнюдь не just for fun. Но тебе уже проясняли этот момент в этом треде. Но ты продолжаешь тупить. Это твои какие-то проблемы.

Чудак, мне этот момент хорошо известен, так как это я и прояснял в этой дискуссии :-) Хехе. :-) Только вот корпорации вкладываются отнюдь не в Lisp :-)

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

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

если GUI действительно приятно будет писать

https://github.com/Kalimehtar/gtk-cffi — сплошной CLOS. Полная поддержка GTK. Причём с нормальными callback'ами:

(defparameter *calculator*  
  (gtk-model
   'window :title "GTK test"
   :signals (list :key-press-event 
                  (lambda (widget event)
;                    (declare (ignore widget ))
                    (do-all (parse-key  (get-slot event :keyval)))
                    (format t "~a ~a~%" widget event))
                  :destroy :gtk-main-quit)
   ('table
    :kids (append
           (list (list 4 (make-instance 'label :text "Калькулятор")))
           (list (list 4 (make-instance 'label :id :display)))
           (build-buttons
            '((7 8 9 +)
              (4 5 6 -)
              (1 2 3 *)
              (0 nil = /)))))))

(defun build-buttons (table)
  (mapcar
   (lambda (row)
     (mapcar 
      (lambda (elem)
        (when elem
          (make-instance 'button
           :label (princ-to-string elem)
           :signals 
           (list :clicked
                 (lambda (&rest rest)
                   (declare (ignore rest))
                   (do-all elem))))))
      row)) table))

Как видно из кода, в качестве callback успешно работает замыкание, созданное через (lambda ...)

Если будет действительно удобный API спроектированный в духе Lisp

Есть https://github.com/robert-strandh/McCLIM . В качесте бэкенда CLX, OpenGL и другие. Всё в духе Lisp. Но никто на нём не пишет. Есть пара приложений, написанных ещё разработчиком McCLIM и всё. :-(

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

Ну ё-моё. Даже реализация Lisp frontend-а с хорошим дизайном к Tk, покрывающая хотя бы половину возможностей Tk - hardwork. Если тебе вдруг не хватило каких-то возможностей Tk, то это значит ты придумал какой-то новый инновационный UI с каким-то революционным подходом. Я конечно допускаю, что это я безыдейный мудак. Но вот уже 4 год пошёл, как я кручу верчу непосредственно LTK на реальных и выдуманных GUI задачах, допиливаю его, пытаюсь придумать нечто, что позволит повысить эффективность в сравнении с существующими в мире подходами и как-то ничего революционного так и не придумал. И только вот не так давно сложилась картина API, который весьма удобен с низким порогом вхождения (по моему, конечно, разумению). Но, чёрт возьми, Tk для этого API более чем достаточно.

https://github.com/Kalimehtar/gtk-cffi — сплошной CLOS. Полная поддержка GTK. Причём с нормальными callback'ами

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

Как видно из кода, в качестве callback успешно работает замыкание, созданное через (lambda ...)

Я понимаю, что это было, подозреваю, не просто сделать. В своём коде мне приходится тоже извращаться, что бы так сделать. Но именно таки это должно быть :)

Кстати, я понимаю твою грусть. Вот hint тебе. Даже если ты написал действительно стоящую вещь, нужно ещё уметь её, так сказать, «продать». Документация нужна определённо. Напиши документацию, черкни на reddit и feedback не заставит себя ждать.

Мне кажется, что твоей либе не хватает документации и примеров.

Не хватает. Но программирую я лучше, чем пишу.

Примеры там есть в папке examples.

+ https://github.com/Kalimehtar/cl-dbf/tree/master/dbfview

+ https://github.com/Kalimehtar/gtk-cffi/tree/master/cl-emacs

Я понимаю, что это было, подозреваю, не просто сделать.

В GTK все callback'и имеют вид f(a, b, c ...., void* data), где data — данные, передаваемые вместе с callback'ом. Дальше дело техники: хэш(указатель, замыкание) и немножко синтаксического сахара.

Документация нужна определённо. Напиши документацию, черкни на reddit и feedback не заставит себя ждать.

Кстати, нашёл от «конкурента»: http://www.crategus.com/books/cl-gtk/gtk-tutorial.html

Ну супер. Ты живёшь в каком-то параллельном мире. Прослеживается юношеский максимализм. У тебя есть на примете с пару тысяч суровых Lisp-еров, которым ты готов платить достойную плату и заменеджить на великие изобретения и переписывание?

В мире, в котором мы живём, есть на примете пара тысяч суровых лисперов маргиналов, которые вот уже много лет переливают из пустого в порожнее. Все они сидят по своим углам и вечно устраивают споры. Почти никогда не приходят к консенсусу, из-за чего каждый считает, что его мнение единственно правильное, и пилит тарабарщину, которую через несколько лет бросает, потому что эта тарабарщина никому и даром не нужна. Думаешь, кто-то будет пользоваться твоими потугами, кроме тебя? :-) Гыгы. А в результате такой деятельности, Common Lisp в полной стагнации. Все, кто всерьёз программировал на CL, набаловавшись, бросают это дело. Потому что многие из них, как они говорят, «не видят будущего у этого языка». (Они правы.) Примеров тому много. Автор weblocks, автор Postmodern, изначальный автор Parenscript. Где там Пол Грэм, где там Пётр Сайбель? Чем дольше это сообщество не организуется и не признается, что нужно создавать свою инфраструктуру сообща, тем быстрее Common Lisp попадёт в музей :-) Или так и будет уделом горстки лентяев-маргиналов-эмо-панков-рокеров-или-ещё-хрен-пойми-какой-субкультуры, ваяющих биндинги к библиотекам на C :-)

Сомневаюсь. Судя по постам, ты настолько далёк от реальности, что пипец.

А я сомневаюсь в будущем Common Lisp :-) И кто из нас далёк от реальности, а? :-)

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

Сообщество и экосистема Common Lisp развивается точно также как и в других ЯП. Нет никаких отличий. Работают те же самые законы. Удобные и хорошие решения приживаются и входят в обиход, решения которые не выдерживают конкуренцию - умирают. Просто экосистема CL развивается медленнее, ввиду малочисленного сообщества. Но есть мысль, что развитие и популярность набирает обороты в т.ч. и в русскоязычном сегменте. Не в последнюю очередь благодаря появлению на свет Quicklisp. Это радует. Ведь сам по себе Common Lisp как язык - блестящий инструмент.

Думаешь, кто-то будет пользоваться твоими потугами, кроме тебя? :-) Гыгы.

Это покажет время. Будут пользоваться - отлично. Не будут - значит я что-то делаю не так. Осознаю, исправлюсь и попробую снова.

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

Кто-то разочаровываться, кто-то нет и продолжает использовать. Как и в любой другом ЯП. Никакой разницы. CL тут ни при чём. Кому-то, например, нужен высокий уровень надёжности и CL их не устраивает. Да как-бы никаких проблем. Я занимаюсь таким ПО от которых не ожидается невероятная надёжность. Ожидаются идеи и фичи, которые должны быстро пилиться с приемлемой надёжностью. CL меня полностью устраивает.

А я сомневаюсь в будущем Common Lisp :-)

Да твоё мнение, как-бы нулю равно. Ты же просто анонимный пиздобол, который вообще не в курсе предмета разговора. Кстати, я сообщения вообще не тебе пишу, а читателям.

Где там Пол Грэм, где там Пётр Сайбель?

Да как бы если Seibel или Graham однажды написали отличные книги по Lisp, это должно означать что они должны до самой смерти долбить код на Lisp и писать книги? Да хер тебе. Никто никому ничего не должен.

А я сомневаюсь в будущем Common Lisp :-)

Да похуй на тебя. Что ты в этом треде забыл, вообще не понятно.

И кто из нас далёк от реальности, а? :-)

Ты.

Просто экосистема CL развивается медленнее, ввиду малочисленного сообщества.

Да она не развивается. В стагнации она. Застой :-)

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

«Библиотечный» подход, заимствованный из C, - это путь к неправильному использованию Lisp. Вместо создания DSL, пилятся сотни никому ненужных недоделанных поделок, доступных через Quicklisp (5 лет в стадии beta) :-)

Ведь сам по себе Common Lisp как язык - блестящий инструмент.

Это да. На бумаге в книжках, да в стандарте :-)

Да как бы если Seibel или Graham однажды написали отличные книги по Lisp

Ну Сайбель вполне себе пишет на работе на PHP, Scala, Python и Java, а не на Lisp :-) А где там «новый» Lisp от Грэма - Arc? :-)

Да она не развивается. В стагнации она. Застой :-)

Действительность говорит об обратном.

«Библиотечный» подход, заимствованный из C, - это путь к неправильному использованию Lisp.

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

Вместо создания DSL...

Facepalm :) Всё ясно.

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

Правильное использование Lisp - это создание DSL, который потом генерирует код. «Программы, которые пишут программы, которые пишут программы». И это придумал не бестолковый аноним, это хорошо написано в том же On Lisp. :-) А вот задроты со своими бестолковыми библиотеками и биндингами к FFI - вот они все в тему то и не вхожи :-)

на PHP, Scala, Python и Java

Ну вот и ты давай скорее сваливай отсюда. Хоп-хоп.

Правильное использование Lisp - это создание DSL, который потом генерирует код.

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

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

Видимо мешает, раз никто из задротов не хочет «переизобретать» и писать «родные» приложения на Lisp, избегая «hardwork» :-) Мне же только остаётся пожать плечами и констатировать факт этого. И то, что в Quicklisp полно ненужных потуг - это тоже факт. И вместо того, чтобы использовать преимущества Lisp как метаязыка, и под каждую конкретную задачу писать свой DSL, предлагаются писать библиотеки и выкладывать их в Quicklisp. Что поделать, такова реальность. :-)

Ну вот ракетку так и используют. Все ок.

Правильное использование Lisp - это создание DSL, который потом генерирует код.

Был проект hu.dwim. Делали именно так. Создали пачку DSL'ей для ORM + Web-framework + computed-cells. Так широкого распространения не получили. Именно потому что DSL. Мол «этот наркоманский код понять невозможно» (с) (archimag или love5an).

Кстати в Racket как раз подход обратный: используй макрос только тогда, когда невозможно использовать функцию.

никто из задротов не хочет «переизобретать» и писать «родные» приложения на Lisp, избегая «hardwork»

Возьми тот же GUI. Если писать «ещё один» тулкит, то он будет всюду выделяться как бельмо на глазу (вспомни Swing в Java). К тому же, если в Linux я ещё могу писать в X просто через сеть, то в Windows хоть GTK дёргай, хоть WinAPI — всё равно нужен FFI.

А где там «новый» Lisp от Грэма - Arc?

http://arclanguage.org/

И на github по language = Arc есть сотня репозиториев

ycombinator до сих пор на арке, по-моему.

(вспомни Swing в Java)

Да ладно тебе, какое бельмо? AWT/Swing в Java используется в каждом приложении. Да, они не идеальны, но ими просто пользуются и делают очень полезные программы. Ну та же IDEA. Ты где-нибудь видел приложение на Java, которая свой GUI рисует с помощью GTK или Qt через JNI? :-) Смешно, не правда ли? :-)

http://arclanguage.org/

Ну да, пардон, сайтишко, который надо смотреть под лупой, чтобы глаза не выкатились, висит. (Интересно, ВиаВЭБ такой же внешний вид имел?) :-) Проходим по второй ссылке The first priority right now is the core language. — 2008 год. Прошло уже 7 лет. Читаем дальше «Number one, expect change. Arc is still fluid and future releases are guaranteed to break all your code.» Сайтишко можно закрывать :-)

AWT/Swing в Java используется в каждом приложении.

AWT — это GTK/WinAPI/Cocoa (в зависимости от платформы). А Swing — это ужас, который всюду выглядит инородным, как только рабочий стол хоть чуть-чуть настроен.

Точнее был ужас до Java 1.6, а теперь там тоже GTK:

http://www.ensode.net/java_swing_mustang_screenshots_gtk.html

Ты где-нибудь видел приложение на Java, которая свой GUI рисует с помощью GTK или Qt через JNI?

http://www.ibm.com/developerworks/ru/library/l-libjava_2/index.html

http://www.eclipse.org/swt/faq.php#gtkstartup

А Swing — это ужас, который всюду выглядит инородным, как только рабочий стол хоть чуть-чуть настроен.

Ну знаешь, по такой логике, Qt - это тоже «ужас, который всюду выглядит инородным, как только рабочий стол хоть чуть-чуть настроен», ибо не похож ни на GTK, ни на WinAPI, ни на Cocoa.

http://www.ibm.com/developerworks/ru/library/l-libjava_2/index.html

Ну и зачем вот это надо, если сам сказал, что «AWT — это GTK/WinAPI/Cocoa (в зависимости от платформы)»? А кроме того ...

http://www.eclipse.org/swt/faq.php#gtkstartup

... а кроме того, есть вот этот SWT, который, как я понял, тоже есть абстракция, аналогичная AWT. Но я, вообще-то, просил конечные приложения, использующие JNI для отрисовки GUI с помощью GTK, а не библиотеки абстракций от корпораций монстров :-) Ну да ладно.

Qt - это тоже «ужас, который всюду выглядит инородным, как только рабочий стол хоть чуть-чуть настроен», ибо не похож ни на GTK, ни на WinAPI, ни на Cocoa.

Полностью согласен. И именно поэтому несмотря на его «переносимость», пользуются им в основном в Linux.

Ну и зачем вот это надо, если сам сказал, что «AWT — это GTK/WinAPI/Cocoa (в зависимости от платформы)»

AWT — это то, что есть во всех трёх библиотеках. Если в одной из них нет, то в AWT нет. Поэтому на GTK просто больше элементов.

Но я, вообще-то, просил конечные приложения, использующие JNI для отрисовки GUI с помощью GTK, а не библиотеки абстракций

Так смысл использовать напрямую JNI если есть «библиотеки абстракций»? В CL ты тоже не встретишь программу, в которой напрямую (cffi:funcall «gtk_init» nil) (cffi:funcall «gtk_window_new» ...) ... Тоже используются «библиотеки абстракций»

Так смысл использовать напрямую JNI если есть «библиотеки абстракций»?

Так об этом то я и говорю, что так не делают, а используют AWT/Swing. :-)

В CL ты тоже не встретишь программу, в которой напрямую (cffi:funcall «gtk_init» nil) (cffi:funcall «gtk_window_new» ...) ... Тоже используются «библиотеки абстракций»

Согласен. Но изначально я говорил, что считаю необходимым создание стандартной библиотеки GUI для Common Lisp, написанной на Common Lisp, хотя бы наподобие AWT/Swing в Java. И кстати, Swing предпочтительней, т.к. может не только рисовать собственные виджеты, но и использовать более низкоуровневый AWT для отрисовки «родных» для окружения виджетов. :-) Вот такое я бы хотел видеть в Common Lisp.

Вот такое я бы хотел видеть в Common Lisp.

Так это есть. Я же уже давал ссылку: https://github.com/robert-strandh/McCLIM

Пользуйся!

Так это есть. Я же уже давал ссылку: https://github.com/robert-strandh/McCLIM

Спасибо, я посмотрю на досуге. Правда, я не слышал ровным счётом ничего об использовании этого, но из любопытства посмотрю. Человек сделал почти 3 тысячи коммитов, вдруг там будет что-то интересное? :-) О, кстати, этот же человек пилит новую реализацию Common Lisp SICL! Ещё одна попытка... :-) Такие люди, конечно, вызывают больше уважение, что пытаются сделать что-то новое, только жаль, что зачастую они привлекают к себе мало внимания и варятся в собственном соку наедине со своими коммитами. Спасибо за ссылки!

Правда, я не слышал ровным счётом ничего об использовании этого

https://en.wikipedia.org/wiki/Common_Lisp_Interface_Manager

Человек сделал почти 3 тысячи коммитов,

Ну не все. Он последний сопровождающий. А так проекту (http://common-lisp.net/project/mcclim/) лет 15. http://cliki.net/clim

Guide по CLIM от Franz считается самым нескучным.

Ну ё-моё. Даже реализация Lisp frontend-а с хорошим дизайном к Tk, покрывающая хотя бы половину возможностей Tk - hardwork.

Это не нужно. Если что и нужно, то сделать для Tcl/Tk отладчик как в лиспе и compile-defun. Тогда на Tcl/Tk можно будет работать как на лиспе. Ещё неплохо бы сделать что-то типа компилятора для проверки соответствия неким политикам. Tcl/Tk - это тоже своего рода лисп.

Если что и нужно, то сделать для Tcl/Tk отладчик как в лиспе и compile-defun.

Tcl/Tk - это тоже своего рода лисп.

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

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

Аналог макросов в нём есть. В любом случае, если ты работаешь с tk, тебе не объехать tcl. И доку по tcl и tk тебе придётся читать всё равно, какие обвязки не возьми. Разве только они будут полностью изолировать tk (но нужно ли это?) Поэтому, есть там компилятор, нет там компилятора - ты будешь его использовать. Компилятор в байткод там давно уже есть. Функционал замыканий реализуется различными несложными способами.

сделать для Tcl/Tk отладчик как в лиспе и compile-defun

Tloona was inspired by Eclipse and Lisp/SLIME ?

Причём аналог макросов как минимум не уступает defmacro по гибкости. Не знаю, хорошо ли это или нет, но это так. Вот тебе пример применения DSL для ООП.

Tloona was inspired by Eclipse and Lisp/SLIME ?

Не знаю, в таких деталях не смотрел. Вдохновиться - это одно, а допилить - это несколько другое.

В любом случае, если ты работаешь с tk, тебе не объехать tcl

Есть perltk, tkinter, http://kaolin.unice.fr/STk/

STk точно полностью независим от TCL. Про остальные точно не помню.

Причём аналог макросов как минимум не уступает defmacro по гибкости.

Напиши loop. Или iterate.

Или хотя бы

(defmacro once-only ((&rest names) &body body)
  (let ((gensyms (loop for n in names collect (gensym))))
    `(let (,@(loop for g in gensyms collect `(,g (gensym))))
      `(let (,,@(loop for g in gensyms for n in names collect ``(,,g ,,n)))
        ,(let (,@(loop for n in names for g in gensyms collect `(,n ,g)))
           ,@body)))))

Tcl/Tk - это тоже своего рода лисп.

Этот своего рода «лисп», наверное, довольно тормозной? :-)

Тогда на Tcl/Tk можно будет работать как на лиспе.

Нашёл правильную цитату-ответ:

Конечно сущий пустяк, что в Tcl нет вменяемых замыканий и всё программирование на классическом Tk сводится к модификации сраного глобального контекста с прострелом всех конечностей. То ли дело скобки - вот это проблема!

Вот добавят в Tcl нормальных замыканий, макросов, сигналов, развитую систему типов, продвинутый ООП и уберут очевидно опасное говно, навроде uplevel, тогда Tcl станет Lisp-ом. Только плохим, с кучей разных видов скобок. Если Tcl доживёт, это где-то будет к 3000 году. Ожидай. А мы пока на Lisp-е попишем

Вообще, John Ousterhout не знал и не понимал Lisp, поэтому он придумал свой и назвал его Tcl. У него получилось плохо, не продуманно. У Маккарти лучше получилось.

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

Ах да, чуть не забыл: и напишут эффективный компилятор. Короче, где-то 3500 год.