Clasp, одна из новых реализаций CL, всего лишь в четыре раза медленнее, чем C++

Другое дело что качественных библиотек в CL действительно не хватает. Но сейчас ситуация потихоньку исправляется

Эту мантру можно слушать бесконечно, ситуация минимум уже лет десять подряд исправляецо и исправляецо.

Эту мантру можно слушать бесконечно, ситуация минимум уже лет десять подряд исправляецо и исправляецо.

Да ну, не так давно всё стало получше. В тот момент как появился Quicklisp. Но вы можете продолжать ныть о «ненужности Lisp» и о мантрах, тогда как я собираются поучаствовать в развитии Common Lisp.

собираются

собираюсь

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

(может поэтому нет ни одного полнофункционального графического пользовательского интерфейса, так как в одиночку сделать нереально, даже если делать FFI к GTK)

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

то сейчас многие бы писали на Racket. Потому как с т.з. некоторых наблюдателей, Racket правильно ограничен и ориентирован на разработку большими командами.

Racket изначально позиционировался (рекламировался) как язык для обучения.

Если брать динамику по githut, то рост более чем четырёхкратный.

Крупные проекты на Racket: http://untyped.com/ http://www.getkahu.com/ https://news.ycombinator.com/item?id=2201964

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

Я писал https://github.com/Kalimehtar/gtk-cffi/, https://github.com/andy128k/cl-gobject-introspection

Пока я его писал, успел появится и завершиться https://github.com/dmitryvk/cl-gtk2/

Причём до этого были https://common-lisp.net/project/lambda-gtk/, https://common-lisp.net/project/cells-gtk/, ...

Сейчас снова «нет полнофункционального биндинга к GTK». И следующий, кому понадобится, опять наваяет свой велосипед с готовностью в 30%.

Ты, я так понял, пишешь биндинг к Tcl/Tk. Причём, не развиваешь http://www.peter-herth.de/ltk/ или http://sourceforge.net/projects/cl-fff-tcl-tk/, а пишешь свой велосипед? Так? Если да, то почему?

Я писал https://github.com/Kalimehtar/gtk-cffi/, https://github.com/andy128k/cl-gobject-introspection

Круто. А почему не развиваете? Нашлись какие-то принципиальные сложности?

Ты, я так понял, пишешь биндинг к Tcl/Tk. Причём, не развиваешь http://www.peter-herth.de/ltk/

Ltk работает через wish и ужасен внутри. Плохо расширяем и мне не нравится интерфейс работы с ним. У меня несколько другое понимание удобного интерфейса. Я пишу основываясь на cffi, то есть Tcl интерпретатор запускается в образе. Также поддержку BWidgets считаю важной вещью, которая обязательно должна быть. Основная цель - лаконичный и удобный интерфейс работы с Tk - без особого порога вхождения. Короче, хочу сделать работу с Tk удобнее и безопаснее, чем на Tcl.

http://sourceforge.net/projects/cl-fff-tcl-tk/

Вот эту штуку, к сожалению, первый раз вижу. Посмотрю исходники. Спасибо.

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

Да ну, не так давно всё стало получше.

Ага, выше уже написали.

тогда как я собираются поучаствовать в развитии Common Lisp.

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

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

А создать что-то свое, не? Вот есть же ж крайне убогий и закрытый CAPI, почему бы не сделать что-то нормальное вместо него? Или истинный путь лиспера - написать 100500 оберток поверх кода на С?

Значит добавятся еще несколько новых трупиков в общей братской могиле наколенных поделок.

Я уж постараюсь, что бы это было не так. А как будет, будем посмотреть. Сейчас пока говорить рано.

Это неплохо на самом деле, у всех языков таковые имеются, но настоящее развитие заключается не в этом.

Развитие заключается в наличии качественных решений с ответственной поддержкой. Именно по этому пути я и собираюсь пойти. Посмотрим что из этого выйдет.

А создать что-то свое, не?

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

Или истинный путь лиспера - написать 100500 оберток поверх кода на С?

Разговоры про «истинные» пути - это религия. Я не вижу ничего плохого в использовании готовых, отлаженных решений. Совершенно без разницы на чём они написаны. Написаны на Си - хорошо. Какие-то проблемы?

100500 оберток

Если бы. Из этих обёрток, качественных - пару штук.

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

Да, но если не браться за такие задачи - ничего абсолютно не изменится.

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

Можно сделать так - выписываешь вменяемый минимальный интерфейс, каким ты его хочешь видеть, предварительно посмотрев что у кого как. Предусматриваешь в реализации наличие нескольких бэкэндов, и пишешь первый из них, например, под тот же Tk. Как только он работает - замечательно, у тебя уже есть результат и можно спокойно отдельно пилить бэкэнды под cocoa, win32, gtk и пр. Ну и расширять интерфейс по необходимости.

Да, но если не браться за такие задачи - ничего абсолютно не изменится.

