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

А на практике 99% так называемых лисперов лиспом пользоваться не умеет.

А мой лисп - вообще Wolfram Mathematica. Туда и смотри, там концентрация вменяемости на порядок выше чем в лисп-тусовке.

Правильный код на Лиспе должен генерить оптимизированный
императивный код из высокоуровневого декларативного DSL.

Бред.

А мой лисп - вообще Wolfram Mathematica. Туда и смотри,

а вот это да - великолепная вещь

LispWorks IDE написано с использованием CAPI (это такая библиотека для создания GUI),

GUI там примитивнейшее, такое и в 80-х не тормозило, не хватало еще, чтоб на современном железе были тормоза на банальных контролах, а «тяжелое» гуи можно посмотреть, например, в XCode

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

т.е. ни для чего, ок

для тебя - да, ни для чего не подойдёт ни при каких условиях ни в какое время ни для какой задачи. Удовлетворён?

Кстати, вышеупомянутый cl-ppcre именно это и делает. А бред у тебя в штанах, лошара.

для тебя - да, ни для чего не подойдёт ни при каких условиях ни в какое время ни для какой задачи. Удовлетворён?

зря ты так :( я вот схему прикрутил - доволен, но у нее есть таки плюсы - удобное скриптование и «склеивание» модулей, а у CL я плюсов не вижу, выше писали про метапрограммрование, но опять же - я лучше возьму racket, больше ничего конкретного не было

Кстати, вышеупомянутый cl-ppcre именно это и делает.

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

я вот схему прикрутил - доволен, но у нее есть таки плюсы - удобное скриптование и «склеивание» модулей

Может дело привычки? После CL-я я сколько к схеме не подходил, не покидает ощущение, что я «как корова на льду». Опять же скорость - в среднем sbcl со своим JIT быстрее, хотя это не критично. Из плюсов у ракеты - хотя бы доделанность оффтопик-версии. Но наблюдая за «приключениями» monk-а с макросистемой ракеты ни как не могу ощутить энтузиазм в её освоении.

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

никак. Особенно плохо с gc. Впрочем, CL годен как язык для прототипов. Танчики из бумаги тоже проще клеить.

Касаемо книг хотелось бы что то типа k&r, в такой же манере, но для common lisp, ну вы поняли.

SICP уже прочитал?

После CL-я я сколько к схеме не подходил, не покидает ощущение, что я «как корова на льду».

А конкретнее, на уровне языка, чем схема недотягивает?

с макросистемой ракеты

У большинства реализаций, емнип, есть defmacro.

Ты не понял. Нет причин для торможения даже «тяжелого» гуи на лиспе. Существующий CLOS вполне справляется с этой задачей. Ведь ты это оспаривал?

Обычно гуи тормозит у людей часто совсем по другим причинам, не из-за языка, и нет тут значимых преимуществ у Си и Си++. Обычно люди косячат в сложности алгоритмов. Это касается и создателей гуишных библиотек.

Кстати, лисповский CAPI куда проворнее, чем Swing и SWT. Работает даже на слабом железе типа вторых пней.

Что касается XCode. Я знаком с Objective-C. Этот язык тоже не вершина скорости. Там часто используется динамическая диспетчеризация методов. Как видишь, даже этого достаточно, чтобы Cocoa не тормозила, поскольку, повторюсь, дело не столько в языке.

Хотел вот узнать, а нет ли аналога ipython для CL без задействования emacs'а?

Ты не понял. Нет причин для торможения даже «тяжелого» гуи на лиспе. Существующий CLOS вполне справляется с этой задачей. Ведь ты это оспаривал?

я про GUI вообще не говорил, а про то, что ООП на CL в виде CLOS сильно проиграет C#, Java и C++ в скорости

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

да, это так, потому, повторюсь, и не приводил в пример GUI

Кстати, лисповский CAPI куда проворнее, чем Swing и SWT. Работает даже на слабом железе типа вторых пней.

как я понял, по факту CAPI это такой себе «wxWidgets», только гораздо более примитивный, т.е. и не должен тормозить, а у Java GUI - таки отдельная история

ООП на CL в виде CLOS сильно проиграет C#, Java и C++ в скорости

А у перла, питона, пэхапэ и руби сильно выиграет. И чо?

А у перла, питона, пэхапэ и руби сильно выиграет. И чо?

очевидно же - если надо упираться в производительность, то CL не катит, а если не надо - с большой вероятностью лучше подойдут «перл, питон, пэхапэ и руби»

А конкретнее, на уровне языка, чем схема недотягивает?

Я не говорил «недотягивает». Я имел в виду - сильно другая.

У большинства реализаций, емнип, есть defmacro.

нафига тогда переходить на схему? :)

