Минусы OCaml-а

> Какие у него есть минусы?

http://www.podval.org/~sds/ocaml-sucks.html

> Один я уже углядел, preemptive многопоточность.

Ты первый, кто упоминает этот недостаток %)

сообщения об ошибках у него не адекватные: если опыта мало, то они совешенно не информативны

> сообщения об ошибках у него не адекватные

Говорят, это общая беда всех языков с type inference.

Нет макросов, а CamlP4 не всегда помогает.

Самый главный с моей точки зрения минус OCaml - отсутствие классов типов как в Haskell.

> сообщения об ошибках у него не адекватные: если опыта мало, то они совешенно не информативны

Я бы не сказал, что совсем уж не адекватные, ну и да, при определенной сноровке, это совсем не проблема.

> Нет макросов, а CamlP4 не всегда помогает.

CamlP4 вполне себе неплох. Вот если бы были классы типов (что позволяло бы не делать различия например между "+", "+." и "+/") или просто доступ на уровне CamlP4 к информации о типах, было бы вообще не особо хуже, чем в lisp.

Все вышеперечисленное - мое ИМХО.

имхо ocaml вполне неплох. лично мне не очень нравится его marshal и завязка на свои сишные либы, но в остальном -- вполне себе.

Минусы:

- Генерация кода в рантайме - только в байткодовой версии, нативно компилируемая этого не поддерживает.

- Однопроходное метапрограммирование с CamlP4. Тот же MetaOCaml, опять таки, работает только с байткодовой версией.

- Не дружит с динамической линковкой, совсем.

- Нет continuations (иногда это серьёзный минус).

> http://www.podval.org/~sds/ocaml-sucks.html

Там все минусы сводятся к тому, что OCaml это не Лисп. :)

> Говорят, это общая беда всех языков с type inference.

Есть такая партия: Helium. Очень неплохо в этом направлении поработали, правда, заплатив страшную цену: почти половина кода компилятора - это всякие эвристики для вывода сообщений об ошибках.

> Однопроходное метапрограммирование с CamlP4

Это не очень большая проблема ИМХО.

> Не дружит с динамической линковкой, совсем.

Откровенная неправда.

> Нет continuations (иногда это серьёзный минус).

http://okmij.org/ftp/Computation/Continuations.html#caml-shift :)

>> http://www.podval.org/~sds/ocaml-sucks.html

> Там все минусы сводятся к тому, что OCaml это не Лисп. :)

Ну не все, не все. То, что это написано безумным лиспером, не должно вводить нас в заблуждение :)

>> Говорят, это общая беда всех языков с type inference.

> Есть такая партия: Helium

Это хорошо, что работа ведется, но в стандартных компиляторах (Haskell, Ocaml) этого пока нет.

P.S. ИМХО, лучше бы (опционально) позволяли указывать типы явно :)

> Это не очень большая проблема ИМХО.

Как выше говорили, это не очень проблема, когда есть классы типов. Единственное, что тут жизнь облегчает, это функторы.

> Откровенная неправда.

Пруфлинк. Была не очень полноценная (и очень неоффициальная) поддержка компиляции динамических библиотек под win32/ia32 и linux/ia32, и она не то чтоб хорошо работала. Товарищ Лерой вообще был против любых попыток реализации подобной функциональности.

> P.S. ИМХО, лучше бы (опционально) позволяли указывать типы явно :)

А что, кто-то это запрещает?!?

let f (i : int) = i * i

> А что, кто-то это запрещает?!?

Я чайнег, только начал учиться.

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

Полезный совет: ocamlc -i выведет аннотации типов всех определений в файле. Ещё полезный совет - не лениться писать .mli, можно даже сначала использовав для этого ocamlc -i, но потом поддерживать руками и исправно комментировать.

> Пруфлинк. Была не очень полноценная (и очень неоффициальная) поддержка компиляции динамических библиотек под win32/ia32 и linux/ia32, и она не то чтоб хорошо работала.

Не оно: http://alain.frisch.fr/natdynlink.html ?

"The natdynlink branch has been merged to the trunk of OCaml's CVS (HEAD branch)"

