За что не любят Common Lisp?

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

Кто тебе сказал что я «принимаю решение о его использовании»?

Я вообще я к тому, что скобочки - минус.

почему?

у всех читается

аптекари вон, почерк врачей разбирают

И при этом рантайм перестаёт быть CL-системой. Нужно только для доставки клиентам проприетарного софта. Т.е. не сильно нужно.

Нужно как раз для «всякой десктопной мелочи».

эта CL-система не всегда нужна

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

Надеюсь уже видел ;-) Вполне себе штучка:

Lisp Flavoured Erlang (LFE): https://github.com/rvirding/lfe

аптекари вон, почерк врачей разбирают

тут лишперы сами себе аптекари и сами себе врачи

Вполне. По производительности наравне с Java и C++ на сложных приложениях.

пейсать сложное мне лень. На простых задачах как оно? Мериться будем?

на ибае, дешево. Только с самомовывозом.

ога...

Common Lisp с 94 года, если что.

какая нафиг разница? ну за 20 лет так и не осилили стандартных либ... Кстати, почему нельзя было перетащить либы на CL с предшественников? Или у вас с каждым новым диалектом надо с нуля писать? тогда ясно...

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

http://img264.imageshack.us/img264/1397/lispnd7.png

Надо ECL допилить. :) Там .so на 1.8МиБ, а бинари вообще килобайты весят.

пофиг на .so. Когда я (правда несколько лет назад) сравнивал сколько места в памяти отжирает запущенный лисп с рядом часто используемых модулей - что sbcl, что ecl отожрали по 5-7 Гб, при этом ecl «нещадно тормозил» и выдавал такой сишный код, смотреть на который без слёз после disassemble в sbcl было невозможно. потом на долго вообще пришлось забыть про ecl, ибо под mingw он перестал собираться без долгих плясок с бубном.

Если сейчас ситуация другая - рад за него. Но надо бы сначала пощупать и убедиться...

На простых задачах как оно?

отстаёт, но совсем не на порядки

Ну, сколько раз у меня кто-то интересовался «почему такой большой?» в 100% случаев имелся в виду бинарник, а не рантайм в RAM.

Кто тебе сказал что я «принимаю решение о его использовании»?

Тогда почему бы в список минусов не дописать пятна на солнце? ;)

Проблема за малым - убедить заказчиков это использовать.

Там, кстати, костылей тоже хватает.

не знаю как щас, но пробовал собирать stumpwm на предпоследней версии ecl - переключение десктопов сторонними софтинами (EWMH) занимало, на глаз, в районе трети-половины секунды :)

На простых задачах как оно? Мериться будем?

на простых — смысла нет, сишечка всегда будет впереди.

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

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

Ну, сколько раз у меня кто-то интересовался «почему такой большой?» в 100% случаев имелся в виду бинарник, а не рантайм в RAM.

Надо было ответить: «Это разве много? Посмотри сколько он в рантайме отъест!..» :)

Лисповоды добавили к своему языку кучу скобок и почему-то называют это «отсутствием синтаксиса».

ты точно упорот: в твоём любимом ЯП ты как конец оператора обозначаешь? Я вот голову ломаю: иногда ";", иногда «}», а иной раз и ","... Подход лиспа куда как логичнее.

Отжирают они все много, но есть же ОС, с её системой виртуальной памяти.

ECL, говорят, стал более читаемый код на C выдавать с последним релизом.

Проблема за малым - убедить заказчиков это использовать.

Дык, заказчики пускай на Ерланге остаются, а ты свое пиши на этом.

Посмотри сколько он в рантайме отъест!.."

а если виртуальной памяти, да на 64 битах...

Лучше бы только самое нужное и вменяемое тащили.

Тогда бы получилась схема )))

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

Лисперы странные существа, у всех читается а скобочки вводят в ступор, а им наоборот.

нормальные лисперы (что SICP читали) используют аккуратное отформатированное написание. Которое легко читается.

Я своё пишу на CL.

ECL, говорят, стал более читаемый код на C выдавать с последним релизом.

Таки надо будет глянуть

а если виртуальной памяти, да на 64 битах...

Ну можно CL попросить «прогнать» gc и попросить показать - сколько осталось памяти в использовании.

Поддерживаю staseg. Для написания десктопного приложения можно использовать LispWorks. Еще можно попробовать Allegro CL. На MacOS X до кучи можно взять Clozure CL - там есть биндинги к Objective-C.

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

Я то с этим вполне могу жить припеваючи, задействуя только «совремменые» конструкции, а вот нытикам это не нравится :)

Ну, сколько раз у меня кто-то интересовался «почему такой большой?» в 100% случаев имелся в виду бинарник, а не рантайм в RAM.

Ну, сколько раз у меня кто-то интересовался «почему такой большой?» в 100% случаев имелся в виду хер, а не какая-то компьютерная ерунда :)

По-моему в даном случае речь шла именно о размере рантайма в памяти, потому что десяток десктопной мелочевки - и привет гигабайту ОЗУ.

