Это все фигня. Если большинство посчитает что нужно, оно и будет. Так как были в свое время пуристы, которые отстаивали минималистичность scheme, но на их мнение наплевали, и вышла R6RS со свистелками и перделками. Мнение меньшинства в расчет не берется никогда. А в коммерческом использовании законодателем мод будут корпорации, и они наложат на мнение кого бы то ни было.

Остались ли ещё в России пользователи Common Lisp?

Да https://github.com/Lovesan?tab=repositories

Вообще, как бы, считается, что если реализация заявляет соответствие спеке такой-то, то оно должно быть:) Это не «желаемое», это вранье тогда получается:).

Спецификация предписывает наличие функций FINISH-OUTPUT, FORCE-OUTPUT, CLEAR-OUTPUT, которые «exercise control over the internal handling of buffered stream output.» (осуществляют контроль над внутренней обработкой буфферизованного потокового вывода) :-) Во-первых, о буфферизации ввода ни слова :-) Во-вторых, то, что эти функции есть, ещё не говорит о том, что фактически реализована буфферизация :-)

Это все фигня. Если большинство посчитает что нужно, оно и будет.

Какое большинство? :-) Тут, кажется, разыскиваются днём с огнём «пользователи Common Lisp в России» :-) Лол :-) Так что теперь уже, может быть, и фигня :-)

А то что «нужно» и «ненужно» определяется мэйнтейнерами реализаций :-) Не мог бы ты предложить улучшить тот же SBCL? :-)

Если мейнтейнер будет сильно ссать против ветра, просто форкнут.

Если мейнтейнер будет сильно ссать против ветра, просто форкнут.

Верно! :-) Я за это и говорю :-) Сейчас 100500 реализаций, а будет 100501 реализация :-) Нет понимания ограниченности ресурсов, к моему большому сожалению :-)

Если мейнтейнер будет сильно ссать против ветра, просто форкнут.

Верно! :-) Я за это и говорю :-) Сейчас 100500 реализаций, а будет 100501 реализация :-) Нет понимания ограниченности ресурсов, к моему большому сожалению :-)

Тут, кажется, разыскиваются днём с огнём «пользователи Common Lisp в России»

пользователи Common Lisp в России

Остается только узнать зачем.

Нужно предложить интересный проект с интересной оплатой, тогда и подтянуться, и не только изэтойстраны.

На ЛОРе лисп дискредитировали быдловатые хамы вроде Луговского и Игнатьева

На сегодня эту функцию эффективно выполняет ТС.

Пользовал ли ты https://www.mitchr.me/SS/mjrcalc/ ?

Не пользовал, пощупаю, спасибо.

Остается только узнать зачем.

+1 :-)

Нужно предложить интересный проект с интересной оплатой, тогда и подтянуться, и не только изэтойстраны.

Вряд ли кто-то выступит инвестором :-) Надо создавать здоровое сообщество с общими интересами и общим бюджетом :-) И со своим форком :-) Деньги надо зарабатывать, а не клянчить :-)

Как Луговский мог что-то дискредитировать? Лавсан - это другая история, но повестись на его рассказы мог только совсем слабоумный.

P.S. Я интересуюсь лиспами, но на практике предпочитаю ML-подобные.

Логгер для IRC-чатика #lor написан на CL. Правда это не тянет на серьёзный проект.

Ты спросил про SBCL, я тебе ответил :-) Взгляни на код set-fd-stream-routines в fs-stream.lisp и узри

А в каких реализациях cl есть буферизация io-потоков? Только в коммерческих?

Логгер для IRC-чатика #lor написан на CL

Тобой?

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

Самописная разбиралка irc-сообщений, вебсервер на hunchentoot, чтобы выводить логи, postmodern для работы с БД и т.д.

почти все свалили на хаскель,

А что, в хаскель уже завезли компилятор в рантайме?

Давно? Реп-то можно посмотреть?

