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

Мне эту картинку с результатом сразу нарисует в notebook, можно ее покрутить и сходу сохранить в любом удобном формате.

А ведь все это уже когда-то уже было в форме presentations в OpenGenera.

CL - это язык *моего* предпочтения, который позволяет мне быстренько заставлять компьютер делать то, что мне надо.

Если задача сформулирована именно так, то CL правильный выбор. А вот когда задача ставится «Позволить глупым пользователям моей программы делать то, что мне надо», то всё не так однозначно.

Все НИР с использованием выч.техники, которые я видел, так и делаются :-)

Явно не на стадии прототипирования

то Matlab/Mathematica, а если ситуация «нужно смоделировать приводнение капсулы на 2 км/секунду», или «вот набор фотографий, построй 3Д объект из них», то стандартные алгоритмы если и нужны, то с исходниками.

И это будет явно не лисп, потому что на лиспе вместо исходников биндинги к сишным либам :)

А ведь все это уже когда-то уже было в форме presentations в OpenGenera.

Ну а что такого-то? Это по факту обычный репл, просто с возможностью вывода элементов интерфейса и картинок (что, впрочем, и тот же Dr.Racket умеет).

И дебагер никто не будет переделывать

Кроме разработчиков Racket есть ещё разработчики geiser. И они вполне могут запилить, чтобы было «не хуже, чем SLIME».

Возможности в платформе для написания произвольного дебаггера есть. Кстати, этим тоже Racket лучше, чем CL. В большинстве реализаций CL не всё, что доступно в дебагере, доступно из кода. То есть, если я в SBCL поймал сигнал (через handler-bind), то я не могу программно посмотреть обратную трассировку, позицию ошибки в файле и т.д. В Racket вся поддержка дебаггера на уровне платформы сводится к меткам продолжений и исключениям, а уж какой дебаггер строить на их основании — дело разработчика IDE. В стандартном DrRacket не хватает лишь кнопки «запустить REPL» и удобного представления данных.

И это будет явно не лисп, потому что на лиспе вместо исходников биндинги к сишным либам

Да ладно. Видел и на фортране программы и на паскале. Вообще NIH синдром в науке достаточно сильный. Проще написать свою реализацию алгоритма Гаусса, чем найти нужную библиотеку, преобразовать из своего формата в тот, который её нужен и т.д.

Например, в программе распознавания изображений и построения трёхмерного из типовых библиотек только чтение jpeg использовалось. Всё остальное — (почти) классические алгоритмы, но в собственной реализации.

А matlab/mathematika только для прототипов. Потому как ходят всякие слухи/страшилки: http://www.itmo.ru/forum/thread.php?threadid=9020

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

В CLOS нет маразма с private/public. А пакеты и условные вычисления прекрасно сочетаются с разработкой в образе, в отличие от Рэкетных модулей, созданных для раздельной компиляции независимых компонентов. Сама концепция модулей из этого сложнее, потому что к ним предъявляются претензии со стороны компилятора во избежание каких-то противоречий. (Я не знаток Рэкета, но предполагаю, что это так.)

Продолжения - вообще тривиальная вещь.

Пусть тривиальная, спич о том, что Рэкет «навороченней». Тут «тривиальная» вещь, там «тривиальная» вещь, тут «красота», там «красота» - в совокупности и даёт те самые «навороты», которые делают из Рэкета своеобразный Си++.

Вообще NIH синдром в науке достаточно сильный. Проще написать свою реализацию алгоритма Гаусса, чем найти нужную библиотеку,

Проще и быстрее. Потому что когда в Интернете 100500 реализаций, то сделать выбор в пользу «хорошей» либы сложно и долго. Поэтому проще и быстрее написать свою, чем тратить время на выбор. Благо, CL способствует быстрому написанию. Относительно быстрому :-)

Вообщем с LispWorks 64 bit, после добавления больше деклараций и при (optimize (float 0)), получилось так:

CL-USER> (time (sys:with-other-threads-disabled
                 (main 1000)))
Timing the evaluation of (SYSTEM:WITH-OTHER-THREADS-DISABLED (MAIN 1000))
1.274224148

User time    =        1.772
System time  =        0.004
Elapsed time =        1.750
Allocation   = 1920643880 bytes
0 Page faults
NIL
CL-USER> (time (sys:with-other-threads-disabled
                 (main 1500)))
