5-й номер журнала «Практика функционального программирования»

А новый конкурс будет?

> Популярность - это частота применения. К CS популярность имеет отношение перпендикулярное.

тут надо согласится в целом, и в частности из лиспа еще не все ценное успели растащить в другие языки :-)

А новый конкурс будет?

А старый чем закончился? Что-то я проспал.

> Последняя вакансия, что я видел по Хаскеллю - Токио

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

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

Самураи служат за честь, а не за вознаграждение и уж подавно не пишут на пыхпыхе.

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

> А старый чем закончился? Что-то я проспал.

Тем что Visual Basic уделал в хвост и в гриву всю гламурную функциональщину.

Ссылка?

Это что-то наподобие cabal.

hackage - http://hackage.haskell.org - это репозиторий, аналог CPAN для перла. Или boost - для плюсов.

Так где можно посмотреть на центральное (или хотя бы достаточно большое) хранилище пакетов для CL?

http://www.cl-user.net/

> Или boost - для плюсов

Ты что-то путаешь, boost не является аналогом CPAN или haskage. Каким-то аналогом boost, кстати, можно считать arnesi.

Так где можно посмотреть на центральное (или хотя бы достаточно

большое) хранилище пакетов для CL?

Непосредственного аналога CPAN для CL, как и для большинства других языков, естественно, нет. Есть несколько разных решений для упрощения установки пакетов. Также есть cliki, на основе которой работает asdf-install. Что именно интересует?

Как раз-таки в 2005 году был максимум потом пошло на спад.

man AI winter

Хочешь узнать, что Бог думает о лиспе? Посмотри на лисперов. © Зефиров (емнип)

Молодец, можешь качнуть штангу.

Мысль крайне проста. У того же erlang есть своя ниша, у пайтона есть ниши и тд. А у CL ниши нет. Вот и вся идея.

+ поведение лисперов и правда очень интересное, всегда советуют использовать CL, а как доходит до подробностей начинается: «это не работает, но легко допилить»(этим как минимум грешит archimag), «этого нет, но легко написать»(вон сколько уже [user]dmitry-vk[/user] мучается с многопоточностью в винде?). А у erlang того же в коробке 100500 _рабочих_ библиотек и он открыт (Про коммерческие LispWorks и аллегро не надо только песни петь).

На самом деле, если даже Грэм называет CL трупиком, то какой можно дальше вести разговор?

> На самом деле, если даже Грэм называет CL трупиком, то какой можно дальше вести разговор?

Грэм много чего говорит, и кстати, он просто не любит CL.

> man AI winter

Где ai winter, а где 2005 год.

К великому сожалению цлисперов, не любит он его по вполне определенным причинам(я говорю про его эссе Being Popular). Он всё же не последний человек в лисп-сообществе.

Что вы к тредам в sbcl под вендой приципились? Ну хочется dmitry_vk ковыряться с ними, он и ковыряется в своё удовольствие. Если так прижало, что нужно писать многопоточный софт на лиспе под венду, берите ccl. С точки зрения программиста разницы между разными коммон лиспами - в значении переменной inferior-lisp-program в slime.

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

Единственное, что правда нравится это slime, но опять же для erlang есть замечательный distel.

PS. Как у clozure cl дела обстоят с армом?

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

У программистов - это нормальное чувство. Тем более, в opensource. Сторонние проекты живут своей жизнью, ломая совместимость со старыми версиями. У меня такое и с C/C++ было, приходилось лочиться на конкретных версиях. И с внутренним питоновым утилём сейчас тоже самое: сначала warning'и о deprecated выдаются, через полгода вообще ломается насмерть.

SBCL сам по себе развивается хорошо: функциональность ширится, баги фиксятся, регрессионные тесты добавляются, коммьюнити растёт.

PS. Как у clozure cl дела обстоят с армом?

Без понятия, у меня нет арма. Вернее, есть в ТомТоме, но мне в него лезть нафиг не впёрлось.

> А у CL ниши нет.

Универсальный язык программирования. О каких нишах речь?

этим как минимум грешит archimag

Хм, можно поподробней в этом месте? О чем конкретно речь? Я вообще не знаю технологии где всё есть и меня устраивает, в том числе по библиотекам. В моей текущей области меня вообще всё сейчас устраивает (нет, вру, надо выделить время, добить аналога mod_auth_kerb для Hunchentoot и окончательно выкинуть Apache).