> Пруфлинк. Была не очень полноценная (и очень неоффициальная) поддержка компиляции динамических библиотек под win32/ia32 и linux/ia32, и она не то чтоб хорошо работала. Товарищ Лерой вообще был против любых попыток реализации подобной функциональности.

Вообще это было по поводу "совсем не дружит с динамической линковкой".

http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html, секция "18.1.4 Dynamically linking C code with Caml code".

http://caml.inria.fr/pub/docs/manual-ocaml/libref/Dynlink.html - правда только байткод.

> Вообще это было по поводу "совсем не дружит с динамической линковкой".

Имелась в виду динамическая линковка с нативным кодом, сгенерённым самим OCaml.

> Не оно: http://alain.frisch.fr/natdynlink.html ?

Нет, это что-то новенькое. Спасибо за наводку. Не видел ранее.

Я говорил о патче Malc-а, который одно время в AltLinux из коробки шел, там не собственный загрузчик использовался, а dll/so. Однако вариант с собственным загрузчиком явно выгоднее.

Похоже, в следующем релизе этот минус можно будет вычёркивать, что не может не радовать.

От себя добавлю: несколько лапшеобразный синтаксис с уклоном в write-only иногда бесит, нету нативного юникода, память кушает заметно больше чем Си

руками писать .mli - это большой шаг назад в эпоху .h

Ну, синтаксис там всё ж получше чем у C-style, причём заметно так получше. Никакого write only не наблюдается, всё очень читабельно, и какой либо "obfuscated ocaml contents" даже не представляется возможным.

Юникод - это да, жопа, но есть для него и костыли. С памятью - IMHO гониво.

Нет. Это правильная модульность.

Вообще, по хорошему, надо СНАЧАЛА писать .mli с комментариями, а потом реализацию.

Нехватает очень классов типов (а родное ООП там вообще не пришей кобыле хвост). Синтаксис в лучших традициях перла и руби, довольно бессистемный, с непривычки глаз сломаешь, даже хаскель понятнее. Revised синтаксис, по-моему, ещё хуже, он понятнее для компилятора, но не для человека.

Зато сам язык довольно простой и жизненный, в сравнении с хаскелем, который давно переплюнул даже C++ по количеству лишних сущностей и неочевидной магии.

Постепенно склоняюсь к мысли, что идеальным языком для меня был бы хаскель без принудительной ленивости, с инетересом жду, пока допилят Disciple.

> СНАЧАЛА писать .mli с комментариями, а потом реализацию.

Вы, уважаемый, так скоро и до UML договоритесь.

Ручное дублирование информации = анальное рабство.

> довольно бессистемный

Это как это? Синтаксис тупой и простой как грабли. Я не представляю, в какую сторону его следует улучшать для большей читабельности.

> с непривычки глаз сломаешь

Пример в студию. Это важно.

> Вы, уважаемый, так скоро и до UML договоритесь.

В UML, как и вообще в высоких уровнях абстракции, нет ничего плохого.

> Ручное дублирование информации = анальное рабство.

Дублирование информации = дополнительный уровень защиты, во первых, и дополнительное документирование во вторых.

mli - это спецификация, как модуль должен выглядеть.

P.S. У меня есть подозрение, что ты никогда ничего больше 10kloc не писал, и никогда не работал в команде.

> Это как это? Синтаксис тупой и простой как грабли. Я не представляю, в какую сторону его следует улучшать для большей читабельности.

Перлист штоле?

> Перлист штоле?

Ну скажи, что общего у всяких там perl и APL с ML?

Я требую примера синтаксиса, который якобы "непонятный" и якобы "write only".

Синтаксис многословный. Чрезмерно.

Почти нет бесконечных структур (только периодические).

Отсутствие бескостыльной ленивости и умолчальной рекурсивности.

Не хватает ad-hoc полиморфизма.

ИМХО, допущение произвольных сайд-эффектов - не есть гуд.

В плюсах - хорошая система модулей и функторов, в Хаскеле что-то подобное появилось лишь недавно и пока остаётся оччень экспериментальной фичей.

> У меня есть подозрение, что ты никогда ничего больше 10kloc не писал

Ты считаешь это признаком непрофессионализма?..