Timing the evaluation of (SYSTEM:WITH-OTHER-THREADS-DISABLED (MAIN 1500))
1.274224151

User time    =        3.948
System time  =        0.004
Elapsed time =        3.889
Allocation   = 4320963928 bytes
0 Page faults
NIL

плз, код и сравнение с sbcl на твоём компе

Кроме разработчиков Racket есть ещё разработчики geiser.

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

Вообще NIH синдром в науке достаточно сильный. Проще написать свою реализацию алгоритма Гаусса, чем найти нужную библиотеку, преобразовать из своего формата в тот, который её нужен и т.д.

Вот по-этому я и говорил, что очень хорошо, когда обширный набор алгоритмов с возможностями работы с данными в разных видах и форматах сразу под рукой :)

А matlab/mathematika только для прототипов.

Так можно понагенерить код всегда и потом этот же прототип использовать для реализации в той же сишке.

Потому как ходят всякие слухи/страшилки: http://www.itmo.ru/forum/thread.php?threadid=9020

Ну баги везде есть.

В CLOS нет маразма с private/public.

В СLOS много другого маразма.

Сама концепция модулей из этого сложнее

Она проще, потому что нету ебнутого eval-when.

Пусть тривиальная, спич о том, что Рэкет «навороченней».

Пока что мы выяснили что на каждый «наворот» ракетки найдется «наворот» в общелиспе.

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

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

Вообщем с LispWorks 64 bit, после добавления больше деклараций и при (optimize (float 0)), получилось так:

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

на каждый «наворот» ракетки найдется «наворот» в общелиспе

Именно концепций в ракетке больше. Потому сравнение Си/Си++ (или Си/Java) вполне правомерное.

То есть в Си есть километровые дефайны, в Си++ — темплейты, в Си указатель одного вида и с ним можно делать что угодно, в Си++ умные указатели с полудюжиной разных семантик и т.д.

Так и здесь. То что есть в Racket и нет в CL: ephemeron, will-executor, continuation, continuation-mark, syntax, structure inspector, code inspector, syntax-arm, custodian, thread (security-guard, channel, thread group), contracts (chaperone, impersonator), units.

Идеи в CL, которых нет в Racket: CLOS, restarts, eval-when

Именно концепций в ракетке больше.

Здесь важно, насколько необходимы эти концепции для использования языка. Например, писать на CL и не использовать CLOS или рестарты - было бы очень странным. В то время как те же continuation marks, syntax arms или инспекторы тебе понадобятся только в весьма специфичных случаях. Выделять в отдельные «идеи» ephemeron с will-executor'ами вообще глупо. По факту реально остаются контракты, юниты, треды (кустодианы и все связанные концепты сюда же).

Здесь важно, насколько необходимы эти концепции для использования языка.

Опять цитируешь апологетов Си++. Мол, можно писать на Си++ как на Си, а ненужное просто не использую. При использовании языка приходится не столько писать, сколько читать код, написанный другими людьми. И для этого надо понимать весь язык.

Например, писать на CL и не использовать CLOS или рестарты - было бы очень странным.

Да ладно. Есть куча код на CL без CLOS и рестартов: alexandria, http://www.cs.berkeley.edu/~russell/code/doc/overview.html ...

Вопрос вкуса.

В то время как те же continuation marks, syntax arms или инспекторы тебе понадобятся только в весьма специфичных случаях.

Их приходится читать. Например, в исходниках DrRacket. syntax-arm, так вообще массово. Можно, конечно, их воспринимать как begin и не париться, но так можно и в CL-ном коде на eval-when не смотреть :-)

Выделять в отдельные «идеи» ephemeron с will-executor'ами вообще глупо.

Почему? Они не выражаются через другие объекты. Их нет в CL. Их невозможно реализовать в ANSI CL.

Так и здесь. То что есть в Racket и нет в CL: ephemeron, will-executor, continuation, continuation-mark, syntax, structure inspector, code inspector, syntax-arm, custodian, thread (security-guard, channel, thread group), contracts (chaperone, impersonator), units.