На самом деле, если даже Грэм называет CL трупиком

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

>Хм, можно поподробней в этом месте? О чем конкретно речь?
Уважаемый, прошу прощения за клевету, бес попутал! http://www.linux.org.ru/forum/development/4654501#comment-4654719 --- я имел ввиду этот пост.

Он не любит CL, а сообщесто CL-разработчиков не любит его.

Причинно-следственная связь очевидна.

Причинно-следственная связь очевидна.

Не очевидна.

> Где забрасывание дерьмом? Где крики, что ФП не нужно???

ФП - околонаучное ИТ-мракобесие, не нужно. *вяло кидает говняшку на вентилятор*

Хм, а вообще чё так прицепились то к потокам в SBCL под виндой? Да, SBCL является одной из ведущих открытых реализацией CL, но SBCL изначально ориентировался на Linux и то, что он вообще работает под другими платформами не более, чем заслуга некоторых энтузиастов - основной коллектив разработчиков особо по этому поводу не беспокоится. Если нужны потоки под виндой - берите Clozure CL (только не надо путать с Clojure), это так же высококачественная реализация CL, которая лучше чем SBCL поддерживает другие платформы. Т.е. сейчас лучший под Linux это SBCL, а под другие платформы Clozure CL. Обе реализации имеют превосходную поддержку со стороны SLIME и большинство библиотек прекрасно работают и там и там. При этом, переход от реализации к реализации вообще никаких сложностей не вызывает. Кроме этих реализаций есть другие, например во многих случаях может быть очень интересен ECL. И ещё раз: сменить реализации в большинстве случае это лишь немного поправить конфиг SLIME, либо просто (как настроено у меня) запустить его другой командой.

> А никакого «Ъ лиспи-стайл» в природе не существует, угу.

Возможно, моё замечание и не относится к «стилю», но Лисп преподносят как язык, где «код = данные», что как бы намекает, что Ъ-лиспер будет сплошь и рядом генерить динамический код. Это можно принять за стиль? :)

Прочитал я комменты и могу точно сказать, что perl - лучше всех! Hackage? Уже неплохо, но люди не могут писать нормальную документацию. boost? это вообще одна библиотека большая, про что ты.

Практически все что есть во всех других языках либо уже есть в perl core либо тянется из CPAN'а.

Хотя list хорош в реализации elisp, как понятный, удобночитаемый язык для редактора emacs.

>А у CL ниши нет. Вот и вся идея.

Вот не надоело троллям которой год эту лажу нести? Лисп - тот же басик, питон, пхп, только немного по-другому, плюс ещё различные фичи. Чего не хватает? Статического ООП, как в жаве или c#? Ну, ставьте везде декларации, может type propogation реализации спасёт.

erlang

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

А erlang и хаскелль не могут для любой задачи применяться? Примеры: ejabberd, xmonad.

> но Лисп преподносят как язык, где «код = данные»

Это одна из особенностей «лиспов», но не является основной для Common Lisp. Для Common Lisp вообще нет «самой главной» идеи (например такой, как «всё это объекты»), это сбалансированный, прагматичный язык, сочетающий в себе самые разные концепции.

что как бы намекает, что Ъ-лиспер будет сплошь и

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

Это не соответствует реальной практике программирования на Common Lisp.

Это можно принять за стиль? :)

Если что и называть стилем Common Lisp, то я бы указал на прагматизм, который базируется на его спецификации, которая не стремиться к каким-либо идеальным концепциям. На самом деле, стиль Common Lisp не в самом коде, не в том, что и как он делает, а в том как он пишется, в модели разработки.

> А erlang и хаскелль не могут для любой задачи применяться?

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

haskell для тех, кто любит созерцать «идеальные» конструкции. Это не инструмент созидания, а скорей способ размышлений о вечном ;)

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

Про erlang ничего сказать не могу - не смотрел.

> Прочитал я комменты и могу точно сказать, что perl - лучше всех!

Батенька, да вы просто гений логических умозаключений! :))
Хотя соглашусь, Перл имеет кучу приятных _И_ПРОСТЫХ_ аспектов, делающих программирование на нём приятным мыслеизъявлением.

>xmonad

ну, вот хоть я и использую xmonad больше года, не считаю его слишком показательным как гуи приложение. Сам по себе примитивен, конфиг весьма сложен (из-за хаскела), есть проблемы. Отловленные ошибки в конфиге порождают сообщения на десятки строк. Может меня и устраивают минимализм плюс имеющиеся библиотеки, но это явно на пример приложения не тянет.

