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

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

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

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

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

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

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

• Первый зрелый компилятор 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, поэтому сообществу сложнее выработать глубокое понимание того, как его использовать.

Я думаю, что проблема с 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИМХО, я думаю, что большая проблема 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, который имеет ДЕЙСТВИТЕЛЬНО лицензию с открытым исходным кодом и сообщество с ДЕЙСТВИТЕЛЬНО поведением с открытым исходным кодом.

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

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

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

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

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

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

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

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

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

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