Вот, отлично сказал. Я было начал писать про кастодианы и зелёные трэды (а так же про то, что в Рэкете отделили понятия конкурентности и параллелизма), и про контракты, но подумал, что список не будет достаточно длинным и убедительным (поскольку я не знаком с Рэкетом настолько, чтобы знать все его специфические концепции). Но даже этого моего списка для *меня* достаточно, чтобы усмотреть нагромождение концепций. И, как следствие, опять же, как и в случае с Си++, нужно постоянно преодолевать большее число внутренних противоречий в поисках наиболее «правильного» пути реализации той или иной идеи. Т.е. всеми этими «наворотами» нужно уметь «правильно» пользоваться. По мне так это просто пожиратель времени, ибо инструмент не должен быть настолько сложным, чтобы я тратил время на принятие решения как именно мне с его помощью добиться задуманного результата. :-)

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

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

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

Инструмент должен быть достаточно мощным, чтобы задуманного результата можно было вообще добиться. Racket изучать приходится дольше, чем CL, но многие задачи, решаемые на Racket, на CL вообще не решаются.

Например, писать на CL и не использовать CLOS
было бы очень странным.

Абсолютно ничего странного. В том же «On Lisp» 24 главы из 25 без ООП. :-)

Опять цитируешь апологетов Си++. Мол, можно писать на Си++ как на Си, а ненужное просто не использую. При использовании языка приходится не столько писать, сколько читать код, написанный другими людьми.

И много кода вот здесь, например:

http://pkgs.racket-lang.org/

с инспекторами, армами и continuation marks?

Да ладно. Есть куча код на CL без CLOS и рестартов

В CL если понимаешь как работает механизм обработки ошибок = знаешь рестарты, по факту. Точно так же как в ракетке это предполагает знание продолжений.

Их приходится читать. Например, в исходниках DrRacket. syntax-arm, так вообще массово. Можно, конечно, их воспринимать как begin и не париться, но так можно и в CL-ном коде на eval-when не смотреть :-)

Ну да, потому что Dr.Racket с кодом работает. Если ты не пишешь свой Dr.Racket, который будет сам раскрывать кусками код или дебагер или еще что-то подобное - оно тебе будет совершенно не нужно. Например, если говорить о тех же syntax arms - я знаю, что это такое, знаю как они работают и для чего нужны, но за все время ни разу с осязаемых эффектом от них не встречался (и не встречусь). Фактически - это кишки реализации, а единственный способ увидеть кишки - это в них копаться.

Если начать копаться в кишках любого %lang_name%, то повылезет куча всяких неочевидных вещей.

Почему? Они не выражаются через другие объекты. Их нет в CL. Их невозможно реализовать в ANSI CL.

https://common-lisp.net/project/trivial-garbage/

а тут как?

слабый хеш с :weakness-matters :key и будет ephemeron.

Но даже этого моего списка для *меня* достаточно, чтобы усмотреть нагромождение концепций.

То есть контрактов и зеленых тредов?

И, как следствие, опять же, как и в случае с Си++, нужно постоянно преодолевать большее число внутренних противоречий в поисках наиболее «правильного» пути реализации той или иной идеи.

Примеры можно?

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

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

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

В чем конкретные сложности-то?

Можно, конечно, их воспринимать как begin и не париться, но так можно и в CL-ном коде на eval-when не смотреть :-)

Кстати нет, если ты не знаешь о dye packs и воспринимаешь армы как begin, то ничего не потеряешь, а вот без знания работы eval-when можно неверно прочитать control-flow :)

без знания работы eval-when можно неверно прочитать control-flow

С учётом того, что встречается только евал-всегда, то неверно прочитать сложно. Я первые три года программирования на CL считал, что eval-when — это такой progn, в который надо заворачивать функции, которые используются в макросах. Как begin-for-syntax. И мне это не мешало читать и писать код.

https://common-lisp.net/project/trivial-garbage/

На ANSI CL это не работает. Работает только на явно указанных реализациях. Поэтому «Их нет в CL. Их невозможно реализовать в ANSI CL.»

С учётом того, что встречается только евал-всегда, то неверно прочитать сложно.

Важно скорее, когда евал-всегда не встречается ;)

На ANSI CL это не работает. Работает только на явно указанных реализациях. Поэтому «Их нет в CL. Их невозможно реализовать в ANSI CL.»

То есть то что, значит, в стандарте языка нету чего-либо эквивалентного слабым ссылкам - это норм, а когда оно есть - это bloated?

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

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

Эти кишки есть в документации. Про continuation marks приходится вспоминать каждый раз, когда создаёшь новый идентификатор через datum->syntax.

syntax-arm — когда пытаешься понять, почему не экспандятся макросы из ffi.

