А как у common lisp дела с производительностью?

А если отбросить религию, батарейки будут примерно равны?

При наличии quicklisp-а CL применим на практике. Однако не хватает IDE заточенной именно под web.

Racket застряд на уровоне «клево, мы можем написать web-сервер».

А как иначе ты сможешь понять аргументацию?

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

Но тут дело даже не совсем в этом: сначала говорится, что мне нужно искать отличия с питоном, потом что должен разбираться, чтобы понять аргументацию. То есть первая часть: это своего рода обряд инициации, чтобы выяснить достоин ли я узреть ваши аргументы?

А толку от pypy, если он не может интерпретировать нужную мне программу?

Одна нужная программа на питоне? У меня некоторые заводились если что, как повезет.

пока оно зависимости разрулит можно успеть кофе сварить.

Знаете ли, меня не смущает и lua: curlpaste / quvi, и sh (тут полно), да и многие python-программы запускаются приемлимо. А если не ограничиваться динамическими - то пусть будет хоть haskell: pandoc.

Понятно, спасибо за адекватные ответы.

По-моему, вы увиливаете.

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

Одна нужная программа на питоне?

Да, по большому счёту.

Знаете ли, меня не смущает и lua: curlpaste / quvi, и sh (тут полно), да и многие python-программы запускаются приемлимо. А если не ограничиваться динамическими - то пусть будет хоть haskell: pandoc.

Я к тому, что если хелловорд запускается быстро/занимает мало места, то это ещё ничего, совсем ничего не значит.

Однако не хватает IDE заточенной именно под web.

Хм, а что там должно быть?

А как показать отсутствие различий я ответить затрудняюсь.

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

Я к тому, что если хелловорд запускается быстро/занимает мало

места, то это ещё ничего, совсем ничего не значит.

Не сразу понятно было. Не знаю ведь насколько хорошо написан этот ваш emerge.

В libquvi-scripts всего на 200kb скриптов (нужны по-одиночке, конечно) - не совсем helloworld. Pandoc - тоже ни разу. Ну и смотря где проводится граница: может мне и smem - нормальная утилита.

Интереснее какими консольными lisp утилитами сами пользуетесь? (я честно пробовал paktahn).

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

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

основы лиспа ...

Не, ну об основах-то предствавление какое-то есть: первые главые pcl (емнип, реализации пролога включительно). Немного схему, elisp тот же.

Но «разбираться» не скажу, динамичность (unwind-protect и сотоварищи), исключения - вне охвата.

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

Слишком много буков понадобится. А у меня к концу недели они закончились.

какими консольными lisp утилитами сами пользуетесь?

Только самописным sip-парсером. Но он запускается раз в час по крону и работает минут 10-12, смотря сколько сообщений нужно обработать. Сколько из этого занимает собственно старт программы до начала обработки данных не мерял, но очевидно оно ничтожно, относительно основного времени работы. Это если речь о CL.

Если говорить, например, о scsh, то на типично шелловских задачах на глаз разницы в скорости запуска относительно bash не заметно.

Слишком много буков понадобится.

Просто странно: вот я честно не вижу чем python более близок к лиспу, чем ruby. Про последний говорится «тормоз», а про первый «недолисп». Такая «защита» лиспа скорее отпугивает (если не было такой цели: поддалкивание оппонента и приобритение псих-го талоничка, что лиспофобы неадекватны).

Но он запускается раз в час по крону и работает минут 10-12

Ну это уже демон. Интересовал startup-cost. Вот говорили про ecl, тогда интересно почему часто препочитают sbcl для консольных утилит.

Если говорить, например, о scsh

Ну это уже скрипты.. И про bash все же верится с трудом, а ведь есть еще dash, если речь идет про небольшие скрипты.

BTW x32? Вот пробовал scsh/guile но там кое-чего не хватало. Хуже: подгрузишь прилично модулей scsh + srfi - у уже небыстро, несмотря на guile-кеш

вот я честно не вижу чем python более близок к лиспу, чем ruby.

Руби мне не очень интересен, бо ничего полезного на нём для меня нет + знаю его слишком шапочно.

Про последний говорится «тормоз»

Если смотреть на шутаут, то руби сливает sbcl до трёхсот раз. Если это не тормоз, тогда я вообще не знаю что такое тормоз.

Такая «защита» лиспа скорее отпугивает

А вы коньячку накатите или вискарика. Снижает чувство страха.

Ну это уже демон.

Чем богат.

И про bash все же верится с трудом, а ведь есть еще dash, если речь идет про небольшие скрипты.

                                                                                  
~/project/bin $ cat echo.scsh
#!/usr/bin/scsh -s
  
!#

(map (lambda (x) (begin (display x) (display " "))) command-line-arguments)

(display "\n")



~/project/bin $ cat echo2.sh
#!/bin/sh

echo $@