Ну как сказать. Оставаясь в контексте рассуждений про GUI, то если взять, например Python, то Qt для Python или TkInter вполне себе в ходу и пользуются весьма широкой популярностью. Никто не пилит GUI на Python с нуля и в тоже время все, в целом, довольны существующими «обёртками». Хотя тот же TkInter достаточно ограничен и далеко не вершина удобства, на мой взгляд, но тем не менее приемлем и на нём пишут.

Какие-то проблемы?

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

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

Мысль конечно правильная. Но это сделать чертовски сложно, как бы не казалось на первый взгляд :) Например, написать какой-то frontend для geometry managers и натянуть на парочку GUI библиотек, что бы это хотя бы выглядело немного одинаково - очень сложно.

Ну как сказать. Оставаясь в контексте рассуждений про GUI, то если взять, например Python, то Qt для Python или TkInter вполне себе в ходу и пользуются весьма широкой популярностью

Да, и проблем с библиотеками там меньше. А еще там сделали по умному - модули можно писать сразу на С и С++:

https://docs.python.org/3/extending/extending.html

И это активно используется, что очевидно на порядки (с) увеличивает кол-во людей, которые могут принять участие в разработке и поддержке. Тот же PyQt практически полностью написан на С++.

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

Я понял, ты полагаешь, что писать «обёртки» - это легче лёгкого? Спешу обрадовать. Конкретно в моём случае, непосредственно сама низкоуровневая «обёртка» - это маленький файлик с парой десятков defcfun-ов. Ведь просто перенести интерфейс работы с Tk - это не решение задачи. Дизайн и разработка lispy интерфейса - вот основная задача. Это и есть самое сложное и интересное.

Я понял, ты полагаешь, что писать «обёртки» - это легче лёгкого?

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

Дизайн и разработка lispy интерфейса - вот основная задача. Это и есть самое сложное и интересное.

Ага, это то самое, что для другого лиспера «менее трудозатратно написать заново» (с).

выписываешь вменяемый минимальный интерфейс

Предусматриваешь в реализации наличие нескольких бэкэндов, и пишешь первый из них, например, под тот же Tk. Как только он работает - замечательно, у тебя уже есть результат и можно спокойно отдельно пилить бэкэнды под cocoa, win32, gtk и пр

И такое есть: https://common-lisp.net/project/mcclim/

И такое есть

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

Нет, это нудная и монотонная работа.

Хм. Это почти та же самая работа, что и писать «с нуля». Только «с нуля» ещё понадобится зачем-то разрабатывать низкоуровневые вещи. В остальном всё тоже самое, придётся проектировать и писать lispy интерфейс. Последнее я бы не назвал нудной работой, весьма творческий процесс. Ведь проектируешь ты на своё усмотрения, с учётом своих взглядов, предпочтений и интуиции.

Крупные проекты на Racket

Только я ни про один полезный для меня не слышал и не видел.

Хм. Это почти та же самая работа, что и писать «с нуля»

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

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

Не согласен. Зачем тебе поддерживать чужое? Проектируй и поддерживай свой API, ну периодически добавляй backend-а. Вот, хороший, простенький пример: я тут just for fun писал binding к sophia - https://github.com/multimethod/cl-sophia. Вот set/get на Си:

void *env = sp_env();
void *ctl = sp_ctl(env);
sp_set(ctl, "sophia.path", "./storage");
sp_set(ctl, "db", "test");
int rc = sp_open(env);
if (rc == -1) {
    /* error */
}
void *db = sp_get(ctl, "db.test");

char key[] = "hello";
char value[] = "world";


/* get */
o = sp_object(db);
sp_set(o, "key", key, sizeof(key));
void *result = sp_get(db, o);
if (result) {
    int valuesize;
    char *value = sp_get(result, "value", &valuesize);
    printf("%s\n", value);
    sp_destroy(result);
}

/* finish */
rc = sp_destroy(env);
if (rc == -1) {
    /* error */
}

(with-database ("test.db")
  (setf ($ "hello") "world")
  ($ "hello"))

добавляй backend-а

Фичи backend-а.

Чувствуешь разницу?

Да, у тебя в коде на лиспе напрочь отсутствуют проверки ^_^. Или ты думаешь авторы sophia такие идиоты и не осилили написать несколько новых функций, чтоб тоже все было в три строки?

Да, у тебя в коде на лиспе напрочь отсутствуют проверки ^_^

Хех. У меня там проверок побольше, чем в самой sophia, если что.

Или ты думаешь авторы sophia такие идиоты и не осилили написать несколько новых функций, чтоб тоже все было в три строки?

Видимо не осилили.

Круто. А почему не развиваете? Нашлись какие-то принципиальные сложности?

Устал пилить в одиночку. Тем более, что по ходу дела пришлось сделать https://github.com/Kalimehtar/cffi-objects/blob/master/redefines.lisp , а это как раз то, что делает CFFI в присутствии GTK-FFI и без него слегка разным.

В процессе, пытался бороться с неудобствами лиспа (пакетам нельзя дать псевдонимы в рамках одного пакета или файла, обобщённые функцие не могут иметь реализации с разным количеством аргументов, ...). Сделал пачку костылей: https://github.com/Kalimehtar/advanced-readtable https://github.com/Kalimehtar/message-oo .