но уж такие-то вещи записывать в «язык переусложнен» как-то странно

Чтобы научиться пользоваться контрактами теми же, надо потратить полчаса-час на чтение документации, не больше. Потому что все элементарно.

Всё это увеличивает время изучения языка.

В Racket именно поэтому есть «языки для HtDP».

А аргумент «против» только один: «зачем учить сложный язык, если _мои_ задачи решаются на более простом». А уж контекст аргумента я видел разный: CL против Racket, Си против Си++, VB против MSVC и Delphi, PHP против Java, 1С против C#.

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

Я имел в виду немножко другое. В CL слабые ссылки и финализаторы — вещи в себе. Частные случаи решения практической задачи. В Racket эфемероны и «исполнители воли» — некие новые сущности, которые надо понять. Собственно, есть аналог слабой ссылки — weak-box и аналог финализатора: register-finalizer из ffi/unsafe. Если бы ими всё ограничивалось, то я бы их и не упоминал.

И эфемероны и исполнители воли дают возможности, которых в CL нет вообще.

Эти кишки есть в документации.

То, что кишки задокументированы - это плохо чтоли?:)

Про continuation marks приходится вспоминать каждый раз, когда создаёшь новый идентификатор через datum->syntax.

По-моему, ты перепутал с чем-то.

syntax-arm — когда пытаешься понять, почему не экспандятся макросы из ffi.

А чего там в ffi с ними?

True. eval-always. И всё в порядке.

Так чего? Неужели LispWorks слил SBCL? Я так и знал...

То, что кишки задокументированы - это плохо чтоли

Если это «кишки», то плохо, что они не отделены. Вот в SBCL есть документация по define-vop и прочему ассемблеру, но она лежит отдельно.

... continuation marks ... новый идентификатор через datum->syntax.

По-моему, ты перепутал с чем-то.

Я имею в виду syntax-local-introduce, syntax-local-bind-syntaxes, syntax/loc, и параметры datum->syntax. Почему для stx = (f id) обязательно надо в syntax/loc передавать #'id, а не stx и т.д.

А чего там в ffi с ними

Я сейчас не помню точно. Помню, что из-за protect-out + syntax-arm а ffi/unsafe чего-то сделать не мог (не полезного, а связанного с expand). Тогда и выяснил, что, мол, «так надо».

Я имею в виду syntax-local-introduce, syntax-local-bind-syntaxes, syntax/loc, и параметры datum->syntax.

А, ясно, ты syntax marks с continuation marks перепутал :)

Ну опять же до тех пор пока ты не захочешь обходить гигиену (что в общем редко надо), или не захочешь настраивать репорт ошибок (что в CL вообще нельзя) то проблем никаких нет. А тот же syntax-rules автоматически делает и syntax-protect и relocate.

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

Как я уже говорил, не являюсь экспертом по Racket, но коли я ставлю его в соответствие с Си++ относительно CL, который ставлю в соответствие с Си, то по опыту использования Си++ приведу такой простой пример. Вот в Си++03 есть ссылки (lvalue), которые отсутствуют в Си. В Си++11 добавили rvalue (которые, будучи именованными, являются, бугага, lvalue, но это уже отдельная песня). Так вот, если при разработке API в Си я всегда однозначно знаю, что аргументы вызываемых функций, которые работают с объектами вызывающих функций всегда передаются по указателю. В Си++ я должен задуматься: использовать ли мне ссылку или же указатель. Был бы я один на планете, то придерживался бы стиля «если вместо указателя может быть передан nullptr, то аргумент должен быть указателем». Даже если значения, передаваемые в функцию имеют семантику указателя, ибо в этом случае мне не пришлось бы явно проверять аргумент на nullptr. Это (в теории) явно документирует сигнатуру функции, и программист видит, что функция в качестве аргумента обязана принять ненулевой объект (ссылка же). Однако же на практике цепепе в лёгкую позволяет передать по ссылке нулевой указатель. Тогда вопрос: зачем нужны ссылки в цепепе? Вот чем ф-я f(const string& s) хуже f(const string* s)? И почему я должен задавать себе и людям этот дурацкий вопрос? А всему виной «наворот» Си++. (Конечно знатоки сейчас будут мне втирать, что ссылки нужны для использования в шаблонах и обобщённых функциях. Это всё понятно.) Кстати, о шаблонах. Вот другой пример. Есть в Си++ парадигма ООП. А есть в Си++ парадигма обобщённого программирования. И вот, допустим, мне нужно создать контейнер. Я начинаю мучить голову вопросами: «сделать мне абстрактный класс обобщённого итератора, или же сделать один общий абстрактный базовый класс Container, или же окунуться в королевство кривых шаблонов цепепе». Или же в том же ООП от Си++: можно применить pimpl и сделать класс handler для API, а класс реализации (который impl) абстрактным, а можно создать иерархию абстрактный классов для API, и, параллельно ей, иерархию классов реализации. И это только вершина айсберга. Т.е. возможностей решить одну и ту же задачу масса потому что язык огромный и мультипарадигменный. За это его, кстати, и любят, и ненавидят :-)

