Почему OCaml не более популярен?

86

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

С другой стороны, языки ML являются функциональными языками, предназначенными для сбора мусора, и у OCaml даже есть объектная модель, но они имеют репутацию такой же быстрой, как и языки C. В языках ML есть абстракция, которую любой может попросить написать высокоуровневый, лаконичный код, но он сохраняет скорость, необходимую для написания высокопроизводительных приложений.

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

Это субъективный вопрос, но почему другие языки OCaml и ML так неясны, в то время как C и другие языки стали популярными?

Джульетта
источник

Ответы:

82

Первый ответ заключается в том, что никто не знает, почему языки становятся популярными, и любой, кто говорит иначе, заблуждается или имеет повестку дня. (Часто легко определить, почему язык не становится популярным, но это другой вопрос.)

С этим отказом от ответственности, вот некоторые пункты, которые наводят на мысль, самые важные сначала:

  • Первый зрелый компилятор C появился в 1974 году; первый зрелый компилятор OCaml появился в конце 1990-х годов. У С 25-летний форвард.

  • C поставляется с Unix, который был самым большим «убийственным приложением» всех времен. В течение долгого времени в каждом отделении CS в мире должен был быть Unix, а это означало, что у каждого инструктора и всех, кто прошел курс CS, была возможность познакомиться с C. OCaml и ML все еще ждут своего первого приложения-убийцы. (MLdonkey это круто, но это не Unix.)

  • C так хорошо заполняет свою нишу, что я сомневаюсь, что никогда не будет другого языка низкого уровня, посвященного только системному программированию. (Чтобы увидеть доказательства в пользу, прочитайте статью Денниса Ричи об истории C из HOPL II.) Даже не ясно, какова ниша OCaml, и ниша Стандартного ML только немного яснее. Таким образом, у Caml и ML довольно много конкурентов, в то время как C убил своего единственного конкурента (BLISS).

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

  • C - это язык со стандартом и множеством компиляторов. OCaml - это программный артефакт: единственный компилятор из одного источника, а компилятор является стандартом. И этот стандарт меняется с каждым выпуском. Для людей, которые ценят стабильность и обратную совместимость, язык с одним источником может представлять неприемлемый риск.

  • Любой, кто имеет достаточно приличный курс по компиляции для студентов и много настойчивости, может написать компилятор C, который более или менее работает и с достаточной производительностью. Чтобы внедрить OCaml или ML с нуля, требуется гораздо больше образования, а для получения сопоставимой производительности с наивным компилятором C требуется гораздо больше работы. Это означает, что гораздо меньше любителей увлекаться такими языками, как OCaml, поэтому сообществу сложнее выработать глубокое понимание того, как его использовать.

Норман Рэмси
источник
5
OCaml - относительно недавний диалект ML, родившийся примерно в то же время, что и Java. Однако ML восходит к 1973 году с первым основным диалектом, SML разрабатывается в 1978 году. Диалекты ML нашли свою нишу в доказательстве и исследовании теорем, но с тех пор стали отраслевым стандартом в финансовых учреждениях.
Джульетта
15
Я бы не назвал ML «отраслевым стандартом в финансовых учреждениях». (И я не говорю этого, потому что я пишу финансовые приложения на Haskell. :-)) В коммерческом мире, хотя финансовая индустрия, вероятно, имела гораздо большее восприятие функционального программирования, чем любая другая, она все еще не так широко используется : по моему опыту, C ++ и Java доминируют. Такие компании, как Джейн Стрит, являются исключением, а не правилом.
8
Perl - это «программный артефакт» - единственное определение Perl - это «язык, который интерпретирует perl (1)», и все же он довольно популярен. Python и Ruby долгое время были «программными артефактами».
5
@Chris: IMO, это одна из причин того, что Perl теряет разум.
Норман Рэмси
5
Что касается предсказуемости, я думаю, что OCaml на самом деле превосходит C в этой области, с уровнем оптимизации, который ожидается от компиляторов C, и хрупкостью многих из этих оптимизаций. Компилятор OCaml очень буквально знает, во что он компилирует ваш код.
63

Я думаю, что проблема с OCaml заключается в том, что он не слишком полезен "из коробки". Возможная причина, по которой люди используют язык, заключается в том, что в нем есть нужные им библиотеки. Однако, не имея ничего «из коробки», никто не заходит достаточно далеко в проект, чтобы понять, что им нужно написать библиотеку. В результате получается язык без библиотек, что затрудняет написание «настоящих приложений».

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

