На самом деле, на ЛОРе в режиме чтения, как мне кажется, обитают множество адекватных личностей. Тролли - они просто самые заметные. И зачастую тролли сами понимают то, о чем идет речь, а просто им нравится такой стиль общения.

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

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

Лисп это состояние души )))

> Увы.... не привлечет...

> Даже в своем институте, слово лисп действует на людей как на быка тряпка.

Вот интересно было бы узнать причину  такого отношения - зачастую это просто нежелание что-либо узнать.

> С "элитарностью" и "матаном" тоже нужно бороться ;)

А как бороться?

С "матаном" бороться не нужно. "Матан" полезен.

> А как бороться?

Ну вот мне, субъективно, иногда бывает полезно подумать о задаче в определённых терминах. "Матан" кстати это жаргон - так студенты называют всё, что отвлекает их от приятного времяпрепровождения :) Да, анализ в программировании - специфично, это когда нужно числодробление, моделирование или решение ДУ, вобщем самим математикам оно и нужно. С другой стороны некоторые вещи (нематан, вроде теории множеств, логики или дискретки) могут находить большее применение. Короче оно полезно, но согласен - необязательно.

К сожалению, _большенству_ разработчиков пока и лисп не нужен...

В сожалению у лиспа нету ни одной среды разработки хорошей...

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

Появись бы что-то подобное для лиспа, думаю и он набрал бы популярность...

> "Матан" кстати это жаргон 

> В сожалению у лиспа нету ни одной среды разработки хорошей...

Ну так Emacs жэ! Ну или CUSP на худой конец.

> Тот же паскаль, стал таким популярным, благодаря делфи...
> Появись бы что-то подобное для лиспа, думаю и он набрал бы популярность...

В перевую очередь мало для CL "батареек". А IDE не нужны. Даже если кто-то напишет что-то, кто будет этим пользоваться? С Emacs не переманить никого :). Расчитывать только на новичков?

>> В сожалению у лиспа нету ни одной среды разработки хорошей...

Хотя звучит парадоксально, в целом - согласен. Впрочем, я имел дела только с SBCL и CCL (говорим о компиляторах), и хотя они восхищают своими возможностями, как пользователь я постоянно думаю "а вот бы мне хотелось чтобы...". Могу список на 100 пунктов составить. Может с коммерческими реализациями дела обстоят лучше, если да, то есть что-то ещё, что мешает распространению CL.

>> Что значит "не нужен"?

Это то, что я наблюдаю :-( Курсов нет (тех где сертифицируют), вакансий нет. Есть много языков которые востребованы на практике - человек пишет код, получает деньги, если ему задать вопрос про CL, он просто скажет - "а зачем?". В том-то и дело что как практический инструмент CL не распространён, не представляю как эта ситуация может изменится. Если только CL изменится.

Насчёт "не нужен" - ох уж эти кавычки ;) В общем:

-- С точки зрения "продвинутого пользователя" не нужно администрирование, нужен администратор.
-- Администратору (в вакууме :) не нужно программирование - нужны готовые фреймворки.
-- Веб-дизайнеру не нужно системное программирование, достаточно LAMP etc.
-- Человек пишет на C/C++/Java/..., вполне возможно, что CL/Haskell/... в его системе ценностей не присутствуют.
-- Erlang, OCaml могут быть нужны в некоторых случаях :) При этом CL как бы остаётся по-прежнему вне поля зрения.
Ну и так далее "матан" и прочее. Можно про блаб тут вспомнить.

>> Только код и реальная практика имеет значение, на этом и следует акцентировать внимание.

Аккаунт на github и вперёд?-))

>> В сожалению у лиспа нету ни одной среды разработки хорошей...

>Ну так Emacs жэ! Ну или CUSP на худой конец.

>> Тот же паскаль, стал таким популярным, благодаря делфи...
>> Появись бы что-то подобное для лиспа, думаю и он набрал бы популярность...

>В перевую очередь мало для CL "батареек". А IDE не нужны. Даже если кто-то напишет что-то, кто будет этим пользоваться? С Emacs не переманить никого :). Расчитывать только на новичков?

Если вы не берете в расчет новичков и средне статистических "кодерво", то удел лиспа только для Гуру, или элиты)))

>  Курсов нет (тех где сертифицируют)

> В сожалению у лиспа нету ни одной среды разработки хорошей...

Есть. Только это денег стоит. :-)

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

Неа, Turbo Pascal стал популярным задолго до Delphi (делфАй произноситься правильно, если что ;).

> Курсов нет (тех где сертифицируют), вакансий нет.

Есть, но это все на английском и очень "камерно". Franz Inc. сертифицирует и обучает. Вакансии, скорее нет, чем есть. Но в прошлом месяце пробегали две вакнасии на CL. Одна в Америке, то есть уже нужно быть там. Пару вакансий в Нидерландах на CL. Причем нидерландцы готовы были рассматривать кандидатов из любой точки мира.