а под линукс и так чтобы не платить сотни тысяч мульёнов?

на простых — смысла нет, сишечка всегда будет впереди.

т.е. выигрыш будет только на жирных монолитных приложениях, по типу M$-Windows? Ибо любое жирное нормально спроектированное приложение можно поделить на множество задач, и решать их на сишечке, как например ядро GNU/Linux. Вот только почему Win тоже на сишечке писано? Ну гуй уже на C++. Но никак не LISP?

ECL, говорят, стал более читаемый код на C выдавать с последним релизом.

Читаемый - да, особенно при (debug 0). Эффективный - к сожалению, нет.

а под линукс и так чтобы не платить сотни тысяч мульёнов?

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

десяток десктопной мелочевки - и привет гигабайту ОЗУ.

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

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

ну вот, это одна из причин, по которой десктопного софта на CL так мало: народ посмотрит, плюнет, и пойдёт писать на бидоне.

По-моему в даном случае речь шла именно о размере рантайма в памяти, потому что десяток десктопной мелочевки - и привет гигабайту ОЗУ.

Есть подозрение, что раньше, чем у тебя закончится память, ты устанешь ждать множественного запуска этого самого рантайма, особенно если это будет не последовательный, а циклический запуск разной мелочёвки ;)

Всё-же CL более располагает к такому: запустил раз среду, а уже в ней делай что хочешь. Хотя это и не «истина в последней инстанции»

жирных монолитных приложениях

почему? можно грузить/компилять/удалять код в рантайме. Помощнее сишной плагинной архитектуры будет. + можно задействовать различные IPC между частями огромного приложения.

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

угу, но для этого у тебя большая часть софта должна быть на CL

ну вот, это одна из причин, по которой десктопного софта на CL так мало: народ посмотрит, плюнет, и пойдёт писать на бидоне.

тем кому нужно писать БОЛЬШОЙ СОФТ, те купят, напишут софт и продатут. PROFIT!

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

Пожалуй, я бы все равно остановился на LW, а так: http://cliki.net/GUI.Только я последние особо не смотрел, но кажется, там есть достойные, если, конечно, твой вопрос не ради поддержания беседы :)

Еще есть вариант. Могу ошибаться, но мне показалось, что можно писать на Clozure CL, используя GTK напрямую. Это, все таки, не WinAPI вызывать.

За что не любят Common Lisp?

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

тем кому нужно писать БОЛЬШОЙ СОФТ

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

если, конечно, твой вопрос не ради поддержания беседы :)

это ЛОР, тут 99% для поддержания беседы :)

можно писать на Clozure CL, используя GTK напрямую

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

Я уже приводил жирноту современных рантаймов, вот еще раз:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 8560 tekila    20   0  884m 411m  60m S   18  5.1  11:29.17 MainThrd           
 3684 tekila    20   0  813m 250m  41m S    2  3.1  19:48.01 firefox            
 4803 tekila    20   0  392m  90m  35m S    0  1.1   0:15.32 thunderbird        
 2271 tekila    20   0  432m  88m  39m S    1  1.1   3:56.50 compiz             
 2329 tekila    20   0  255m  50m  16m S    0  0.6   0:27.96 dropbox            
 6940 tekila    20   0  270m  38m  18m S    0  0.5   0:33.39 lw                 
 6882 tekila    20   0  103m  38m  13m S    0  0.5   0:41.28 emacs            

На последних строчках: емакс (SLIME + distel) и LispWorks (с кучей загруженны систем) — a если стрясти все не нужное, будет еще меньше.

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

PS: первый в списке — Steam ;-)

я об этом уже сказал

у меня так:

 6974 dk         1   0 1627m 1,3g 6044 S  25,9 16,6   0:30.39 kvm                                                                                                     
 7000 dk         1   0  656m 139m  36m S   0,0  1,7   0:04.18 xulrunner-17.0                                                                                          
 6551 dk         1   0 1048m  61m  23m S   0,0  0,8   0:00.53 stumpwm                                                                                                 
 6184 root       1   0  171m  60m  26m S   0,0  0,8   0:04.67 Xorg                                                                                                    
 6233 dk         1   0  347m  40m  10m S   0,0  0,5   0:01.87 emacs                                                                                                   
 6889 dk         1   5  853m  39m  30m S   0,0  0,5   0:00.57 p4v.bin                                                       

тем не менее, для простейших приложений - оверхед

кстати, я так понимаю это у тебя 32 бита?

кстати, я так понимаю это у тебя 32 бита?

ага - PAE ;-) не вижу профита в 64 битах на десктопе.

> Переусложнённая нечитаемая каша

> сишечки, джавы

Лисперы странные существа, у всех читается а скобочки вводят в ступор, а им наоборот.

сишные «*» и «&» в разных количествах и порядках просто образец читаемости, а жабское многословие из ничего пророк его.

а жабское многословие из ничего пророк его.

«Паблик статик файнал Борщ борщ нью Борщ, пожалуйста.»