Вот: https://github.com/vladimir-g/zoglog. Вживую тут.

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

Кто-то тут писал про Lovesan-а, но он больше ничего не делает, смотрим активность на гитхабе и видим почти ничего.

Забухал, видимо, разочаровался.

компилятор в рантайме?

там у них, говорят, компилятор в рантайме нельзя, но за то можно факториал вычислить генератор суперкомпиляторов или супергенератор компиляторов, или мегасупер, накрайняк, с помощью моноида в пердофункторах замутить. Читай за фапе: TAPL, TAPOK, там все поясняется

Спасибо.

Нужно предложить интересный проект с интересной оплатой,

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

Если по ним судить, то я занимаюсь Racket'ом.

А разве не занимаешься?

В свеже стартанутом браузере, 2-3 секунды.

У него жестокий рандомный затык между dns-ом и открытием певого соединения. Если этот этап удается пройти все реактивно. Сейчас таким вот путем оно у меня чаще не работает, чем наоборот. Архимаг с год назад активно ругал свой условно бесплатный хостинг.

В QL лежит две workaround-а с поддержкой {sb|c}cl. Заявлено ускорение в нескольких и впплоть до десяти раз.

Подводим итоги: трое, если считать нас с Монком, из них один начинающий. По-честному скорее двое. Плюс трое на ЛОРе, вроде других. Плюс ystok. Итого 6.

Зачем я интересовался? Да так, есть один проектик, но лучше закроем эту тему, чтобы не было офтопика, а про проектик может быть в другой раз напишу.

В QL

QuickLisp, что ли?

Вот еще нашел https://github.com/rpav/fast-io

Блин, опечатался. 6 если _не_ считать нас с Монком.

А разве не занимаешься?

Занимаюсь. Но помимо Racket, активно занимаюсь Common Lisp'ом и менее активно Haskell'ом.

Я в том смысле, что swizard занимается и Rust'ом и Common Lisp'ом и Kavascript'ом.

CL - уже не модно, Rust наше все.

Таки

Раст - говно, Golang наше все!

I have a Common, I have a Lisp... Aaaa Common Lisp.

I have a Racket, I have a Haskell... Aaaa Racket Haskell.

Common Lisp, Racket Haskell... Aaaa Haskell Racket Common Lisp :-)

Теперь осталось все это под музычку и видос на ютубе выложить. Популярность этим трём будет обеспечена.

Теперь осталось все это под музычку и видос на ютубе выложить. Популярность этим трём будет обеспечена.

Кстати, чем не проект? :-) Осталось определиться кто будет в клипе сниматься :-) Fukamachi? :-)

Да - ваш КЭП.

У него усов нет.

В QL лежит две workaround-а с поддержкой {sb|c}cl. Заявлено ускорение в нескольких и впплоть до десяти раз.

название не подскажешь?

QuickLisp, что ли?

Да. fast-io и pounds

Кстати, я только что заметил фразу «в России». Я тогда ваще не ститаюсь...

Ну на самом деле у меня есть один проект, который мог бы быть кому-то интересен. Есть cl-javascript. Мы его с успехом применили для решения такой задачи, как генерация html из markdown. В принципе для этого есть cl-markdown, но он кривой и убогий. Главное - в нём нельзя делать таблицы. В showdown можно. Мы (лично Monk) пинками заставили связку cl-javascript + showdown работать. Баги ещё остались, но во всяком случае можно видеть вот это.

Исходник вот

По сравнению с cl-markdown это большой прогресс, а трудозатраты составили пару дней.

Проблема cl-javascript состоит в сложности отладки. Например, он не берёт на себя труд сохранять имена функций из Js и плюётся кучей анонимных лямбд. Увидеть исходники этих лямбд нельзя (или во всяком случае для этого требуются дополнительные действия).

Уже в ныне работающей версии Яра у нас есть пошаговый отладчик, опирающийся на пошаговый отладчик SBCL. Как это устроено, я коротко рассказал здесь.