(Я знаю, что в настоящее время ведется работа по изменению этого, с такими проектами, как «Батареи включены». Вернитесь сюда через 5 лет, и, возможно, OCaml станет более популярным.)

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

Результатом стала популярность. Деньги могут решить много проблем.

На функциональной языковой арене мы видим, что Haskell становится довольно популярным. Я думаю, что большая часть популярности связана с такими людьми, как Доны, которые пишут полезные библиотеки и никогда не прекращают маркетинг языка. Каждый день вы видите несколько статей на Haskell по программированию Reddit. Это удерживает его в сознании людей, пока они наконец не решат: «Я собираюсь попробовать Хаскелл». Когда они это делают, они видят полезные вещи, такие как веб-платформы, объектные базы данных, библиотеки OpenGL и библиотеки обработки XML. Это означает, что они действительно могут сделать что-то полезное «прямо сейчас». Таким образом, между потенциалом продуктивности и большим слухом, Haskell приобрел большую популярность.

CL имеет много тех же библиотек, что и на Haskell, и работает почти так же быстро, но никто не говорит об этом, поэтому он «чувствует себя мертвым». Действительно, #lisp намного тише, чем #haskell, но Lisp по-прежнему очень продуктивный язык с большим количеством библиотек. Ни один другой язык не имеет SLIME. Но маркетинг очень важен, и Haskell делает это лучше, чем Lisp или OCaml (и конкурирует за ту же базу пользователей).

Наконец, некоторые люди никогда не «начнут» программировать, поэтому нарушение их ментальной модели (переменные - это поля со значениями, код выполняется сверху вниз) гарантирует, что они не будут использовать ваш язык. Программисты этого типа составляют значительную долю населения, занимающегося программированием, поэтому это дополнительно ограничивает возможную пользовательскую базу абстрактных языков, таких как Lisp, Haskell и OCaml.

jrockway
источник
45
Это было возможно правда 10 лет назад. Дайте мне знать, когда я смогу "установить cabal" библиотеку OCaml. В любом случае, просто потому, что я сказал что-то плохое о ваших любимых языках, не значит, что вы должны перестать его использовать. Так что не нужно быть эмоциональным.
5
Нет, я имел в виду программирование в целом. Если вы не можете понять функциональное программирование, вы, вероятно, не можете понять и другие концепции.
8
Я не покупаю это. У OCaml есть много библиотек для основных повседневных задач программирования, и если бы он стал более популярным, люди писали бы больше. Каждый язык начинался с нескольких библиотек.
8
Как насчет ссылки на эти библиотеки?
4
Почему более 0 человек проголосовали за того, кто утверждает, что у языка нет используемой хэш-таблицы? Я не могу вынести языки, которые создают бесполезную ерунду, такие как регулярные выражения и словари в них, язык должен быть максимально отделен от библиотек, чтобы сдерживать критическое значение TCB. Язык, который полагается на словари, чтобы сделать что-нибудь, - полная чушь.
Longpoke
22

Мне нравится OCaml много как язык. НО...

Поддержка инструментов просто не существует. Отладчик работает только нормально, но не работает с окнами (последний раз я проверял), и для него просто не так много инструментов разработки.

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

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

Объектная модель выглядит несколько привязанной, и стандартная библиотека почти не использует ее, вместо этого выбирая библиотеки на основе модулей.

Есть много других вещей, которые в основном сводятся к тому, что язык не чувствует себя «отполированным», и это отталкивает людей в очень критический период, когда они выбирают язык и пытаются решить, нравится ли он им или нет.

Я думаю, что его наиболее важным наследием будет то, что он, наряду с другими диалектами ML, оказал очень сильное влияние на другие функциональные языки. Большинство функциональных языков текущего поколения берут лучшие элементы из диалектов ML и устраняют некоторые неудобства.


источник
3
Я бы не сказал, что система типов слишком сильная, но недостаточно выразительная, класс типов аля Haskell очень помог бы.
2
Да, но большинство этих комментариев о том, как не чувствовать себя обманутым, применимы еще сильнее к C ++! Я чувствую, что это немного ослабляет ваш аргумент (хотя я с этим согласен).
Yttrill
2
Отладчик OCaml - единственный, который я знаю, который может делать шаг назад и вперед.
ocodo
21