кстати прошу воспринимать мои посты как троллинг с целью таки выяснить лучшие стороны CL

если не надо - с большой вероятностью лучше подойдут «перл, питон, пэхапэ и руби»

это ты про «мультидиспатч», и не только по типам? И других потребностей в скорости, кроме как «быстр как сишка» и «не страшно, что тормозит как питон без jit-а и байткода, но с GIL-ом» и быть не может? :)

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

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

Начнём с того, что производительности лиспа хвататет везде, где хватает производительности «перл, питон, пэхапэ и руби». А это колосально широкая ниша. Это раз.

Маленькое отстование лиспа, там где оно вообще есть, совершенно не критично для почти всех остальных задач. Это два.

А про числодробилки на лиспе тебе уже рассказали.

с большой вероятностью лучше подойдут «перл, питон, пэхапэ и руби»

Очередное бездоказательное утверждение. Пэхапэ вообще нигде не следует применять. Совсем. Перл --- write-only язык, извините, но это правда. Руби --- безнадёжный тормоз. По данных шутаута сливает лиспу до _трёхсот_ раз. А питон --- в принципе тот же лисп, только убогий на обе ноги и тоже тормоз, хотя и быстрее руби.

Такие дела.

да, у меня тоже пятница.

А питон --- в принципе тот же лисп

Эм.. а чем можно подкрепить сие утверждение?

и и тоже тормоз

Есть еще pypy, вообще-то.

И вопрос «батареек» обделен вниманием, а он очень намаловажен.

совершенно не критично для почти всех остальных задач

Консольную утилитку стоит писать на лиспе? А десктопную гуйню? А серверную вебню (если примерно в той же «ТТХ-нише» есть racket)?

Хотел вот узнать, а нет ли аналога ipython для CL без задействования emacs'а?

rlwrap

Консольную утилитку стоит писать на лиспе?

Лучше на ecl

А десктопную гуйню?

Если в ней есть какая-то логика кроме on_buttonXcliclk. Если она сама по себе является производной от предметной области.

А серверную вебню

А почему нет. См. предыддущий пункт.

(если примерно в той же «ТТХ-нише» есть racket)?

А это вопрос религиозный.

rlwrap

Как все печально, а нема readline для sbcl? Пробую linedit - но это полукомбайн, вещь в себе.

Хотел вот узнать, а нет ли аналога ipython для CL без задействования emacs'а?

ABLE если в графике

Limp для vim

а нема readline для sbcl?

А оно не ghjqltn из-за gpl-ности.

Лучше на ecl

Чем лучше? Буква e там ничего не значит после 10ка загруженных пакетов.

Лучше на ecl

А его сами лисперы не ругают, что «много чего нет», не легко ли будет на это наткнуться?

Если в ней есть какая-то логика

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

А это вопрос религиозный.

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

Limp для vim

Тогда уж лучше slimv

Как все печально, а нема readline для sbcl?

Угадай, что значат r и l в rlwrap?

Угадай, что значат r и l в rlwrap?

Знаю, разумеется, печаль в том, что это костыль. Или скажем, дополнение (ну да, не совсем голый readline хотелось бы), прозрачно будет доступно?

А оно не ghjqltn из-за gpl-ности.

А в чем проблема сделать gpl sbcl-библиотеку? И использовать ее для repl (конечный же пользователь может смешивать как хочет), непосредсвенно в проект она не полезет.

а для чего он лучший выбор? не для ООП точно, там его все порвут по скорости, для работы со строками - тоже не катит (выше был пример), для быстрого и простого накидывания кода тоже плох - примеры на ruby и lua в разы меньше, так зачем он вообще нужен?

Ну вот для чего нужен БМВ? У Киа тоже 4 колеса, у ТАЗа тоже есть баранка, Тойота - самая популярная машина в мире, Опель делают в той же стране, а Хёндай соната даже делает визуальный закос под БМВ-пятёрку.

