Haskell - ленивый. Чистый (без императивных возможностей вообще). Есть классы типов. В общем, если хочется писать красиво - то Хаскелль - самое то. Есть Template Haskell.

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

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

Короче, всё от задачи зависит. Я использую и Haskell, и OCaml, и Common Lisp, и Scheme, всё для разных задач, но часто - всё вместе в одном проекте.

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

Звучит просто очень соблазнительно. Что важно: компилятор для виндоус также хорош, как и для С? Как на счет GUI? Как emacs справляется с OCaml? Есть ли возможность вызова С-функций из Окэмела и наоборот?

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

Еще общий вопрос. Какие типы задач более подходят для Хаскеля, Окэмэла и Лиспа? Что характерно для каждого из языков? Что именно вы решаете? Кстати, это вы?

http://www.kasamba.com/viewExpert.asp?conMemID=96244&Catid=10244&banI...

И еще вопрос от чайника: в чем принципиальная разница Лиспа и Схемы?

Принципиальная разница CL и Scheme в том, что в Scheme стандартизован только сам язык + очень скромная библиотека функций, а в Common Lisp'е эта стандартная библиотека на порядок, а то и на два, больше. В частности, она включает в себя CLOS. Для Cхемы никакого стандартного объектного расширения (пока) нет. Кроме того, Scheme -- более "функциональный" язык. Так как по стандарту обязательно требуется proper tail recursion (т.е. возможность в определенных контекстах делать неограниченную рекурсию), то там, например, вообще нет "операторов" цикла --- все через рекурсию.

Что касается компилятора для OCaml -- то в некоторых случаях он *лучше* чем компилятор C. Но кстати и некоторые компиляторы Common Lispа тоже генерят лучший код, чем C

> Я использую и Haskell, и OCaml, и Common Lisp, и Scheme, всё для разных > задач, но часто - всё вместе в одном проекте.

Хотел бы я на это посмотреть :))))))

> Кстати, это вы?

Скорее всего нет - стиль не тот.

> в чем принципиальная разница Лиспа и Схемы?

Схема - это Лисп. Точнее, один из его диалектов. Другой диалект - Common Lisp. Поэтому особо принципиальной разницы нет, просто исторически они немного разные применения нашли.

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

GUI - есть Tk и GTK, оба одинаково хорошо и красиво забинжены.

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

Счётные задачи решаются довольно таки неплохо, но, суперпроизводительности тут ожидать не следует. Я предпочитаю генерить код на Си или Фортране из программы на OCaml - то есть, использовать его для аналитических вычислений и по минимуму для численных.

По поводу более глобальной классификации задач - это тема для отдельной статьи. А то и монографии. Я такое пейсать не возьмусь, времени нет.

Про Схему - это такой минималистический диалект Лиспа. Всё в ней неплохо, только вот самое главное в стандарт (R5RS) засунуть забыли - истинные макры (defmacro в Common Lisp).

Про Касамбу - ну да, я это. В связи с некоторыми обстоятельствами вынужден набирать "репутацию"... :(

Я что, настолько примитивен, что должен придерживаться единого стиля?!?

>Для Виндовса есть кой-какие проблемы, но вроде бы нынешний mingw32-порт уже довольно приличный. У Cygwin-порта технических проблем нет, но есть проблемы с лицензией.

О! Я не знал про mingw Спасибо большое за подсказку. Классная вещь. мне очень понравилось, что можно использовать mingw прямо из cygwin, но генерить нативный код.

Что остается непонятным... Что делать с оконным интерфейсом? Есть ли какой-нибудь опыт прикручивания GUI к программе, чтобы работало и там и сям (в виндах и в юниксе)?

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

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

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

OCaml выглядит очень привлекательным, но я боюсь попасть в ситуацию, когда написанная программа окажется неперносимой или трудности с графическим интерфейсом окажутся слишком большими (то есть не смотря на преимущества языка, будет проще использовать готовые C++ библиотеки вроде wxWidgets).

>По поводу более глобальной классификации задач - это тема для отдельной статьи. А то и монографии. Я такое пейсать не возьмусь, времени нет.

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

Про дефмакро я тоже прочитал. Хм... Объясните, в чем там такая уж радость? Как я понял - это просто возможность генерировать код для выполнения. Но похожая вещь есть, скажем, в С (препроцессор). Конечно, препроцессор С - это гораздо меньше возможностей (да и язык отличается от С), но смысл очень похожий. Все же в чем особая крутизна дефмакров? Есть ли пример, когда без них нельзя обойтись. Что я не так понимаю?

>Про Касамбу - ну да, я это. В связи с некоторыми обстоятельствами вынужден набирать "репутацию"... :(

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

Вообще, круто, поискав по сети, я нашел ваш вклад и в OCaml и в другие проекты (особенно на sf.net). Респект.

>Я что, настолько примитивен, что должен придерживаться единого стиля?!?

Вы не кажетесь примитивным. Отнюдь. Однако, единство стиля тоже не говорит о примитивности.

MPI

И еще: есть ли попытки сделать какую-нибудь параллелизацию для OCaml?+

О! Нашел книжки Paul Graham: rules!!!

См. message passing движок на http://ontil.ihep.su/~vsl/ - работает как локально (с нитками), так и удалённо, через сокеты. Я на этом деле большие генетические фиты считаю...

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

Про defmacro - ну, к примеру, можно в моей статье это почитать: http://arxiv.org/abs/cs.PL/0409016