Встраиваемые системы часто требуют двух вещей: скорость и детерминизм. OCaml может обеспечить скорость, но тот факт, что он имеет сборщик мусора, делает его по сути недетерминированным, а для системы реального времени это просто не сработает.

ctacke
источник
1
Конечно, но Java и PHP популярны, и вы не можете использовать их во встроенных системах. Удобство использования во встроенных системах не оказывает большого влияния на популярность языка.
3
Первоначальный вопрос касался встроенных систем, поэтому я привел конкретную причину, по которой он может не использоваться. И как примечание вы можете использовать Java - только не для реального времени (то же самое относится и к C #).
2
Сама Java не в реальном времени. Ничего с механизмом сборки мусора быть не может.
3
@ctacke: Это просто неправда. Есть много сборщиков мусора в реальном времени. Реализации Java используют их, а Java используется в приложениях реального времени.
Джон Харроп
18

Это немного сравнение яблок с апельсинами. OCaml - довольно молодой язык [1], и никогда не было серьезных, постоянных усилий, чтобы продвинуть его в мейнстрим (исключая текущую работу Microsoft с F #). В отличие от C, это не лингва франка самой широко поддерживаемой и имитируемой операционной системы предприятия (например, UNIX). В отличие от Java, крупная корпорация не выдвигала его как вычислительную платформу следующего поколения. В отличие от Perl, Python и Ruby, он не занял влиятельную, влиятельную нишу (т. Е. Его ниша - язык программирования и автоматическое исследование рассуждений - не очень громкий по сравнению с веб-разработкой). Следовательно, это не супер-популярно.

[1] Справедливости ради, оригинальный язык ML существует с 70-х годов. Но OCaml появился только в 1996 году и не наследовал библиотеки Standard ML. На практике это более молодой язык, чем C, C ++, Java, Python, Haskell или даже Ruby.

Крис Конвей
источник
Согласно Википедии, ML не намного моложе, он всего на год младше (1972 для C против 1973 для ML). Остальная часть твоего объяснения мне кажется правильной на деньги.
1
Да. Я бы встречался с C в конце 60-х и ML - в начале 80-х (и OCaml, в частности, в конце 90-х ... моложе, чем Java, Python и даже Ruby), но, думаю, я немного не в себе.
ML датируется 1973 годом, OCaml - 1996 годом.
ocodo
15

Сообществу OCaml не удалось разработать большую и надежную стандартную библиотеку (помимо того, что поставляется с OCaml сегодня), которая облегчает разработку приложений. Есть несколько попыток решить проблему, но просто взгляните на Python или Ruby, чтобы увидеть, чего не хватает. OCaml - отличный язык, если вы хотите решить алгоритмическую проблему, которая не зависит слишком сильно от необходимости взаимодействовать с продвинутыми стандартными модулями, такими как XML, сетевые технологии, вычисления данных и т. Д., Которые вы бы предпочли не реализовывать самостоятельно.

Я считаю, что отчасти проблема заключается в том, как модули OCaml сопоставляют модули с файлами: концептуально все файлы * .ml находятся в одном пространстве имен, а каталоги не имеют смысла. Это затрудняет развитие библиотеки для сообщества. Если бы компилятор отобразил иерархии каталогов в иерархии модулей, я бы увидел больше шансов на развитие стандартной библиотеки. Это, однако, потребует значительных усилий со стороны разработчиков ядра компилятора. (Я знаю об упаковке модулей, но я думаю, что это кладжа.)

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

Кристиан Линдиг
источник
действительно хороший момент
cnd
11

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

Мне показали ML и Smalltalk примерно в одно и то же время. Smalltalk выглядел чертовски круто, и сразу стало понятно, для чего нужен ОО и как вы можете создавать красивые, интерактивные вещи в этой среде. ML был об абстрактных математических вещах, которые не имели отношения к тому, что я хотел сделать. И, в отличие от C, не обещал мне писать быстрые игры на 16-битных микросхемах.

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

В эти дни я думаю, что вопрос будет таким: теперь я чувствую, что мне нужно знать эту странную и запутанную теоретическую информацию о типах, почему я бы выбрал ML вместо Haskell или Erlang?

Interstar
источник
Ну, вы можете выбрать Haskell вместо ML, потому что Haskell, во многих отношениях, просто улучшенный ML. Почему вы выбрали бы Erlang вместо того, чтобы я не уверен: Erlang не является статически типизированным, и, как для меня, после некоторого разочаровывающего опыта с этим, я бы взял ML над этим в любой день.
В 1996 году в Кембриджском университете меня обучали Стандарту ML, и он мне не очень понравился, потому что все примеры были теоретической информатикой (а я физиком), а также потому, что его реализации не работали (когда я жаловался, они дали мне 100kLOC исходного кода компилятора ML). это даже не скомпилировано и сказал мне, чтобы исправить это сам). Я выбрал OCaml после того, как защитил докторскую диссертацию, и обнаружил, что он гораздо более жизнеспособен. Что касается ML против Haskell / Erlang, это зависит от того, какой ML. OCaml, очевидно, обладает множеством функций, которых нет у Haskell и Erlang. Более того, эти функции оказываются существенными на практике.
Джон Харроп
9

Я считаю, что основной проблемой является отсутствие актуальной стандартной библиотеки. Следовательно, проект OCaml Batteries Included , который, как ожидается, в значительной степени улучшит ситуацию. Он должен вступить в бета-фазу в течение нескольких дней, поэтому вам придется снова задать вопрос через год или около того.


источник
10
Два года спустя OCaml не кажется более популярным.
5
Четыре года спустя OCaml не кажется более популярным.
Камило Мартин
8

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

Кроме того, люди, которые знают такие языки, как OCaml, чрезвычайно разнородны. Среди веб-программистов, возможно, 1 из 1000 слышал об OCaml. Среди людей, занимающихся научными вычислениями в Кембриджском университете, около 90% людей, которых я знал, свободно говорили на OCaml. Действительно, я был одним из последних среди моих друзей, которые изучали OCaml. Мы даже запускали OCaml на нашем суперкомпьютере с 256 процессорами ...

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

Джон Харроп
источник
"крутая кривая обучения": сколько времени нужно, чтобы освоить C ++, начиная с 0? Я думаю, что если бы OCaml был более популярным, больше людей сочли бы нормальным приложить усилия для его изучения.
Джорджио
@ Джорджио «Я думаю, что если бы OCaml был более популярным, больше людей сочли бы нормальным приложить усилия, чтобы изучить его». Я думаю, что все больше людей изучают Python и Ruby, потому что их сравнительно легко выучить.
Джон Харроп
Конечно, люди предпочитают изучать языки, которые проще (кстати, я не думаю, что Ocaml намного сложнее, чем Ruby и определенно менее сложен, чем C ++), дело в том, что когда язык становится популярным / популярным, тот факт, что он сложный, больше не рассматривается как большая проблема. OCaml не пользуется популярностью, и поэтому люди не думают, что его стоит изучать.
Джорджио
Я согласен, за исключением того, что я определенно воспринимал сложность C ++ как серьезную проблему, и я думаю, что большинство людей, с которыми я встречался, тоже были в этом убеждены. В частности, сложность программного манипулирования кодом C ++ - огромная потеря возможностей.
Джон Харроп
Я нахожу ваше утверждение: «Среди людей, занимающихся научными вычислениями в Кембриджском университете, около 90% людей, которых я знал, свободно говорили на OCaml». очень удивительно. Как физик, который много занимается моделированием, я видел, как коллеги используют много разных языков: C, C ++, Fortran, Java, Python, Perl, MATLAB, Mathematica, R и другие. Но я никогда не видел, чтобы кто-нибудь использовал OCaml. Я слышал, как люди говорили о том, что, может быть, изучают это, но я никогда не видел, чтобы кто-нибудь использовал это . Поиск на scicomp.stackexchange.com снова ничего не дает. Ваш адвокат для этого использования ML сделал ...
Szabolcs
6

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

Когда я начал учиться в университете, я уже знал достаточное количество BASIC, C ++ и Java и немного ассемблера Pascal и x86. Я был далеко не экспертом, но пришел к (слегка наивному) выводу, что все языки программирования в основном одинаковы с немного отличающимся синтаксисом. Наше введение в курс программирования использовало ML, который быстро отвлек меня от этого понятия. Мне было трудно разобраться с ML на этом этапе моей карьеры программиста, и я не видел смысла в функциональном программировании. Я думаю, что требуется немного больше опыта с некоторыми проблемами процедурного программирования, чтобы по-настоящему оценить преимущества функционального подхода.

Наш лектор ML часто утверждал, что рекурсивное выражение проблем было более «естественным» и более простым, чем использование циклов или других процедурных концепций. Я никогда не был убежден этим требованием и все еще не покупаю это. Рекурсивные функции могут иногда обеспечивать особенно элегантные и лаконичные решения проблем, но я все еще нахожу это неестественным способом думать о проблемах. Возможно, если у вас очень сильный математический фон, он кажется более интуитивным, но я не думаю, что большинству людей легко рекурсивно мыслить. Учитывая центральное значение рекурсивных функций для парадигмы функционального программирования, я думаю, что это также может быть причиной меньшей популярности функциональных языков.

Существует также эффект обратной связи с популярностью языка. Когда я начал программировать, я хотел знать, как программировать графические эффекты и игры. Изучив немного BBC BASIC, а затем QBASIC, я, естественно, исследовал, какие наиболее распространенные языки использовались разработчиками демо-сцен и игр, и приступил к изучению ассемблера C ++ и x86. В настоящее время некоторые новые программисты могут захотеть узнать, как создавать веб-приложения, и поэтому будут стремиться к изучению PHP, Ruby или C #. Существует очень мало областей применения для начинающих программистов с самостоятельной мотивацией, где ответом на вопрос «Какой язык лучше всего научиться программировать что-то вроде X» будет «Ocaml».

Многие практические причины ограниченной популярности Ocaml (отсутствие зрелых библиотек, отладчиков, IDE и т. Д.) Устранены официальной поддержкой Microsoft F # как первоклассного языка .NET. Будет интересно посмотреть, поможет ли F # повысить уровень популярности функционального программирования.

mattnewport
источник
Рекуррентные отношения - это одна из тех вещей, которые всегда хорошо отображаются в FP.
Джон Харроп
3
«Для большинства людей функциональное программирование просто не является естественным способом мышления»: структурированное программирование не было для меня естественным способом думать, пока я программировал на Basic. Затем я переехал в Паскаль. Объектно-ориентированное программирование не было для меня естественным способом думать, пока я программировал на Pascal и C. Затем я перешел на C ++ и Java. Функциональное программирование также показалось мне странным, пока я не начал изучать Haskell и другие языки FP, а теперь C ++ выглядит так неловко для определенных задач. :-)
Джорджио
6