// другой анонимоус

> Синтаксис многословный. Чрезмерно.

Ну да, у haskell немного почище, но не сказал бы, что чрезмерно.

> Почти нет бесконечных структур (только периодические).

> Отсутствие бескостыльной ленивости и умолчальной рекурсивности.

Что значит почти нет? Бескостыльная ленивость - это ленивость по умолчанию? Кстати, по поводу бесконечных структур, может вам синтаксическое расширение дать для lazy lists + lazy lists comprehension? А то я когда-то писал, вполне удобоваримо.

> ИМХО, допущение произвольных сайд-эффектов - не есть гуд.

Это уже на вкус и цвет.

> С памятью - IMHO гониво.

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

> Ты считаешь это признаком непрофессионализма?..

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

Конечно, 10kloc на OCaml, это аналог по функциональности 100kloc на Java, потому я такое число и взял.

Что там ковырять? Обычные tagged unions. Никакой прожорливости.

Ну прикинь сколько памяти займет double в Си и float в Ocaml с учетом всей "обвязки"

> Ну прикинь сколько памяти займет double в Си и float в Ocaml с учетом всей "обвязки"

Burbaka, а одиночных float-переменных мало, а в массиве они хранятся 'как есть'. Так что оверхед по памяти в данном конкретном случае отсутствует.

> Так что оверхед по памяти в данном конкретном случае отсутствует.

Точнее он очень мал.

А на кой тебе одиночный float хранить со всей обвязкой? Он и в Си до хера места занимает, если его malloc-ом выделить.

Справедливости ради нужно сказать, что описываемаю тобой проблема имеет место с int32/int64.

В массивах - да, потому как для этого специальных хак предусмотрен, а в структурах, в тьюплах и т.д. ? 

Вот типичный пример работы с кортежем из Си

CAMLprim value
inspect_tuple( value ml_tuple )
{
    CAMLparam1( ml_tuple );
    CAMLlocal3( vi, vf, vs );

    vi = Field(ml_tuple, 0);
    vf = Field(ml_tuple, 1);
    vs = Field(ml_tuple, 2);

    printf("%d\n", Int_val(vi));
    printf("%f\n", Double_val(vf));
    printf("%s\n", String_val(vs));

    CAMLreturn( Val_unit );
}

Где Field и Double_val следующие макры  (взято из mlvalues.h)

#define Field(x, i) (((value *)(x)) [i])
#define Double_val(v) (* (double *)(v))

Если я все правильно понимаю, то на каждый double в тьюпле и структуре получаем лишние 4 байта. Размер double = 8, размер указателя = 4 => получаем 50% оверхед :) Или я где-то неправ ? 

Неправ в том, что float-ы никто по структурам не развешивает, ибо не фиг.

И по спискам и по тьюплам :) Недостаток есть - факт, а пользуется ли кто-нибудь этой возможностью или нет - вопрос надцатый

Это не недостаток, это tradeoff. За то, что длинные типы данных всегда boxed, мы получаем очень простой и от этого очень быстрый gc. Если бы структура тупла была бы сложнее, GC работал бы медленнее. Заметно медленнее. А так у программиста всё равно есть возможность оптимизировать расход памяти, и при этом гарантированна качественная работа GC.

А ну да, забыл - еще и целочисленная арифметика поторомознее сишной будет :)

Обратно же трейдофф. Плата за быструю работу с памятью.

> Это не недостаток, это tradeoff.

"наши недостатки продолжения наших достоинств" (с)

> . А так у программиста всё равно есть возможность оптимизировать расход памяти, и при этом гарантированна качественная работа GC.

Мне надо сассоциировать с каждой вершиной некоторой ссылочной структуры данных double - значение. Доступ должен быть от известной вершины, к соответствующему double-значения. Как, например, такое оптимизировать ?

> А ну да, забыл - еще и целочисленная арифметика поторомознее сишной будет :)

Нет, ну это уже слишком :) Язык повысокоуровневей C все же будет.

> Нет, ну это уже слишком :) Язык повысокоуровневей C все же будет.

Тема называется "Минусы OCaml-а". Я их просто перечисляю :)