Как я уже говорил, не являюсь экспертом по Racket

А чего ты тогда рассуждаешь, если нихрена не знаешь, лол?

Т.е. возможностей решить одну и ту же задачу масса

В общелиспе тоже.

Вот другой пример. Есть в Си++ парадигма ООП. А есть в Си++ парадигма обобщённого программирования.

Ну это вообще пиздец, ты даже не понимаешь разницы между subtyping-полиморфизмом и параметрическим.

А, ясно, ты syntax marks с continuation marks перепутал

Не перепутал. Если не так делаешь, то всё работает, но в трассировке фигню показывает. А трассировка в continuation marks.

или не захочешь настраивать репорт ошибок (что в CL вообще нельзя) то проблем никаких нет... А тот же syntax-rules автоматически делает и syntax-protect и relocate.

Ну так иногда надо репорт ошибок. Вот то, с чем боролся, на syntax-rules не хватает: https://github.com/Kalimehtar/binary-class/blob/master/binary-class/syntax.rkt

Пришлось делать

....
(syntax/loc #'FTYPE 
  (call-with-values ;; add frame to prevent TCO
    (λ () (read-value 
      (values->maybe-list FTYPE) in ARG ...))
    values))
....

....
(syntax/loc #'FTYPE 
  (read-value 
     (values->maybe-list FTYPE) in ARG ...)))
....

возможностей решить одну и ту же задачу масса

В общелиспе тоже.

В общелиспе чаще, чем в Racket. Выбор между defun/defgeneric и defstruct/defclass как правило почти произволен. По крайней мере пару раз видел безумный код в стиле

(defmethod nodep ((x node))
  t)

(defmethod nodep (x)
  nil)

У тебя какой lw? Hobbist, enterprise?
А personal к эмаксу зацепится?

Ну так иногда надо репорт ошибок.

Ну надо конечно. Смысл в том что в CL этого-то в принципе нет.

именно для сохранения continuation marks

Ну так проблема с отладкой и ТСО во всех языках с ТСО. Тут в общем дело не в марках.

В общелиспе чаще, чем в Racket.

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

Только в общелиспе считается нормальным, что каждый дрочит как он хочет

Так я это и сказал. Если строго подходить к вопросу «возможностей решить задачу», так везде примерно одинаково. «Настоящий программист может написать программу на FORTRANе на любом языке» (с).

Почти оригинальный код, с несколькими добавочными декларациями (смотрел на вывод ассемблера).

