Вокруг OCaml'а в интернете ходит много мифов, распространяемых недругами, некомпетентными людьми или другими читателями habrhabr.ru.
На этой странице коллектив camlunity будет мужественно развенчивать эти мифы.
-
OCaml никто не использует (см. RealWorld )
-
Для OCaml'а нет библиотек
Смотрите OCaml Forge и The Caml Hump
-
Невозможно найти программистов на OCaml + Невозможно найти вакансию, будучи программистом, специализирующимся на OCaml
Вакансии регулярно публикуются в рассылке, есть как академические, так и очень практические. Из практических, например:
По опыту, за месяц практического использования окамла вполне можно писать на нём годный, качественный код.
Кроме того, имея опыт использования окамла, вы будете писать гораздо лучший код на других языках, как менее, так и более высокоуровневых.
-
Отсутствие перегрузки операторов -- неудобно.
А вы пробовали? А синтаксис "Float.(1.2 + 3.4)" тоже пробовали? А pa_do использовали?
Автору данных строк, например, очень удобно и как бы комфортно от того, что "((a + b) - b) = a" всегда, но "((a +. b) -. b) <> a" в общем случае.
-
Haskell лучше OCaml
Для некоторых, весьма нечастых применений -- да, лучше. Про остальные же применения -- мы разрушим этот миф прямо здесь и сейчас, на ваших глазах.
- Код, который пишется, если не тратить на него кучу времени, на окамле пишется так, что работает за разумное время и с разумными O-характеристиками по используемому процессору и памяти.
- Программу обычно не нужно профилировать в поисках кода, использующего много процессора и памяти, благодаря строгой (не ленивой) модели вычислений по умолчанию. (хотя, строгая модель вычислений -- не ограничение, и всегда есть ленивые значения.)
- Профилирование программы -- это очень просто, и есть хорошее свойство языка, помогающее этому: если в программе есть значение и код дошёл до его использования, то оно уже вычислено, и все ресурсы (процессор, память, внешние ресурсы наподобие файлов/сокетов) уже использованы для его вычисления.
- Функторы помогают писать очень абстрактный код, работающий над модулями в стиле ML, чего в хаскеле нет.
- Объекты и полиморфные варианты позволяют использовать подтипизацию -- то, что в хаскеле лишь имитируется. Более того, объекты позволяют осуществлять не только подтипизацию, но и наследование поведения, что в хаскеле делается через костыли.
- Перегрузка операторов в хаскеле позволяет весьма сильно затуманить семантику кода как тем, что перегружаемые операторы в общем могут делать и делают разные вещи (в случае арифметики, например, нарушая законы математики), так и тем, что используемые операторы выбираются компилятором автоматически, без явного указания. Заметим, что type classes вполне реализуются на окамле любым удобным для конкретного применения образом: через записи, объекты, функторы, first-class modules, при этом обеспечивая явное, следовательно, более лёгкое для отладки описание алгоритма.
- Проблемы с ленивой семантикой и вводом-выводом известны программистам, использующим хаскель. Настолько, что Олег Киселёв изобрёл iteratees для надёжного ввода-вывода в хаскеле. В окамле вы можете как использовать прямой ввод-вывод, как в других языках, так и монадный ввод-вывод, так и iteratees, выбирая тот способ, который больше всего подходит текущей задаче.
- Строки, по умолчанию являющиеся ленивыми списками, содержащими символы -- отдельный fail. Конечно, это исправляемо -- все нормальные библиотеки уже умеют работать с ByteString там, где это нужно, но запах остался.
- Создание и разбор больших структур данных в памяти ленивым образом -- fail, так как частенько приводит к живым, но неиспользуемым значениям, что выражается в отъедании кучи памяти без её освобождения. Там, где в хаскеле используются бесконечные ленивые списки (для обработки потоков/сигналов, например), в окамле можно использовать значения, создаваемые стандартным модулем Stream, гарантирующим отсутствие со своей стороны ссылок на уже обработанные значения. (конечно, при необходимости эти значения можно оформить в ленивый список, создаваемый на основании этого stream, но это делается только сознательно и явно, защищая программу от неявного и бессознательного отъедания памяти.)