Я считаю, что суть проблемы - это политика. Разработчики Ocaml в основном заинтересованы в исследованиях и не имеют ресурсов, чтобы обеспечить и поддерживать богатую библиотеку. Однако они также не хотят передавать контроль над продуктом сообществу, у которого есть эти ресурсы, в результате чего несколько попыток решить эту проблему основывались на несуществующем сотрудничестве и финансировании сторонних библиотек, и эти попытки не увенчались успехом. Батареи выйдут из строя по той же причине, если разработчики Ocaml не изменят свое отношение.

Я использую Ocaml для разработки своего продукта, и у меня есть простое правило: минимизировать зависимость от стороннего кода. Если полезен сторонний продукт, если это вообще возможно, включать исходные коды непосредственно в пакет. Например, OCS Scheme и Dypgen являются неотъемлемой частью синтаксического анализатора Felix, поэтому они скопированы в наши источники, поэтому мы имеем некоторый контроль над ними. Управление несколько иллюзорно (поскольку Dypgen, по крайней мере, настолько сложен, что вряд ли мы сможем его сохранить, но, по крайней мере, у нас есть копия, которая, по нашему мнению, работает :)

Я не буду использовать батареи, потому что лицензия ограничена, поэтому я не могу скопировать источник, и я не верю в его долговременную жизнеспособность как отдельного продукта: единственный способ, которым я мог бы использовать его, - это если бы он был включены непосредственно в стандартный дистрибутив Ocaml.