~/project/bin $ time ./echo.scsh aaa bbbb ccd
aaa bbbb ccd
0.018 secs                                                                                                                                                                         
~/project/bin $ time ./echo2.sh aaa bbbb ccd
aaa bbbb ccd
0.009
secs                                                                                                                                                                         
~/project/bin $ uname -a
Linux nejdanchik 3.7.10-gentoo #9 SMP Tue Jun 11 21:17:23 MSK 2013 x86_64 Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz GenuineIntel GNU/Linux

9 тысячных секунд разницы. Это значимо?

BTW x32?

Да. Либо lib32 для x86_64. Поэтому сейчас я в поисках адекватного ЯП для скриптинга.

Если смотреть на шутаут, то руби сливает sbcl до трёхсот раз.

Ага, крайний случай, просто зеркальный вариант v8/sbcl кода wota.

Снижает чувство страха.

Вас отпугивает только страх?)

9 тысячных секунд разницы. Это значимо?

Не значимо, но у меня 0.2s, поэтому и было уточнено про x32. Ну и все-таки для объективности лучше несколько модулей подключить, или в родном scsh это сразу?

Потому что у его будет одна libecl.so на 20 консольных запускалок.

А толку? Байт-код у них-то разный и не шарится. Сама libecl.so маленькая и погоды не делает. ИМХО, для мелкой фигни лучше брать CLISP.

Если же компилировать, то ECL и тут сливает на скорости компиляции (не говоря уже о скорости кода).

зуб даешь? :)

Я подтверждаю :) Помню, видел события и участвовал в обсуждении на ЛОРе — но явно не swizard.

А как у common lisp дела с производительностью?

На уровне ruby, python - иногда значительно выше. Этого достаточно.

Это ж как надо ухитриться?

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

Для своих консольных утилит. Раз свои значит по ходу доделываются, а в смысле разработки sbcl удобнее. А стартует он вполне себе быстро.

вот я честно не вижу чем python более близок к лиспу

Так еще с Норвиг-а повелось :)

Это ж как надо ухитриться?

Сталина на ни^Uв смысле помню флейм, где в углу были специализированные схемы.

вот http://plasmon.rghost.ru/46926439/image.png , потом убрали, ибо подвержено неправильно интерпретации

Для своих консольных утилит

Вот я всем с paktahn-ом надоел: там sbcl.

А стартует он вполне себе быстро.

Хорошо, договоримся: утилита для себя. sbcl удобнее, как точда вижу: либо --script (с долгим холодным стартом, но могу ошибаться: малая выборка; а если что-то обновилось - он же полезет компилировать), либо жирный бинарь (и мало ли как он с моих не самых быстрых винтов подгрузится, да и места иногда жалко), есть еще gzexe - но время на распаковку еще больше может съесть. Из tmpfs - да, очень неплохо.

Так еще с Норвиг-а повелось :)

Подразумевается, в частности, табличка со сравнением? Очень познавательная (правда с небольшим «субъективом» в пользу лиспа) была.

https://observatorio.iti.upv.es/resources/new/4540

The bottom left three languages, Cmucl, Regina and Stalin are outliers. These languages do not have enough benchmark implementations in the database to generate fully fleshed stars.

Но наблюдая за «приключениями» monk-а с макросистемой ракеты ни как не могу ощутить энтузиазм в её освоении.

Зря. В своё время такие же «приключения» были при попытке перейти с C++ ООП на CLOS. Archimag до сих пор пишет на CL CLOS как на C++ с очень можными макросами и REPLом.

Кстати вопрос: у Норвига есть пример компилятора из схемы в CL: http://norvig.com/paip/compile1.lisp и прочие compile*.lisp на http://norvig.com/paip/. Не знаешь, существует ли доделаный вариант такого компилятора (хотя бы с доделанной гигиеной)?

Очень хочется писать на scheme и cl в пределах одного образа. Да и оптимизатор у SBCL неплохой, может получится достаточно быстрая реализация схемы.

readline для sbcl

Используй clisp — у него readline встроенный.

существует ли доделаный вариант такого компилятора (хотя бы с доделанной гигиеной)?

Помоему только для R4

Помоему только для R4

Ссылка есть? Google даёт только учебный пример Норвига. А от него до более-менее рабочего писать сильно много.

http://mumble.net/~jar/pseudoscheme/

Archimag до сих пор пишет на CL CLOS как на C++ с очень
можными макросами и REPLом.

Чего?

Вот я всем с paktahn-ом надоел: там sbcl.

Вот надо смотреть в его код и выяснять что не так.