ejabberd

И это сильно далеко от телекоммуникаций?

Про erlang комментровать не буду - не разбираюсь, насчет xmonad'a - пример применения haskell'а вне математики.

archimag, я так догадываюсь, что ты хорошо разбираешься в Лиспе и возможно даже применяешь его в продакшене. Насколько он хорош в этом плане? У нас вот стоят вполне классические задачи, которые я хотел бы решить на более эффективном языке (сейчас это C#). Это sockets(+SSL), database(MS SQL, но не обязаловка), GUI. Т.е. классическая клиент-серверная модель. Может лисп предложить здесь что-то более оптимальное/эффективное и что конкретно?
Для меня, зарабатывающего хлеб софтом, вопрос «крутизны» языка стоит именно в таком разрезе - что я могу сделать быстрее и лучше в конкретных, требуемых заказчиком нишах, а не сортировках и числах Фибоначчи. :) (это такой камешек в функциональщиков)

>xmonad'a - пример применения haskell'а вне математики.

Это не production software, так что приводить в пример его некорректно. Это даже не софт в обычном понимании, а скорее куча либ из которых можно сделать хороший, но примитивный вм. И вот вреда от статичности хаскелла тут больше, чем пользы от его типов. Мне, конечно, нравится то, что у меня получилось с примитивным конфигом, но язык не повернётся приводить это в качестве аргумента за хаскелл, скорее получится против.

<шютка> Можешь писать все как было - на шарпе, а данные из базы сортировать хаскеллем </шютка>

> Или взять тот же CLIM? За 15 лет не могут допилить,

хотя не последние люди в проекте участвуют.

Просто никому не нужен, да и сейчас уже есть cl-gtk.

Мне нужен. Слова Sun-ch'а о «не последних людях», кажется, относятся к прошлому моменту. Сейчас допиливание McCLIM практически остановилось, если судить по конфе. Особенно после того, как пропал куда-то Troels Henriksen и несколько отошел от хакинга Cristophe Rhodes. Я пару патчей в конфу послал, а там ни слуху, ни духу. Так и остались без комментариев (хотя бы критики) и неприложенными. Такое ощущение, что мейнстрим умер. А у меня еще есть изменения, но незаконченные, так они более масштабные. Но смысла слать в пустоту уже не вижу. Даже не знаю, что делать: либо просить, чтобы дали доступ, либо форкать.

У меня есть свое видение перспектив CLIM. Но это уже отдельный разговор.

matuba, я пишу для веб и о возможностях применения CL в других областях могу рассуждать только гипотетически. Библиотеки для работы в sockets(+SSL) есть, хорошие (usocket, iolib), но насколько хороша поддержка SSL (via cl-plus-ssl) не знаю, не пользовался. Для баз сейчас лучшая поддержка есть для PostgreSQL (postmodern), для работы с MSSQL видимо нужно юзать CLSQL (via ODBC) - я её не люблю и для своих скромных нужд (мне нужно вынимать данные из 1C и немного туда писать) я сделал cl-mssql - биндинг к FreeTDS, но это очень простое решение. Для GUI видимо сейчас лучшее решение это cl-gtk2, но особо не юзал, ибо просто не пишу GUI (кому он сейчас нужен?). В целом, конечно, имеющиеся библиотеки для «прикладных» задач, конечно, уступают имеющимся в .Net.

Может лисп предложить здесь что-то более оптимальное/эффективное

и что конкретно?

Он может предложить более мощный язык. Например, более мощный ООП со встроенной поддержкой мультиметодов, или более развитую систему обработки ошибок - сигнальный протокол, или пресловутые макросы, в общем, см. http://lisper.ru/articles/common-lisp-technologies. Вопрос возможности практического применения сводится к сравнению «библиотеки vs язык». Например, при программировании на CL за счёт возможностей CLOS можно вообще забыть о такой жуткой вещи, как «Визитор», что может иметь весьма важное значение (повидали мы кода).

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

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

просто не пишу GUI (кому он сейчас нужен?).

Всем нашим виндузятникам :) Без кнопки «сделать всё зашибись!» не станут даже смотреть. Кстати, ГУЙня у нас как раз весьма разнообразная, включая docking, combobox-tree, listbox-checkboxes и прочих мутантов (сейчас всё на WPF). Плюс логика элементов, кэши всякие... так что «веб-морда» не катит.

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

