Помогите выбрать ф-циональный ЯП

Scala, использует Java VM, поэтому сразу куча библиотек и приличная скорость работы.

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=sbcl&am...

>2. Изучяемость (простота/сложность в изучении);

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

>3. Быстрое создание GUI, сетевых приложений, вобщем разнообразие набор всяких биндингов;

JVM, JRE, JDK, отсюда выбор Scala

Да... По скорости Ocaml крут получается... Вот что значит компиляция в натив.

Тока с Haskell'ом где-то на равне... Про Haskell кто чего скажет ?

Нет поддержки динамических библиотек, да и вообще мало библиотек для него:(

По "мощности" думаю всётаки Lisp всех делает...

да и биндинги к нему (Lisp) есть...

Haskel (GHC) пока не может динамической линковки. Получаются бинари в десятки мег. Скорость загрузки и потребление озы поэтому соответствующее. С либами у него вообще некоторая лажа. Вобщем, не для продакшна пока, к сожалению. Hugs - интерпретер, со всеми вытекающими.

А с ocaml'em как обстоят дела ? Вроде, смотрю, библиотек много...

Лисп (cmucl, sbcl, и другие с худшей поддержкой стандарта) тоже компилят в натив. На скорость это само по себе влияет не очень сильно, известно что _интерпретируемый_ форт рвёт многие компилируемые в натив.

Похоже неплохо но он с сильным ООП-привкусом. Я с ним практически не знаком.

На лиспе можно писать "сишный" код, который может быть быстрее самих сей. Это не тру лиспно, но зато на сях нельзя писать лиспный код :)

> известно что _интерпретируемый_ форт рвёт многие компилируемые в натив.

Откуда это известно? Какой код? Да и интерпретируемым прямой шитый код (например) можно назвать с бо-о-ольшой натяжкой. Это скорее смесь кода, данных и адресов перехода.

Это такая легенда от фортеров.

>На лиспе можно писать "сишный" код, который может быть быстрее самих сей. Это не тру лиспно, но зато на сях нельзя писать лиспный код :)

Нельзя так говорить, что это не "трулиспно". Никто же не собирается оптимизировать руками высокоуровневые конструкции. Если нужна быстрая математика, то никуда не денешься: либо использовать привязки к библиотекам через FFI (вот это как раз не трулиспно!), либо писать на Common Lisp, но с (declare (optimization ...)) и (declare (type ...)). Это очень полезно, если пишешь какое-нибудь приложение по обработке изображений или высокопроизводительный геометрический движок. Там же много функций, которые выполняются огромное число раз. Другой вопрос, что не каждая реализация CL обязана что-то оптимизировать.

А всётаки про Ocaml кто-нибудь может что сказать в практическом плане, в смысле использования. А то теорию и описание читаю, вроде ничего, а как на практике...??? И как он соотносится с Lisp'ом по тем пунктам, что я привел в начале ?

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

А на счёт Scheme, что скажешь ? Нафига он был сделан и как с Lisp'ом соотносится ?

Ocaml мне больше всех ФЯП нравится. Не такой академичный, как Haskell, быстрый нативный код (использует всякие xmm регистры, если есть), да и за 4 года от лиспа устал :) Сейчас когда пишу на Ocaml'е испытываю такую же эйфорию, как когда-то, во время написания на лиспе

> да и за 4 года от лиспа устал

А что Ocaml проще ? Или чем-то лучше ?

схема - это сильно упрощённый чисто функциональный диалект лиспа. Коммон лисп, как извесно, довольно жирный и не функциональный. Схема как мне кажется используется чаще коммон лиспа, но в более простых проектах, в сложных обычно совместно с другими наречиями. Есть например http://www.gnu.org/software/kawa/ - работает на жабьей вм.

> схема - это сильно упрощённый

Здесь "упрощённый" звучит как урезанный, лишённый многих возможностей (худший) или - наоборот оптимизированный (в смысле синтаксиса - выкинуто много лишнего), более практический и проработанный (продуманный) ?

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

> много возможностей выкинуто

а можно кратко каких _основных_ ? Я немного с CL знаком.

Scheme в силу своей элегантности идеально подходит для обучения (для чего он и был придуман). Еще неплох как встраиваемый язык для скриптов. В остальном у него проблем куча. Стандарт scheme очень скупой, каждая реализация поддерживает свой набор SRFI, большинство идет со своими нестандартными библиотеками. Binding'ов мало, потоки нормальные есть только в одной реализации (guile) итд.

http://groups.google.com/group/comp.lang.scheme/msg/b505263f820dba29

> схема - чисто функциональный

Ским не чисто фп, не как хаскилль ;)

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

>1. Скорость исполнения кода;
>2. Изучяемость (простота/сложность в изучении);
>3. Быстрое создание GUI, сетевых приложений, вобщем разнообразие набор >всяких биндингов;
>4. Развитие (комьюнити, поддержка, обновление, проекты), >переспективность.