Проблема в том, что всё это гомно совокупно хуже БМВ.

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

Эм.. а чем можно подкрепить сие утверждение?

Назови мне основные значимые отличия питона от лиспа.

Есть еще pypy, вообще-то.

Я могу в моей генте оставить его единственным интерпретатором питона? Уж больно emerge тормозит, прям не знаю что и делать.

И вопрос «батареек» обделен вниманием,

Вперёд.

Консольную утилитку стоит писать на лиспе? А десктопную гуйню? А серверную вебню (если примерно в той же «ТТХ-нише» есть racket)?

Пишите.

Ну вот для чего нужен БМВ?

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

А вот такое уточнение: с каким другим (Java?) языком наибольшее пересечение ниш? (временно откладывая макросы и (e)DSL); и что выпадает из пересечения?

Проблема в том, что всё это гомно совокупно хуже БМВ.

Хачмобиль же ^_^. А еще моторы к «крыльям черным, что посмели летать»..

А вот такое уточнение: с каким другим (Java?) языком наибольшее пересечение ниш? (временно откладывая макросы и (e)DSL); и что выпадает из пересечения?

Не знаю. В лиспе самое главное - это концепция символов и наличие eval, способным модифицировать окружение.

А питон --- в принципе тот же лисп

Эм.. а чем можно подкрепить сие утверждение?

Назови мне основные значимые отличия питона от лиспа.

Ну и подходец %). Может проще сформулировать тезис: «все динамические языки - суть недолисп».

Вперёд

А что «вперед»: в лиспокомьюнити народу не очень много.

Консольную утилитку стоит писать на лиспе? Пишите

Ну тот же paktahn - бинарь 60м => startup-cost. Или sbcl --script (при холодном запуске) был бы намного шустрее?

Или скажем, дополнение (ну да, не совсем голый readline хотелось бы),

Если подсунуть ему список дополняемого. Хотя между пакетами он все равно не догадается.

А в чем проблема сделать gpl sbcl-библиотеку?

Большинство использует Slimе, он же рекомендован для SBCL. Всех остальных мало и им не очень надо.

Ну и подходец

Вай нот? Если ты не можешь описать разницу, значит различие не так уж и велико.

в лиспокомьюнити народу не очень много.

А FFI религия использовать запрещает. Обидно-то как.

Кстати, про pypy как единственный питон в системе --- это был серьёзный вопрос. Можешь ответить?

Ну тот же paktahn - бинарь 60м => startup-cost. Или sbcl --script (при холодном запуске) был бы намного шустрее?

Не уверен, что понял ваш вопрос.

Тогда уж лучше slimv

Он тяжелее и глючнее. Это скорее почти IDE и для запуска пары команд избыточен.

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

Вай нот? Если ты не можешь описать разницу

Причем тут, собственно, я? То есть, чтобы поинтересоваться, «чем подкреплен ваш аргумент» - мне нужно разбираться в лиспе? А то, батенька, создается впечатление, что вы слабо плаваете в лиспах, а здесь просто отыгрываете роль (извиняюсь) паладина.

Кстати, про pypy как единственный питон в системе --- это был серьёзный вопрос. Можешь ответить?

Забыл ответить: вряд ли получится. Хотя может вам обидно держать несколько питонов и использовать pypy там, где можно?)

Не уверен, что понял ваш вопрос.

Очевидно же: консольной утилите негоже иметь большое время запуска (там где его можно избежать).

А его сами лисперы не ругают, что «много чего нет», не легко ли будет на это наткнуться?

В смысле стандарта есть все. Всмысле бибилиотек ситуация исправляется. Наткнуться разве что на поголовный инлайнинг и (safety 0) всего из коробки (лечится). Но именно для разработки консольного будет лучше.

Возможно. Limp не использовал из-за его убогости, а сейчас свалил на emacs.

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

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

Хотя может вам обидно держать несколько питонов и использовать pypy там, где можно?)

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

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

Вот за это я emerge и не люблю, пока оно зависимости разрулит можно успеть кофе сварить.

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

C переменным успехом и безсистемно. Жизнь опредленно есть, но нет глобальности и надежности. Сам пишу на tk.