> CL как язык может применять почти для любой задачи

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

> дайте реализацию, которую можно смело применять в деле

только ее нет

Их много разных, которые можно смело применять в деле. На основе чего вы отрицаете очевидное?

> Их много разных, которые можно смело применять в деле. На основе чего вы отрицаете очевидное?

вы правда не видите серьезные претензии к любым существующим реализациям cl или вы их игнорируете? словосочетание «CL как язык» уже говорит само за себя.

> вы правда не видите серьезные претензии к любым

существующим реализациям cl

Они работают, какие могут быть претензии? Насчёт «любым» не скажу, со всеми не работал, но ведущие реализации развиваются буквально десятилетиями со всеми вытекающими. К примеру, я использую всегда самую последнюю версию SBCL и ни разу не сталкивался с какими-либо трудностями из-за этого.

словосочетание «CL как язык» уже говорит само за себя.

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

>Чего не хватает?
Не хватает:
1) нормальных библиотек и реализаций --- без «легко допилить» и «легко переписать»;
2) поддержки серьезных дядь;
3) нормального не воинстующего комьюнити, понимающего проблемы CL *Грэма и того не взлюбили*

в жоп^W узкой нише, как и хаскел, и оттуда они никогда не выберутся.

Вот тут ты абсолютно не прав. Erlang благоодаря тому, что он хоть где-то может использоваться и _используется_, сейчас активно полез в веб. И вообще зайди на амазон и посмотри сколько книги по erlang --- все вышли не так давно и еще планируются к выпуску, тоже показатель состояния.

CL как язык может применять почти для любой задачи.

Может. кто же спорит? Факт в том что практически не используется.

erlang это язык, который надо терпеть

Терпеть не надо. На нем пишут с удовольствием ;)

И это сильно далеко от телекоммуникаций?

DB: Riak, CouchDB
Веб: Nitrogen, erlang-web, erlyweb, chicago boss
3d моделирование: Wings 3d

> Не хватает:

1) нормальных библиотек и реализаций

Тоже самое можно сказать про любой другой язык. Утверждать подобное можно только применительно к какой-либо задаче: вот здесь для Python/Java/C++/etc есть хорошая библиотека, а для CL нет. Языка, который бы превосходил прочие по подбору библиотек в любой области просто нет.

Не хватает:

2) поддержки серьезных дядь;

О каких дядях идёт речь? Есть качественные коммерческие реализации с поддержкой. Есть ITA Software, которую, как говорят, сейчас хочет купить Google.

Не хватает:

3) нормального не воинстующего комьюнити

А оно, как раз, такое и есть, просто не надо делать «глубокие» выводы по такому специфичному месту, как ЛОР. Как раз популяризации CL мешает то, что в нём нет «религии» (такой, как например в Ruby). Проблема есть в том, что в нём много случайных людей, привлеченных байками об «элитарности».

Факт в том что практически не используется.

Используется. По крайней мере ведь коммерческие поставщики на что-то живут? А ITA создаёт весьма мастшабные приложения. Ну да что об этом в очередной раз спорить?

erlang это язык, который надо терпеть

Терпеть не надо. На нем пишут с удовольствием ;)

Ну да, если ранее писали на C. Для имеющих опыт разработки на CL, или хотя бы Python/Ruby речь именно о том, что надо терпеть.

>О каких дядях идёт речь?
О дядях типа межделмаша, эриксона, оракла, гугла и других монстров. Есть уверенность, что если завтра в автокатастрофу кто-то попадет, то поддержка мипс не отвалится, к примеру.

Утверждать подобное можно только применительно к какой-либо задаче: вот здесь для Python/Java/C++/etc есть хорошая библиотека, а для CL нет. Языка, который бы превосходил прочие по подбору библиотек в любой области просто нет.

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

Используется. По крайней мере ведь коммерческие поставщики на что-то живут? А ITA создаёт весьма мастшабные приложения. Ну да что об этом в очередной раз спорить?

Ну да, что спорить. Ясно следующее: FreeSoftware и CL слабо коррелируют =)

хотя бы Python/Ruby речь именно о том, что надо терпеть.

не надо, правда не надо.

Если сравнивать с .Net, то надо брать коммерческие реализации CL с их батарейками, платформой и поддержкой. Смотрите http://www.lispworks.com/, http://www.franz.com/