В мире C ++ я мог бы просто рассмотреть возможность использования Boost: хотя это сторонняя библиотека, не входящая в стандарт, она имеет такую ​​мощную поддержку сообщества и фактически превосходно синхронизирована с процессом разработки стандартов. Идеи, разработанные и протестированные в Boost, становятся разновидностью существующей практики, которую можно стандартизировать, а процесс разработки стандартов достаточно открыт, чтобы обеспечить участие сообщества.

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

Yttrill
источник
5

Я наслаждался кодированием в ML и C для самых разных проектов. То, что мешает мне использовать ML во встроенных проектах (большинство из которых имеют ограничения в реальном времени и требуют проверки), это сборка мусора.

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

Дуг Керри
источник
3

ИМХО, я думаю, что большая проблема OCaml не в языке (это здорово), а в людях, которые его разрабатывают и, как следствие, в его лицензии:

http://caml.inria.fr/ocaml/license.en.html

Они используют лицензию Q Public для компилятора! Да, лицензия ex-Trolltech используется для библиотек Qt! Забудьте о получении любого вклада с такой лицензией.

Если вы проверяли Language Shootout ( http://shootout.alioth.debian.org/ ) около 7-8 лет назад, OCaml отставал от C и C ++ по скорости выполнения. В то же время другие языки (например, Haskell) получили лучший компилятор (из-за другого подхода сообщества, я полагаю), и теперь скорость выполнения OCaml не так велика, как в прошлом.

Короче говоря, я бы не стал использовать OCaml, потому что я не вижу, чтобы он шел куда-то лучше без каких-то действительно хороших хакеров, создающих компилятор OCaml, который имеет ДЕЙСТВИТЕЛЬНО лицензию с открытым исходным кодом и сообщество с ДЕЙСТВИТЕЛЬНО поведением с открытым исходным кодом.

Патрицио Рулло
источник
Некоторое время назад в списке рассылки обсуждалась, казалось бы, низкая производительность OCaml в языковой перестрелке. Удивительно, но в C-подобных языках разрешено использовать нестандартные распределители памяти, в то время как языкам, собирающим мусор, не разрешается настраивать свои собственные сборщики мусора ... И настройки по умолчанию в IIRC OCaml для современных процессоров были немного отключены.
bltxd
3

Хорошо, если речь идет о деньгах, как говорит @jrockway, посмотрим, получит ли F # популярность, как java или C #.

Для меня, я думаю, разработчики не чувствуют себя комфортно с функциональным способом работы (это из сессии F # в techdays 2009, где около 10 человек сказали, что знают функциональное программирование среди почти 100 человек).

Я запустил OCAML в этом году, я никогда не пачкал свои руки функциональным программированием, но теперь я действительно всегда учусь новым вещам из OCAML и функциональному способу решения проблем (но я не могу сказать, что откажусь от C # использовать OCAML :)).

0xFF
источник
10 лет назад это было бы больше, чем 1 из 100 человек, знающих FP. ;-)
Джон Харроп
2

Ну, может быть, F # станет популярным.


источник
2

Не помогает то, что c-> ocaml является более значительным психическим переходом, чем c-> lisp. Я пару раз рассматривал ocaml и всегда обнаруживал, что цена / выгода просто не для меня, так что отложите это снова. Это не были конструкции, которые заставляли это выглядеть трудно, они действительно выглядели действительно опрятными. Он пытался выучить совершенно другое значение слова «!». Лисп, по крайней мере, выглядит настолько по-другому, что легко избежать неправильного толкования его маленьких частей как c.


источник
2

Если вы хотите, чтобы язык использовался во встроенных системах реального времени, вам нужны указатели, и вы не можете позволить себе GC.

Неманья Трифунович
источник
1

Я думаю, что основная причина в том, что слишком мало разработчиков знают OCaml.

И когда я общаюсь с другими разработчиками (теми, кто что-то слышал об Ocaml), у меня всегда складывается впечатление, что они думают об OCaml как о языке "только для образования" ... грустно, но верно

Крис
источник
Я считаю, что сейчас есть 2 компании с> 20 разработчиками OCaml (Jane St. и Citrix).
Джон Харроп
3
Вау! Целых две компании? :)
Иттрилл
0

Мне очень нравится O'caml ... Я реализовал множество вещей, используя его, компилятор, интерпретаторы, систему для связи с C ...

когда я узнал об этом, основная проблема заключалась в том, что сообщения об ошибках не совсем ясны ... так, например, в начале я не был уверен, когда поставить ';' и это было действительно трудно найти, что на самом деле; был неуместен ...

LB40
источник