либо --script (с долгим холодным стартом, но могу ошибаться:

Секунда на старт самого (Не новый Athlon XP 1800) , остальное зависит от кода. Есть смысл

 (setf sb-ext:*evalutor-mode* :interpret)

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

Он не весь грузится так что размер особо не влияет

Подразумевается, в частности, табличка со сравнением?

Нет скорее общий тон выступления.

Это ж как надо ухитриться?

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

Возьмём задачу «Сделать интерфейс для работы с контенерами объектов».

Варианты решения (все написаны на CL):

В стиле C++ : http://common-lisp.net/project/cl-containers/

В стиле Common Lisp: http://common-lisp.net/project/iterate/

В стиле Scheme/Haskell: https://github.com/fare/lisp-interface-library

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

в r4 вроде нету гигиены?

Возьмём задачу «Сделать интерфейс для работы с контенерами
объектов».

Поржал. Ты же не понимаешь, о чём пишешь.

В стиле C++ : http://common-lisp.net/project/cl-containers/

В каком месте это стиль С++? Стиль С++ это STL, которая к ООП, вообще говоря, имеет весьма отдалённое отношение. При этом, что автор STL долго пытался реализовать её на Scheme и не смог. cl-containers это просто не очень удачная в плане интерфейса библиотека, которой никто не пользуется.

В стиле Common Lisp: http://common-lisp.net/project/iterate/

Как ты предлагаешь сравнивать её с предыдущей библиотекой, ведь они решают принципиально разные задачи? iterate это инструмент для построения циклов произвольной сложности и только это.

При этом, что не раз подчёркивалось, iterate единственная широко известная библиотека, в которой использование сложного code walker-а действительно себя оправдывает. Я никогда не использую loop, а только iterate.

Если бы у меня было время и большое желание, то я бы шел в сторону добавления итераторов в стиле Python и интеграции их с iterate, благо iterate имеет расширяемую архитектуру.

Кроме того, ты как-то в треде про преимущества лиспа
сильно возражал против макросов

Я говорю, что макросы это всего лишь один из инструментов декомпозиции, которые имеет плюсы, но имеют и существенные минусы. И на практике в большинстве случаев минусов больше, чем плюсов. Разработка сложного code walker-а наподобие iterate себя оправдывает очень редко.

Он не весь грузится так что размер особо не влияет

И правда! Интересно как это?

mmap. Так же как и so-шки.

Используй clisp — у него readline встроенный.

У меня и так дофига лишнего установлено, sbcl хотя бы требуется для maxima.

Секунда на старт самого (Не новый Athlon XP 1800)

Ну вот, есть говорить о «консольных утилитках» - может стать ограничением.

Да Заранее скомпилировать fasl тоже можно.

Хм, почему-то тогда только --load работает, не обвешивать же костылями --noinform и --eval '(quit)'

Он не весь грузится так что размер особо не влияет

Похоже на то. А вообще теоретически возможна динамическая линковка? хотя не вижу с чем: в пакете всего три бинарных файла.

Хм, почему-то тогда только --load работает, не обвешивать же костылями --noinform и --eval '(quit)'

Не понял мысли.

А вообще теоретически возможна динамическая линковка? хотя не вижу с чем: в пакете всего три бинарных файла.

Теоритически, стать разработчиком. Штатно можно объединять общие страницы памяти. Для ECL можно и линковать.

Ну вот, есть говорить о «консольных утилитках» - может стать ограничением.

В общем случае не должно, а частные рассматривать по отдельности.

[user - ~]$ time -f '%e сек.' sbcl --noinform --no-userinit --non-interactive --eval "(write-line \«5\»)"
5
0.02 сек.

Разработка сложного code walker-а наподобие iterate себя оправдывает очень редко.

С нормальной макросистемой сложные кодеволкеры не нужны.

С нормальной макросистемой сложные кодеволкеры не нужны.

Может быть, но в CL ведь не такая?

Не понял мысли.

Просто не могу найти как правильно запустить *.fasl в качестве отдельной программы.

0.02 сек.

Ну ведь это ни разу не холодный: у того же guile раза 4 больше, но тоже очень быстро, зато холодный в 4 раза меньше.

Позволю себе нескромный вопрос: какими консольными утилитами на лиспе вы пользуетесь?)

не такая.

Позволю себе нескромный вопрос: какими консольными утилитами на лиспе вы пользуетесь?)

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

Ну ведь это ни разу не холодный:

Специально проверил холодный после перезагрузки 1.35. Второй и последующие запуски 0.01

Просто не могу найти как правильно запустить *.fasl в качестве отдельной программы.

(load ...) в репле и дальше как обычно.

Позволю себе нескромный вопрос: какими консольными утилитами на лиспе вы пользуетесь?

Никакими. Репл всегда запущен. А для интеграции с unix-way, есть inferior-shell и clesh.

Друзья, мне почему то не удалось найти в Сети крякнутых версий LispWorks? Почему?

Ха, здоровская утилита!

Друзья, мне почему то не удалось найти в Сети крякнутых версий LispWorks? Почему?

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

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

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

Но твой метод лучше, да. Менее разрушителен для психики.

Я можетн немного не в тему, но может кто-то тут уже практиковал Kernel? http://web.cs.wpi.edu/~jshutt/kernel.html

Сейчас часто о нём слышу.

А у него уже есть работающая реализация?