Скажу про Python: Функциональшины там как в Лиспе, но макросов нет, и скобок меньше. По первому пункту заметно медленнее, по 2,3,4 имхо один из лучших на сегодняшний день...

Сложилось такое впечатление, что Ocaml более практический язык. Большой набор библиотек и модулей, причём "родных" (от разработчиков, искаропки :)даже графика есть, делает, как мне пока кажется, Ocaml более, чем Lisp пригодным для разработок, где нужен гуй, важна скорость как выполнения, так и разработки и т.д..... Кто чего думает ?

Ты зачем нагло врёш, родной?

> Ты зачем нагло врёш, родной?

ИМХО, человек, утверждающий, что Лисп может поднять производительность труда программиста в 100 раз, должен выражаться более мягко :D Например, "Ты немного преувеличиваешь, родной" :)

В Lisp'е меня смущает, что дополнительные возможности (гуй, сеть...) разрабатываются кучей сторонних разрабов, а не в всё в одном флаконе, как например в Ocaml'е или жабе ? Или я что-то не понимаю ? :)

А тебя не смущает что в сях, с++, и прочих то же самое? Для жабы тоже есть полно различных библиотек, разработчики которых никакого отношения к сану неймеют. Это только показатель зрелости и признанности платформы, и ничего более.

> А тебя не смущает что в сях, с++, и прочих то же самое?

Смущает. По-этому то и ищу что-то другое. Просто в жабе дофига возможностей искаропки. В Ocaml'e тож, есть группа разрабов, которые клепают либы и модули, которые точно будут работать и совместимы между собой. А в Lisp'e я читал (даж здесь на ЛОРе), часто биндинги часто не прикручиваются, или некорректно работают и т.д.... Lisp мне очень нравится, и против него ничего не имею, но надо выбрать...

Хотя, посмотрел Ocaml'евские модули, в Lispe всё (ну почти) искаропки (в самом языке), тока гуёв нет. Подскажите, что для Lisp'а попорбовать в качестве гуёв, чтоб точно работало было простенько и быстренько. На cliki.net был, там много всего, но подскажите из опыта, что лучше выбрать на попробовать ?

> Смущает

чем?

> Просто в жабе дофига возможностей искаропки.

В лиспе тоже. Практически тех же самых. Только гуя нету. А в жабе достаточно многого не хватает, приходится докачивать и устанавливать. К чести разработчиков жабы, проблем однако это обычно не вызывает.

> В Ocaml'e тож, есть группа разрабов, которые клепают либы и модули, которые точно будут работать и совместимы между собой.

Окамла, насколько мне ведомо, есть только одна имплементация. Это многое облегчает, но многое и усложняет.

> А в Lisp'e я читал (даж здесь на ЛОРе), часто биндинги часто не прикручиваются, или некорректно работают и т.д....

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

> но надо выбрать...

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

gtk-cells, здоровый монстр с большими амбициями. ИМХО достаточно перспективный. Или clg - другой биндинг к гтк, самый ИМХО безпроблемный.

> Впрочем, с майнстримными имплементациями

Где взять ? :)

> А зачем? Я благополучно пользуюсь многими

А зачем ? Я пишу на сях (без крестов) дровишки там, обмены данными и т.д. Просто появилась необходимость (заказчики хотят) гуи там всякие (меня терминал всегда устраивал), сеть и т.д. Вот и надо, сделать некоторую обвязку (склейку), где скорость особа не нужна, высокоуровневую (гуи, шмуи ....), для управления сишными модулями. К с++ стойкая неприязнь с детсва, поэтому жаба отпадает, питон тож не очень, вот и решил что-нить из ФП попробовать...

>> Впрочем, с майнстримными имплементациями

> Где взять ? :)

в дистре вестимо. CMUCL, SBCL, CLisp. Вроде в всех дистрах есь, хотябы последний и один из первых.

Попробуй tcl/tk. Возможности в метапрограммингу почти такие же как в лиспе, гуй искаропки, всё стабильно и отлажено. Мне впрочем не понравился, ибо лисп ИМХО луче.

а tcl/tk не пробовал? Если особо красоте не нужна, то самое оно, всякое ГУИ пишется очень быстро.

опередил:)

> Попробуй tcl/tk.

Хочю LTK попробовать. Tk вроде прост.

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

ИМХО с "простыми" книжками совсем луче не связываться. Они дают упрощённое, неправильное понимание предмета, после которого переучиваться сложнее чем учить с нуля.

ну так посоветуй с чего начять...

Спецификация языка и потом документация по либам. Можно перед этим sicp почитать для общего развития.

я вот собираюсь:
Common Lisp the Language, 2nd Edition 
The Common Lisp Cookbook
The Advanced User's Guide

Пока Намана ?

> документация по либам

А это чего ? Ссылку плз можешь ?

> чисто функциональный

ни разу. В языке имеются как функциональные, так и императивные черты. Хотя схема конечно более функциональный, чем CL.

> чтоб точно работало было простенько и быстренько

ltk? проще уж некуда :-)