>>8622> Кстати, пользуясь случаем, а обругать OCaml никто не желает?
Вообще, эмель сдох. Никакого развития нет и не планируется. Тот же Лерой прямо писал в конфочку, что да, ГЦ окамла сосет, но ему похуй, ничего делаться не будет. А раньше раньше развитие было разным в разных реализациях, т.е. приличная оптимизация в Млтон, свежие языковые фишечки в нью-джерси или москоу, человеческое лицо в элис, в окамле - традиционнно сосание хуйцов бесплатно. Флагманской реализации так и не появилось, язык распался на диалекты. Итого, большинство реализаций и диалектов сдохли или в коме, комьюнити нет, библиотек меньше чем в хаскеле, эмелеебы переходят на хаскель хлопая дверью (могу доставить свежую сочную пасту), заглянувшие на огонек хаскелеебы охуевают от того, что в Окамле все делаешь, а ничего нет. При этом окамл позиционируется как практичный, но практичность окамла это: нет многопоточности, нет нормальных числовых типов, нет нормального ГЦ, нет нормальных оптимизаций в компиляторе, нет либ, нет инфраструктуры, нет комьюнити, на главном сайте есть надпись, что окамл - практичный язык.
Помимо пиздежа про практичность, окамлофанбои любят похвалится производительностью, но это тоже пиздежь. Идеоматический код на окамле сосет не разгибаясь, более-менее сносную производительность можно получить только написав на окамле фортраноподобную говнолапшу. Да и то, даже хаскелист, почитывающий бложек какого-нибудь дона стюарта и знающий пару ключей компилятора и настройки рантайма, имеет все шансы оставить окамлоеба глотать грязь на обочине.
Я вот тут от балды написал прикладной http сервант на ocaml, что бы несколько спустя дней сыпя проклятиями переметнуться на хаскелл, напиать от балды сервак на нем и успокоиться. Так что не все так однозначно, особенно учитывая то, что уже haskell 6.12 имеет конкурентный сборщик мусора и сам из коробки умеет использовать несколько ядер.
1) Откровенный, признанный в рассылке баг в Lwt, собранный с ним ocsigen, фикс есть, но надо почти весь окамловый мир пересобрать. Даже на ubuntu 10.10 он еще есть.
2) Если жить с этим багом, то это приводит к тому, что сервер становится блокирующим. Это вообще неприемлемо, при сколь угодно маленьких нагрузках
3) Собранный хаскеллем бинарник будет жить на любом вообще почти линуксе --- там динамические зависимости от малого количества системных библиотек. Его не поломать сменой энвайромента
4) На окамле так теоретически можно, на практике за половину дня у меня не получилось (может я тупой, но я лучше буду на хаскелле код писать, чем бодаться со сборкой и путями к библиотекам и чтением манов на ocamlfind)
5) Happstack очень хороший и он проще в использовании, чем Ocsigen, хотя и не такой пока навороченный. Но лучше все равно.
6) 90% из того, что я пишу в окамле руками, в хаскелле уже есть
7) В компиляторе хаскелла правильный подход к компиляции, к представлению значений в памяти, и люди над компилятором работают, а не занимаются черти-чем. Это значит, что момент, когда хаскелл станет уделывать окамл по вычислениям --- неизбежно наступит, это только вопрос времени. Представление чисел в Окамле --- это какой-то позор, при том, что есть SML/MLTon и Эндрю Аппель. Работа с этими числами и их типами при отсутствии тайпклассов --- это тоже позор. Так что окамл быстро работает только на 31-битной арифметике (ну или 63-битной, но я не уверен, что в 64-битной сборке примитивные типы 63-битные)
Может, в хаскелле оно вообще сейчас боксед всё, я не знаю, но динамика развития компилятора говорит о том, что это временно
8) Темпы развития компилятора и рантайма хаскелла - в нём уже есть конкурентный сборщик и масштабирование по ядрам, а не отмазки, что это все сложно и потребует больших переделок.
Работает само (на примере хаппстека). Т.е. теже драйвера HDBC --- уже сами по себе написаны в неблокирующей манере и прозрачно работают с ForkIO, а не требуют запуска в нативных тредах или переписывания, как окамле (я не говорю про качество самих драйверов еще).
В общем-то окемл -- это такое легаси для компиляции Coq. Язык так себе, практически не развивается (0.5-1 man-power на поддержке), но умеет быстрые символьные вычисления (сам Ксавье переключился бы с него на что-нить еще, было бы на что).
Кроме большей скорости на некоторых задачах и большей простоты обучения, у кемла нет никаких особых достоинств. А вот недостатков куча.
Приведенный пример еще не так страшен. Понадобилось всего две вспомогательные ф-ии (drop/takeWhile, ужасающе кривой input
list с mutlist не в счет). А вот при разработке больших проектов кемл показывает себя во всей красе -- иерархических модулей нет, автоматом они в repl не подгружаются. Мутабельность, которая по-началу местами что-то упрощает, потихоньку превращает проект в кашу. Отсутствие ленивости по-умолчанию делает всё менее модульным. Уж не говорю про отсутствие type class-ов, задания приоритетов операторов, убогие функторы. В итоге получается конечно получше, чем C++/java/c#/python (все таки замыкания, вывод типов, алгебраические типы, pattern-matching), но остаются все их проблемы связанные с неконтролируемой мутабельностью.
