Насколько я сумел заметить, обсуждение "новых",  модных в текущем квартале,
скриптовых языков программирования всегда сводится к позиционированию языка между
LISP и языками со строгой типизацией в стиле Хиндли-Милнера (Haskell, *ML).

Истинно новым всегда оказывается только синтаксис, а описание новых свойств
гордо повествует, что вот это наконец-то делается "почти как в LISP", а вот это
"почти как в Haskell".

Когда меня единожды забодало это "почти" -
почти сборка мусора, почти лексические замыкания, почти мета-объектный протокол -
я месяц выбирал между двумя языками( CommonLisp и OCaml), которые делают все не почти, 
а так как нужно, выбрал и с тех пор не загружаюсь.
 

svg, мне самому очень нравятся MLоиды, но я весьма удивлен, что OCaml попал в число двух языков, работающих «как надо», особенно если второй — Common Lisp.
Язык сам по себе хорош, но:
— Скудный выбор библиотек. Caml Humps более чем наполовину состоит из разработок в альфа-  и бета-стадии, причем многие из них оставлены авторами несколько лет назад.
— Не очень прозрачный и слабо документированный FFI.
— Метаинформация отсутствует в принципе.
— CamlP4 работает исключительно на уровне синтаксиса.
Почти уверен, что ваш выбор пал на CL и не удивлюсь, если по одной из этих причин. (Сам, увы, знаком с CL только на уровне «читаю по слогам со словарем».)
В общем, для себя я решил, что OCaml стоит использовать для compiler construction, символьных вычислений и прототипирования алгоритмов. Для всего остального даже недо-OCaml от MS F# практичнее.

Кстати, почему при выборе не рассматривался Haskell? Ленивость?


Все это появилось в Лиспе. Но я бы не стал утверждать, что по сей день является исключительно прерогативой декларативных языков.
Сборка мусора? Да, в скриптовых языках предпочитают делать ref-counting, а настоящий GC лишь рвет циклы. Но насколько критичны эти детали реализации в их use-cases?
Замыкания сегодня реализуют все, кому не лень (если кому лень, никто их насильно из каменного века не вытаскивает). Python и Ruby, по крайней мере, их поддерживают.
Что касается рефлексии, тут да, с Лиспом трудно кому-либо тягаться. Но все-таки она присутствует в современных динамических языках.

(offtop: вы на RSDN не бываете? Что-то мне ваш стиль показался знакомым…) 

Меня очень привлекала производительность OCaml при уровне абстракции языка сопоставимой с Haskell.
Очень впечатлил код MLDonkey - красивая работа,
компактный код, нетривиальная программа.

Выбрал Common Lisp я чисто из недостатка времени, прикинув, что в продуктив с CL я выйду на полгода раньше,
чем с OCaml, тк дабы успеть сделать проект в срок мне нужен был генератор CRUD в стиле RoR, а, имея макросы
и уникальную рефлексию MOP данную задачу я мог решить тривиально. 

С библиотеками в CL такая же чехарда -  почти все, что мне понадобилось, все равно пришлось дописывать/переделывать.




Меня доводило, более чем производительность, что сборка мусора на стороне FFI в Python/Perl отдавалась
на откуп программисту, те ручками. 
Постоянно сталкивался с трудноисправляемыми ошибками из-за этого, тк машина языка подразумевала одно поведение, а
кодер интерфейса какое-то иное.



Ruby - да, автор языка - известный Lisp-программист, ему было бы стыдно сделать иначе.
Python - с ограничениями/оговорками, довольно горбатое определение областей видимости. Но это следствие того,
что изначально Python проектировался простым. Нежданная популярность требует теперь делать его сложным.
В результате прикручивают к мотоциклу "Хонда" ковш эксковатора и лопату грейдера.



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

 

Характеристики - область применения на 70% состоит из soft-realtime приложений. 

Это сообщение отредактировал(а) svg - 14.5.2006, 22:15

Этого у OCaml не отнимешь. При том, что резервы оптимизации далеко не исчерпаны. Единственное, что нельзя обойти в рамках существующей реализации — тегированное представление данных, на целочисленную арифметику это сильно влияет.

Удручает то, что в последние годы INRIA не внесла ни в язык, ни в реализацию ничего существенно нового. Похвально стремление разработчиков сделать язык стабильным и пригодным для промышленного применения. С другой стороны, многие интересные проекты, такие как GCaml, JoCaml, заглохли.


Boost.Python пытается это дело до некоторой степени автоматизировать.
С замечаниями в целом согласен.


Erlang не рассматривали? Впрочем, заточенность под realtime здесь скорее всего единственное его преимущество перед CL.

Добавлено @ 22:38 
P.S. Господа рубисты, прошу прощения за перевод дискуссии на другие рельсы. Если хотите, можно попросить модераторов разделить тему. 

Предыдущая версия системы как раз была на Erlang, работала 4 года.
Работала бы и дальше, но компания Cisco внезапно упокоила поддержку
собственного протокола Tacacs в собственных продуктах.

Времени на реализацию Radius-сервера на Erlang не было, пришлось искать альтернативы.
Сначала пробовал прикрутить FreeSide, но, помаявшись
с переписыванием его Perl-скриптов, плюнул и переписал его целиком на CommonLisp,
временные затраты получились те же.

 

M Cr@$h

Беседа взята из разговора о недостаках Ruby.