Clojure VS Common Lisp

Наброс негодный.

Сейчас набежит love5an под анонимусом и начнётся...

Не пытался вбрасывать. Правда интересны + и - Clojure перед CL и тем же Scheme

> Не пытался вбрасывать. Правда интересны + и - Clojure перед CL и тем же Scheme

Здесь раз в неделю топик именно на эту тему, поищи поиском.

> Не троллинга ради

Угу, конечно.

http://www.linux.org.ru/forum/development/5439798

Давно не было годного вброса и толстого троллинга. Давайте поговорим на тему что лучшу Scheme или Common Lisp и почему?

http://www.linux.org.ru/forum/development/5452361

Небольшой троллинг на тему «что лучше» и в то же время тема для помощи, тем, кто хочет сделать выбор в пользу одного из ФЯ. Я свой выбор сделал в сторону Haskell, т.к. он на мой взгляд более функционально чистый и является языком с прекрасной системой типов. Вы что считаете лучше и почему?

А это кто писал?

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

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

можно реализовать функции с одним именем и разным набором аргументов

Мультиметоды это не то?

// сори, если вопросы необоснованные: Lisp не знаю вообще

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

мультиметоды - это не функции с разным кол-вом аргументов, это совсем другая вещь...

> мультиметоды - это не функции с разным кол-вом аргументов, это совсем другая вещь...

Ну, изначально вы написали

функции с одним именем и разным набором аргументов

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

поддержка коммерческая уже есть

Я вырвал «нет поддержки» из этой фразы — нет поддержки полного набора типов чисел (numeric tower), которые есть в Scheme и Common Lisp

clojure - жуткий синтаксис (этакий c++ в мире лиспа), широкие возможности для написания параллельного кода, не столь шировкие возможности для метапрограммирования, как у CL, только под jvm.
common lisp - все и так ясно. если хочется ява-машины, то в abcl недавно(с год, кажется, назад) опять стали активно комитить.

> Я вырвал «нет поддержки» из этой фразы — нет поддержки полного набора типов чисел (numeric tower), которые есть в Scheme и Common Lisp

У clojure практически все достоинства и недостатки идут из платформы.

> У clojure практически все достоинства и недостатки идут из платформы.

Из достоинств - количество java-библиотек. Из недостатков - jvm. Я все правильно понял? :)

Steps in Scala. Книжку кинуть? Судя по содержанию гл.12 «Chapter 12 introduces and analyzes the expression problem, a not so widely
known software design problem. Since its essence lies at the frontier of combining data with operations, we feel that this particular problem should be brought to the attention of a wider audience. Based on work by well-known researchers (including the creator of Scala,Martin Odersky) we build a small code library that follows
a consistent set of naming conventions in order to help us tackle the expression problem» будет тема для функционального срача

Кстати, объясните, что за expression problem?

Не пытался вбрасывать. Правда интересны + и - Clojure перед CL и тем же Scheme

Тогда - man первоисточники.

http://en.wikipedia.org/wiki/Expression_Problem - возможность расширения типов новыми функциями, и функций новыми типами... В Clojure это решается с помощью протоколов (вот хорошее объяснение - http://www.ibm.com/developerworks/java/library/j-clojure-protocols/index.html, на русском я пишу сейчас про протоколы, может быть к НГ закончу...)

В CL за счет наличия CLOS этой проблемы не наблюдается :-)

>Не троллинга ради.

Не троллинга ради. После Clojure я зарекся трогать что-либо лиспообразное и/или динамическое.

После Clojure я зарекся трогать что-либо лиспообразное и/или динамическое.

И как оно?)

>И как оно?)

Хреново. Может, я его готовить не умею... Но с одной стороны, постоянные эксцепшены, а с другой — резкая потеря управляемости после введения макросов. Все-таки в CL защит побольше, и инструментарий разнообразнее.

Хотя многое там интересно. Я бы вот с удовольствием подружил Clojure с Erlang'ом, благо средства для создания ерланговских нод на яве имеются. ИМХО друг-другу они должны подойти, уж больно просто на Clojure будет работать с ерлаговскими термами.

возможность расширения типов новыми функциями, и функций новыми типами...

А. кажется понял.

Хотя многое там интересно. Я бы вот с удовольствием подружил Clojure с Erlang'ом, благо средства для создания ерланговских нод на яве имеются.

Сейчас модно через zeromq дружить: больше 20 языков уже поддерживается...

>Сейчас модно через zeromq дружить

zmq - это хорошо, но кроме дешевой пересылки сообщений нужны дешевые воркеры.

zmq - это хорошо, но кроме дешевой пересылки сообщений нужны дешевые воркеры.

Зачем? Дешёвые воркеры - это тоже куча трейд-оффов. Для HPC, например, совершенно не годится. Эрланг с чем-то имеет смысл скрещивать как раз из-за того, что Эрланг, как язык, слаб и неудобен.

>Для HPC, например, совершенно не годится.

Есть и другие области, кроме HPC. Например, веб-приложения.

Есть и другие области, кроме HPC. Например, веб-приложения.

Несомненно. Только зачем языку, с которым Эрланг скрещивается, обязательная поддержка дешёвых тредов? :)

Действительно, не стоит с утра читать форума - все сообщения невнимательно читаются, я не заметил ключевого слова «дружить».

Почему для hpc не годится? Что за трейд-офф? Ерланг скрещивают с чем-то только, потому что он черепаха в числодробилках. На портал.асм видел 'истории успеха' связанных с hpc и ерлангом

Да пересылками сообщений --- это лишь малая часть плюшек

>Почему для hpc не годится?

Потому что для HPC воркеров должно быть столько, сколько ядер процессора, потому что задачи там ограничены скоростью процессора и/или памяти.

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

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

>> Я свой выбор сделал в сторону Haskell,

А это кто писал?

Анек в тему:
-Скажите Ржевский, правда, что в молодости вы были членом суда?
-Ах, молодость, молодость, челеном туда, челеном сюда.