(declaim (optimize (speed 3) (safety 0) (space 0)
                   #+lispworks (float 0)))

(defmacro eval-A (i j)
  `(let* ((n (+ ,i ,j))
          (n+1 (1+ n)))
     (declare (type (integer 0 22000) n n+1))
     (the double-float
          (/ (float (the fixnum (+ (ash (the fixnum (* n n+1)) -1)
                                   (the fixnum (+ ,i 1)))) 0d0)))))

(defun eval-At-times-u (u n Au start end)
  (declare (type fixnum n start end)
           (type (simple-array double-float) u Au))
  (loop for i of-type fixnum from start below end do
    (setf (aref Au i)
          (loop for j of-type fixnum below n
                summing (* (aref u j) (eval-A j i))
                  of-type double-float))))

(defun eval-A-times-u (u n Au start end)
  (declare (type fixnum n start end)
           (type (simple-array double-float) u Au))
  (loop for i of-type fixnum from start below end do
    (setf (aref Au i)
          (loop for j of-type fixnum below n
                summing (* (aref u j) (eval-A i j))
                  of-type double-float))))

(defun execute-parallel (start end function)
  (funcall function start end))

(defun eval-AtA-times-u (u AtAu v n start end)
  (execute-parallel start end
    (lambda (start end)
      (eval-A-times-u u n v start end)))
  (execute-parallel start end
    (lambda (start end)
      (eval-At-times-u v n AtAu start end))))

(defun main (n-supplied)
  (let ((n n-supplied))
    (declare (type fixnum n))
    (or (typep (* (- (* 2 n) 1) (- (* 2 n) 2)) 'fixnum)
        (error "The supplied value of 'n' breaks the optimizations in EVAL-A"))
    (let ((u (make-array n :element-type 'double-float :initial-element 1.0d0))
          (v (make-array n :element-type 'double-float))
          (tmp (make-array n :element-type 'double-float)))
      (declare (dynamic-extent u v tmp)
               (type (simple-array double-float) u v))
      (dotimes (i 10)
        (eval-AtA-times-u u v tmp n 0 n)
        (eval-AtA-times-u v u tmp n 0 n))
      (let ((vBv 0.0d0)
            (vv 0.0d0))
        (declare (type double-float vBv vv))
        (dotimes (i n)
          (declare (type fixnum i))
          (incf vBv (* (aref u i) (aref v i)))
          (incf vv (* (aref v i) (aref v i))))
        (format t "~11,9F~%" (sqrt (the (double-float 0d0) (/ vBv vv))))))))

CL-USER> (lisp-implementation-type)
"LispWorks"
CL-USER> (lisp-implementation-version)
"7.0.0"
CL-USER> (time
          (sys:with-other-threads-disabled
            (main 1000)))
Timing the evaluation of (SYSTEM:WITH-OTHER-THREADS-DISABLED (MAIN 1000))
1.274224148

User time    =        1.728
System time  =        0.012
Elapsed time =        1.713
Allocation   = 1920667904 bytes
0 Page faults
NIL
CL-USER> (time
          (sys:with-other-threads-disabled
            (main 1500)))
Timing the evaluation of (SYSTEM:WITH-OTHER-THREADS-DISABLED (MAIN 1500))
1.274224151

User time    =        3.864
System time  =        0.028
Elapsed time =        3.824
Allocation   = 4320999952 bytes
0 Page faults
NIL

CL-USER> (lisp-implementation-type)
"SBCL"
CL-USER> (lisp-implementation-version)
"1.2.14"
CL-USER> (time (main 1000))
1.274224148
Evaluation took:
  0.350 seconds of real time
  0.352000 seconds of total run time (0.352000 user, 0.000000 system)
  100.57% CPU
  873,249,712 processor cycles
  0 bytes consed  
NIL
CL-USER> (time (main 1500))
1.274224151
Evaluation took:
  0.680 seconds of real time
  0.680000 seconds of total run time (0.680000 user, 0.000000 system)
  100.00% CPU
  1,695,322,248 processor cycles
  0 bytes consed
NIL

А чего ты тогда рассуждаешь, если нихрена не знаешь, лол?

А я и не хочу тратить время на познание ещё одного Си++ во имя того, чтобы знать дохрена :-)

Ну это вообще пиздец, ты даже не понимаешь разницы между subtyping-полиморфизмом и параметрическим.

Из чего ты сделал такой вывод? По-моему, у тебя батхёрт :-)

У тебя какой lw? Hobbist, enterprise?

Оба.

А personal к эмаксу зацепится?

Personal Edition — не консольный, но можно после загрузки IDE подкрузить SLIME, и соединится из емакса. Будет тоже самое.

спасибо!

сделай, плз, этот же тест без оптимизации и на lispworks, и на sbcl. достаточно (time (main 1000))

тогда получатся все возможные варианты для сравнения

этот же тест без оптимизации и на lispworks, и на sbcl. достаточно (time (main 1000))

Выкинул строчку (declaim...)

* (time (main 1000))
1.274224148
Evaluation took:
  0.350 seconds of real time
  0.352000 seconds of total run time (0.352000 user, 0.000000 system)
  100.57% CPU
  627,718,938 processor cycles
  97,088 bytes consed

CL-USER 1 > (time (main 1000))
Timing the evaluation of (MAIN 1000)
1.274224148

User time    =       11.184
System time  =        0.000
Elapsed time =       11.039
Allocation   = 3840432236 bytes
0 Page faults

SBCL 1.2.14.debian

LispWorks Personal Edition 6.1.1