Можно сделать то же самое для cl-javascript, а именно:

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

Общий смысл - более-менее технологично заимствовать библиотеки из js. Вот. Соответственно, если кому-то из квалифицированных лисперов это интересно сделать на добровольной или частично добровольной основе, то обращайтесь. Естественно, меня не интересует EMACS/SLIME, а интересует только моя среда.

Занимаюсь. Но помимо Racket, активно занимаюсь Common Lisp'ом и менее активно Haskell'ом.

Ну Haskell - ладно, но не в порядке холивара, просто любопытно: сложилось впечатление (особенно по теме «Анализ пользователей Common Lisp и Racket»), что Racket тебе более симпатичен. Это не так? Или у CL есть свои, полезные в другом случае, преимущества? Или?

в хаскель уже завезли компилятор в рантайме

Да. В ghci. В cabal активно используется (там фактически выполнение определения функции по окончанию ввода строки в фоне выполняется, по результатам даёт синтаксические ошибки и типы).

Racket тебе более симпатичен. Это не так?

Так.

Или у CL есть свои, полезные в другом случае, преимущества?

Есть. На CL гораздо легче разрабатывать прототипы. На CL проще abuse'ить библиотеки. На CL можно пользоваться отладчиком в production версии. И даже на ходу делать исправления.

Скажу честно, если бы в (реализации) CL был нормальный call/cc, я бы на Racket не ушёл. Но здесь срабатывает «парадокс блаба»: «call/cc — это странная штука, которая нормальным людям не нужна».

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

Скажу честно, если бы в (реализации) CL был нормальный call/cc, я бы на Racket не ушёл.

Мне казалось, что тебе о вкусу именно «ограничения» Racket или они не перевешивают возможность «делать исправления на ходу в релизе»?

Ну какой еще нахрен Common Lisp? Россия по всем рейтингам уже где-то на уровне африканских стран — СПИД, нищета и мракобесие. И это еще на резервах, через год и этого не будет.

Мне казалось, что тебе о вкусу именно «ограничения» Racket

Все эти ограничения при большой необходимости легко обходятся. Мне по вкусу рекомендуемый стиль программирования в Racket.

На момент перехода почти всё, что мне нравилось в Racket (модули, define вместо let, match) можно было сделать макросами и правкой readtable. Кроме call/cc.

они не перевешивают возможность «делать исправления на ходу в релизе»

Возможность «делать исправления на ходу» слишком расхолаживает при разработке. То есть, чтобы написать хорошую программу на CL требуется больше самодисциплины, чем чтобы написать хорошую программу на Racket. Но время до первой работающей версии на CL будет меньше.

На момент перехода почти всё, что мне нравилось в Racket (модули, define вместо let, match) можно было сделать макросами и правкой readtable.

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

Опять же, меньше проблем при взаимодействии с чужим кодом. Или это не аргумент?

Но время до первой работающей версии на CL будет меньше.

Наверное. И тебе по вкусу подход «набросать прототип на CL, затем переписать на Racket»? В смысле, он хорошо себя зарекомендовал?

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

На момент перехода было сильное желание «доработать напильником» отсутствие в Racket нормального отладчика, отсутствие как класс аналога inspect и отсутствие нормального автодополнения в DrRacket.

Философию: «если тебе понадобился отладчик, значит ты не понимаешь, как должна работать твоя программа» и «тесты нельзя писать в REPL» я смог принять только через пару месяцев.

В общем ощущения были как после перехода с mcedit на vim. Вроде всё удобней (будет когда-то), но требует обучения.

И тебе по вкусу подход «набросать прототип на CL, затем переписать на Racket»? В смысле, он хорошо себя зарекомендовал?

Только там, где алгоритм требует исследования. В остальных случаях напоминает «набросать прототип на Perl, затем переписать на Java». Базовые конструкции настолько же различны.