А потом обнаружил, что есть Racket, где все эти проблемы решены + решено ещё несколько, о которых я не задумывался (гигиена в макросах: например, можно сделать нормальный aif; раздельная компиляция: в CL есть XCVB, но под него нет пакетов; продолжения; нормальные финализаторы: в SBCL нельзя ссылаться на финализируемый объект; ...). Поняв, что, например, продолжения и финализаторы я точно сам не напишу, я ушёл на Racket.

Кстати, CLOS в Racket сделать можно (ради эксперимента сделал аналог CLOS на типах, а не классах: https://github.com/Kalimehtar/gls/blob/master/gls/test.rkt). Там кроме специализатора EQL можно специализировать по любому условию и нет запрета на разное число аргументов:

(defgeneric fact)

(add-method fact
            (method ((x (and? integer? (>/c 1))))
                    (* x (fact (- x 1)))))
(add-method fact
            (method ((x integer?))
                    1))

(add-method fact
            (method ((x integer?) y)
                    2))

> (fact 5)
120
> (fact 5 1)
2

Хех. У меня там проверок побольше, чем в самой sophia, если что.

Чисто в обертке небось? А ее пользователь пусть лапу сосет, если что пойдет не так.

Видимо не осилили.

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

Хех. У меня там проверок побольше

В примере есть два куска /* error */, которые в твоём коде выброшены. Если их добавить (также комментарием), то разница уже не будет настолько дикой. Кроме того, sophia.path = ./storage и db = test у тебя захардкожены в with-database?

Чисто в обертке небось? А ее пользователь пусть лапу сосет, если что пойдет не так.

Если что-то пойдёт не так с самой sophia будет сигнализирован internal-error c кодом возврата. Всё тоже самое, что и в Си, только не нужно специально писать обработку ошибок, если предполагаешь что всё должно пройти гладко и в ином случае не имеет смысла продолжать работу. Если хочешь обработать - перехватывай internal-error.

Также будет дикой. В пример на CL добавится лишь handler-case с обработчиком internal-error - это 3 строки.

если предполагаешь что всё должно пройти гладко

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

sophia.path = ./storage

Да, определено динамической переменной. https://github.com/multimethod/cl-sophia/blob/master/sophia.lisp#L140

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

Ну ё-моё. Есть же проверка. Результаты низкоуровневых вызовов передаются в check-retcode - https://github.com/multimethod/cl-sophia/blob/master/sophia.lisp#L18-L23.

Просто тебе не нужно проверять явно. Если что-то не откроется или ещё чего - сигнализируется internal-error.

db = test

Нет. Название базы передаётся в with-database.

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

Да, не могут. Я, честно говоря, не представляю как бы такая функциональность выглядела в рамках CLOS.

гигиена в макросах: например, можно сделать нормальный aif;

Хм. Что значит нормальный aif? Чем классический aif не правильный?

Название базы передаётся в with-database.

У тебя в Сишном коде:

sp_set(ctl, "db", "test");
...
void *db = sp_get(ctl, "db.test");

А в твоём всё это сжалось в test.db

Хочешь сравнивать честно, так сравнивай честно, а не передёргивай.

А то я тоже могу написать на Си пару функций и сказать, что доступ к sopihia выглядит как

env = open_db("test.db");
my_get(env, "hello");
sp_destroy(env);

А потом обнаружил, что есть Racket, где все эти проблемы решены + решено ещё несколько, о которых я не задумывался (гигиена в макросах: например, можно сделать нормальный aif; раздельная компиляция: в CL есть XCVB, но под него нет пакетов; продолжения; нормальные финализаторы: в SBCL нельзя ссылаться на финализируемый объект; ...). Поняв, что, например, продолжения и финализаторы я точно сам не напишу, я ушёл на Racket.

Я с трудом представляют как всю эту функциональность, которая плохо или не работает в CL использовать для biding-а к GTK. Ты, наверное, как-то хитро решил всё написать :) Застарил проект. Посмотрю твой код на досуге.

Чем классический aif не правильный?

(defmacro aif (test then &optional else)
  `(let ((it ,test))
     (if it ,then ,else)))

(defmacro fwrite (stream x)
  `(aif ,stream (format it "~a" ,x) nil))

(fwrite t 3) ;  => 3
(aif 3 (fwrite t it)) ; => t

А в твоём всё это сжалось в test.db

Конечно. Так и задумывалось при проектировании интерфейса. На мой взгляд, сущности env, ctl - лишние, поэтому я выбросил это из frontend-а. При этом я не теряю доступ к функциональности по настройке. Все необходимые настройки и метаданные передаются в with-database.

Хочешь сравнивать честно, так сравнивай честно, а не передёргивай.

А что тут не честного? Этот код делает всё тоже самое. Даже больше и при этом выглядит так как должен выглядит код set/get к key-value БД.

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

Можешь как-то наверное, но тебе нужно будет учесть всю функциональность sophia при этом. Я всё самое интересное учитываю. Есть конечно фичи, которые не реализованы, но они расширяются без изменения уже имеющегося интерфейса.