>> Хм, и много вы знаете курсов по Python или Perl?

Ну, не много но знаю, у mainstream языков это нормальное явление, что тут такого?

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

Если вы главный разработчик то да :)) А так язык регламентируется.

> Если вы главный разработчик то да :)) А так язык регламентируется.

> Если вы не берете в расчет новичков и средне статистических "кодерво", то удел лиспа только для Гуру, или элиты)))

Ну CUSP-то сойдёт для новичка?
Я сам не так давно начал на CL писать, но мне IDE не понадобился.

По теме: "срачи" на ЛОРе очень полезны. Из-за них я и познакомился и с Lisp'ами и с ML'ями (Спасибо VSL'ю за прочищенные мозги).

Это признание перевернуло мое представление о срачах на лоре)))))))))))

Наверное, это уже избитая точка зрения, но мне кажется, Лисп слишком индивидуален. Из-за его сверхвысокой выразительности, каждый видит, любит и использует его по-своему. Разработка на Лисп, в которой будут участвовать пару десятков человек - это всё-равно, что сделать их богами и поставить задачу создать Землю и человечество с нуля так, чтобы было хорошо.

> Лисп слишком индивидуален. Из-за его сверхвысокой выразительности

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

И ничего печально в текущем положении Common Lisp'а (как и лиспов) нет. Есть и коммерческие реализации с адекватной системой лицензирования и ценами, есть и бесплатные, которые в одной лиге с коммерческими. Библиотеки и исходный код для множества алгоритмов присутствуют в достаточном количестве, а чего нет, то можно написать под свои нужды. Программистов на Лисп найти можно, как и обучить с нуля.

Вздохи и ахи на тему "почему же лисп не распространен", я считаю, появляются из-за того, что люди, кто знаком с лиспом, хотели бы его использовать на своих местах работы (часто из-за причины описанной в первом параграфе). Но вместо это пишут на том, что придется. Но, я не думаю, что лиспы станут распространены повсеместно в IT индустрии (да и не были они никогда). Сейчас ведь очень много программистов "с 9 до 18", которые пришли в это ремесло, по той же причине, что миллионы людей идут в юристы и бухгалтера -- платят хорошо, служебная лестница понятна, напрягаться вне проложенной дорожки не нужно. И теперь представьте себе что такой программист вида "с 9 до 18" будет писать на лиспе, где между ходом его мысли и ее выражением в виде программы не вырастает дополнительных барьеров и где вместо проложенной одной дорожки есть множество переплетений дорог ведущих к цели. Представили? 

> если запретить использовать макросы 

вот не нужно это делать :-)

> если запретить использовать макросы для подстройки синтаксиса

Ну так это везде так. Никто же не пишет
#define BEGIN {
#define END }
в программах на C/C++. Так что такие требования вполне разумны/корректны/сами собой разумеются.

> #define BEGIN {
> #define END }

Пишут, пишут -- я видел в одной коммерческой и широко известной не в столь узких кругах CRM системе :)

> вот не нужно это делать :-)

Ну а что ж сделаешь, если defun плохо работает?

> Ну а что ж сделаешь, если defun плохо работает?

Для CL как динамического языка defun/let работают так как и должны, но статические типизации позволяют компилятору создавать код на порядок лучше. Т.е. если я создаю биндинг/параметер i = 0, то i считается чем угодно - в дальнейшем я могу использовать её для хранения любого ежа, а отсюда оверхед gc и обычного времени. Т.е. либо нужно использовать обычные def* и загромождать код declare, либо делать макро-систему с выводом типов.

Как вы думаете что лучше? Определить следующий уровень абстракции, получать не оптимальный код, или играть в optimizing CL?

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

Возможно читали уже:

http://a-nickels-worth.blogspot.com/2008/03/optimizing-cl.html

и ещё:

http://t-b-o-g.blogspot.com/2009/10/brians-brain-on-common-lisp.html
http://t-b-o-g.blogspot.com/2009/10/brians-brain-on-common-lisp-take-2.html
http://t-b-o-g.blogspot.com/2009/12/brians-brain-on-common-lisp-take-3.html

весёлое занятие! А суть в том, что оно имеет эффект, чего быть не должно.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" (c)Donald Knuth

Больше мне ответить нечего, пожалуй кроме того, что я видел в интернете множество тестов, где "разгоняют" CL на предмет "оптимального кода", но я заметил две вещи у "разгонщиков":

1) Их код на CL становиться не читабельным вообще и напоминает такие же кошмары из других языков. Меня всегда интересует вопрос, зачем им CL, если они на нем пишут C?

2) В своем большинстве "разгонщики" не используют CL в своих рабочих проектах (на той же работе). Все чаще "разгонщики", это люди, которые занимаются в свободное время CL, при этом пишут "непонять что" (пишут "в ящик"), и это "непонять что" пытаются разогнать на "оптимальный код". То есть CL у них не основной язык программирования и в серьезных проектах они его не используют, продолжая все так же писать на С/Java/whatever 90% своего времени.

> Возможно читали уже: http://a-nickels-worth.blogspot.com/2008/03/optimizing-cl.html

Там комментарии примечательные, где автору указали, что если все делать Lisp-way изначально, а не тупо копировать код из perl, то все будет в разы быстрее без безумных опитимизаций.

artem, не могли бы вы написать как поняли два мои предыдущих поста, просто интересно :) Я кажется сказал то же что и вы.

Про 1 - macroexpand кода на CL (например макроса iter), и что мы видим? tagbody/go, block/return-from вобщем низкоуровневые шаблоны, такие же как и в Си. К сожалению мы не можем увидеть раскрытие ir1-transformation, разве что в trace. Это бы убедило ещё больше в том, что оптимизации - основная работа компилятора.

Про 2 - это всё уже неважно, начём они пишут большую часть времени. Давайте будем добрее /^_^/

>> Там комментарии примечательные, где автору указали, что если все делать Lisp-way изначально, а не тупо копировать код из perl, то все будет в разы быстрее без безумных опитимизаций.

Давайте сойдёмся на следующем))

defun создаёт привязки своих аргументов в окружении. declare оптимизирует их.
let создаёт локальные привязки. Макрос the или тот же declare оптимизирует их.
var на верхнем уровне создаёт глобальные переменные, proclaim их оптимизирует.

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

PS в brain's brain по ссылке говорящие графики, тут уж ничего не попишешь. Можно устроить локальный тест - убедиться.

Если в загловке зачится "ЛОР", то из этого вовсе не следует, что его тут надо устраивать.

Я смотрел IDE у Allegro. Очень напоминает Дельфи. Те же формочки, кнопки и т.д. Только на CL и множестве библиотек из коробки. Лицензия, конечно, жесткая. В общем, аргумент, что Лисп не популярен из-за того, что нет удобных IDE  не проходит. Боюсь (хоть я и не опытен), что у Лисп в любом случае окружающая среда  удобнее и технологичнее, чем у многих других языков. По крайнем мере в коммерческих версиях.
На Западе, конечно, с вакансиями получше http://lispjobs.wordpress.com/

Этот тред - местная инкарнация ))

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

Эх, на правах оффтопа вспомню...

Пришел в универе в какую-то лабу курсач делать. Завлабой предложил написать что-то-там. Я настоял на другой теме с условием писать на цэпэпэ. Приношу ему через некоторое время полуготовый вариант на коммон лиспе. Он выпал в осадок и начал громко материться. Я ему объяснил, что это типа разрабатывать удобнее на лиспе, готовый вариант перепишу на приплюснутых. Хрен там, через месяц приношу с нуля переписанный вариант, на пару десятков раз более производительный, но таки на коммон-лиспе!

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

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

Это самая большая тема сдесь наверно))

>Это самая большая тема сдесь наверно))
Еще пока нет. Но тенденция на лицо.

по крайней мере,
вот эта тема пока длиннее
http://lisper.ru/forum/thread/126

Оффтоп..

вступайте в пиратскую партию)

http://pirateparty.ru/home/

>> если запретить использовать макросы
Есть люди, считающие, что CL - язык мета/макро-программирования, и пишущие на нём исключительно из-за удобных макросов и data-as-code. А к идеологическим вопросам (кроме совсем бредовых, вроде нехватки скобок в loop) еще можно отнести &rest - есть мнение, что карринг/частичная-аппликация даёт больше профита, нежели просто возможность не написать (list ..). Да и вообще, везде, где можно выбрать два хороших, но разных варианта, будут разногласия. А в C++/#, явах синтаксис жесткий, на уровне синтаксиса путей мало, а вот там, где действительно могут возникнуть разногласия - в проектировании - придумали паттерны.

> Ну так это везде так. Никто же не пишет
> #define BEGIN {
> #define END }
> в программах на C/C++. Так что такие требования вполне разумны/корректны/сами собой разумеются.

Требование/пожелание не вводить лишние имена сущностей без добавления функционала вообще вполне разумно, но какое это отношение имеет к макросам? о_О

>Я тут недавно заглянул в исходный код dwim - там  везде def вместо defun, defmethod и т.п. Я дальше особо не стал смотреть, ибо у разработчиков просто большие проблемы с головой ;)

А мне использование def вместо defun у них очень да же нравится (хотя в начале то же было чувство отторжения). Там многие рутинные вещи решаются типа экспорта символов удобно решаются.
Вообще мне бы было бы интересно услышать вашу критику по поводу dwim.
Кстати а кто-нибудь еще с их библиотеками в частности с wui пробовал работать?

А что такое http://dwim.hu/ ? У меня страница пустая принимается по этому адресу :-/