为什么OCaml不受欢迎？

#1 楼

第一个答案是，没有人真正知道语言为什么会流行，而其他人则感到迷惑或有议程。 （通常很容易确定为什么某种语言未能流行的原因，但这是另一个问题。）

使用该免责声明，以下是一些有启发性的要点，最重要的是首先：


1974年出现了第一个成熟的C编译器。第一个成熟的OCaml编译器出现在1990年代后期。 C具有25年的领先优势。
C随Unix一起提供，这是有史以来最大的“杀手级应用”。长期以来，世界上每个CS部门都必须拥有Unix，这意味着每个讲师和参加CS课程的每个人都有机会接触C。OCaml和ML仍在等待他们的第一个杀手级应用程序。 （MLdonkey很酷，但它不是Unix。）
C填补了它的空白，以至于我怀疑永远不会有仅用于系统编程的另一种低级语言。 （要获得有利的证据，请阅读HOPL II中Dennis Ritchie的有关C历史的论文。）甚至还不清楚OCaml的利基是什么，而Standard ML的利基则更加清晰。因此，Caml和ML拥有很多竞争对手，而C击败了它的唯一竞争对手（BLISS）。
C的一大优势在于其成本模型非常可预测：可以轻松查看C代码的任何小片段，即可立即准确地了解执行该代码必须执行哪些机器操作。 OCaml的成本模型不太清楚，尤其是因为内存分配的显性要低得多，并且内存分配的总成本（相等的分配成本加上垃圾回收期间产生的成本）取决于紧急属性，例如对象的生存时间和引用的对象其他对象。最终结果是性能很难预测，甚至很难分析。 （OCaml的内存分析工具不是应有的工具。）因此，OCaml不适用于性能必须非常可预测的应用程序（例如嵌入式系统）。
C是一种具有许多标准的语言编译器。 OCaml是软件工件：唯一的编译器来自单一来源，并且编译器是标准的。而且该标准随每个发行版而改变。对于重视稳定性和向后兼容性的人来说，单一源语言可能会带来无法接受的风险。
任何拥有中等程度的本科编译器课程并且具有很多持久性的人都可以编写可以或多或少有效的C编译器，并且具有足够的性能。为了使OCaml或ML的实现落地，需要更多的知识，而要获得与天真的C编译器可比的性能，则需要做大量的工作。这意味着很少有业余爱好者会喜欢OCaml之类的语言，因此社区很难对如何利用它进行深入了解。

#2 楼

我认为OCaml的问题在于“开箱即用”它不太有用。人们使用某种语言的最终原因是因为它拥有他们所需的库。但是，没有什么“开箱即用”的东西，没有人能深入到项目中来意识到他们需要编写一个库。结果是没有库的语言，这使得编写“真实的应用程序”变得很困难。

我认为这是OCaml所遭受的-没有人愿意在其中启动“真实的项目”，因为有一种编程语言。是的，我可以加两个和两个并打印结果。结果是收集了大部分都是学术性的抛弃式软件的库（作者获得了博士学位并继续前进），这对实践程序员并不太有用。

（我知道正在进行着一些工作，可以使用“包括电池”之类的项目来更改此设置。请在5年后再回到这里，也许OCaml会更受欢迎。）

此规则有些例外。 Java最初是没有库的，但是Sun付钱让人们在内部编写它们，然后他们把它全部卖掉了。 Java认证，特定于Java的硬件，Java书籍，Java类等。然后，即使说这不是一种用于学习编程的好语言，大多数大学也说服了他们专门学习。

结果是受欢迎。钱可以解决很多问题。

在功能语言领域，我们可以看到Haskell变得非常流行。我认为大多数的流行是由于像dons这样的人编写了有用的库，并且从未停止过销售这种语言。每天您都会看到Haskell上有关Programming Reddit的几篇文章。这使它一直困扰着人们，直到他们最终决定“我要尝试Haskell”为止。当他们这样做时，他们会看到有用的东西，例如Web框架，对象数据库，OpenGL库和XML处理库。这意味着他们实际上可以做一些有用的“立即行动”。因此，在具有潜力的生产能力和对它的大量了解之间，Haskell得到了很大的欢迎。

CL具有许多与Haskell相同的库，并且速度几乎一样快，但是没有人谈论它，因此“感觉已死”。确实，＃lisp比#haskell安静得多，但是Lisp仍然是一种非常有生产力的语言，具有许多库。没有其他语言具有SLIME。但是营销非常重要，Haskell的表现要比Lisp或OCaml更好（并争夺相同的用户群）。

最后，有些人永远不会“得到”编程，因此破坏了他们的思维模式（变量是带有值的框，代码从上到下执行）将确保它们不使用您的语言。这种类型的程序员在编程人员中占很大比例，因此这进一步限制了诸如Lisp，Haskell和OCaml之类的抽象语言的潜在用户群。

#3 楼

我非常喜欢OCaml作为一种语言。但是...

工具支持还不存在。调试器只能正常运行，但不能在Windows上运行（最后我检查过），并且没有太多可用的开发工具。

它的类型系统有时过于强大。对于通常不了解类型推断如何工作或ML类型系统的人，他不能立即向浮点数添加整数的事实马上就成为了主要的选择。

标准图书馆有时会产生不一致的感觉。

对象模型似乎有些固定，标准库几乎没有使用它，而是选择了基于模块的库。

还有很多其他的东西，基本上等于语言不会感到“磨光”，并在人们选择一种语言并试图决定他们是否喜欢它的关键时期将其赶走。

我认为这是最重要的遗产它将与其他ML方言一起对其他功能语言产生非常大的影响。当前的大多数功能语言都采用了ML方言中最好的元素，并消除了一些烦恼。

#4 楼

嵌入式系统通常需要两件事：速度和确定性。 OCaml可以提供速度，但是它具有垃圾收集器的事实使其固有地不确定性，而对于实时系统而言，简单是无法做到的。

#5 楼

这有点像橘子的比较。 OCaml是一种相当年轻的语言[1]，并且从未进行过认真，持续的努力将其推向主流（微软目前与F＃的合作除外）。与C不同，它不是受最广泛支持和模仿的企业操作系统（即UNIX）的通用语言。与Java不同，它没有一家大型公司将其推向下一代计算平台。与Perl，Python和Ruby不同，它并没有占据高知名度，有影响力的利基市场（即，其利基市场是编程语言和自动推理研究，与Web开发相比并不算是高知名度）。因此，它不是超级受欢迎。

[1]公平地讲，原始的ML语言自20世纪70年代就存在。但是OCaml直到1996年才出现，并且没有继承Standard ML库。实际上，它是比C，C ++，Java，Python，Haskell甚至Ruby更年轻的语言。

#6 楼

OCaml社区未能开发出一个大型且可靠的标准库（超出了当今OCaml随附的库），这使得应用程序开发变得容易。有几种尝试解决该问题的方法，但是只需看一下Python或Ruby来查看缺少的内容。如果您想解决一个算法问题，而OCaml是一种很棒的语言，而该算法问题并不需要过多地与XML，网络，数据计算等高级标准模块进行交互，而您不想自己实现。

我认为部分问题是OCaml如何将模块映射到文件：从概念上讲，所有* .ml文件都位于相同的名称空间中，目录没有意义。这使得社区很难发展图书馆。如果编译器将目录层次结构映射到模块层次结构中，我会看到标准库会更好地发展。但是，这将需要核心编译器开发人员付出巨大的努力。 （我知道打包模块，但是我认为这很麻烦。）

另一个库问题是编译器版本之间的二进制兼容性。可以肯定地说，在编译器升级后必须重新编译所有库代码。这使得很难提供模块或库的二进制发行版。

#7 楼

可能是因为过多的人接受过ML语言培训，因为这是对类型的怪异和令人困惑的理论介绍的一部分。这就是我发生的事情。

大约同时向我展示了ML和Smalltalk。 Smalltalk看起来简直太酷了，立即可以理解OO的用途以及在这种环境下如何制作漂亮的交互式内容。 ML是关于抽象的数学事物，似乎与我想做的事情无关。而且与C不同，我不能保证让我用16位micros编写快速游戏。

当然，这是非常不公平和主观的。但这对于大多数人来说可能是真实的故事。

这些天我想的问题是：现在我确实觉得我需要了解关于类型的奇怪且令人困惑的理论知识，为什么我会选择通过Haskell或Erlang进行ML？

#8 楼

我认为主要问题是缺少实际的标准库。因此，包含OCaml电池的项目有望大大改善这种状况。它应该会在几天内进入Beta阶段，因此您必须在一年左右的时间内再次提出问题。

#9 楼

我同意Windows支持不佳，陡峭的学习曲线和苗条的标准库在过去都扼杀了OCaml的使用，但是我要补充说，与Java之类的主流语言相比，关于OCaml的教程信息（例如书籍）非常缺乏。

另外，了解OCaml之类的语言的人也非常不同。在网络程序员中，可能有千分之一的人听说过OCaml。在剑桥大学从事科学计算的人中，我认识的人中约90％的人精通OCaml。确实，我是我的最后一个学习OCaml的朋友之一。我们甚至在256 CPU超级计算机上运行OCaml ...

我还应该提到这些问题正在迅速得到解决。 OCaml最近通过Ocsigen之类的项目将自己改造为Web编程，并且在这种情况下至少已经取得了两个主要的工业成功案例。现在有关于OCaml的另一本新书。该社区正在合作一个名为“包括电池”的综合标准库，该库刚刚进入Beta版本，看上去很棒。 OCaml的多核友好版本即将发布。 OCaml的最新版本还包括许多出色的新功能，例如惰性模式和动态加载的本机代码OCaml库。

#10 楼

我认为部分问题在于函数编程并不是大多数人思考的一种自然方法（我说这是对函数编程有浓厚兴趣和赞赏的人）。如今，绝大多数程序员开始学习过程编程（大多数流行的OOP语言仍是过程的核心），因此功能语言很难适应最初的事实，这使情况更加复杂。

当我上大学时，我已经知道相当数量的BASIC，C ++和Java以及一些Pascal和x86汇编语言。我不是专家，但得出的结论是：所有编程语言基本上都是相同的，只是语法略有不同。我们对编程课程的介绍使用了ML，这使我很快忘了这个想法。在编程生涯的那个阶段，我很难掌握ML，也没有真正看到函数式编程的意义。我认为要真正体会到函数方法的好处，需要更多的过程编程问题经验。

我们的ML讲师经常声称，递归表达问题更“自然”且容易而不是使用循环或其他程序概念。我从来没有被那个说法说服，现在仍然不买它。递归函数有时可以为问题提供特别优雅和简洁的解决方案，但我仍然认为这是思考问题的不自然方法。也许如果您具有很强的数学背景，那么它似乎会更直观，但我认为大多数人都不容易进行递归思考。考虑到递归函数在函数式编程范式中的核心地位，我认为这也可能是函数式语言不那么流行的原因。
对语言流行度也有反馈作用。当我开始编程时，我想知道如何编程图形效果和游戏。在学习了一些BBC BASIC和后来的QBASIC之后，我自然地研究了演示场景和游戏程序员使用的最常见的语言，并着手学习C ++和x86汇编。如今，一些新的程序员可能想知道如何生成Web应用程序，因此会倾向于学习PHP，Ruby或C＃。自我激励的初学者程序员很少有应用程序领域，其中“什么是学习像X这样的东西的最佳语言”的答案将是“ Ocaml”。

给出了许多实际的原因Microsoft正式支持F＃作为一流的.NET语言解决了Ocaml有限的普及（缺少成熟的库，调试器，IDE等）的问题。有趣的是，看看F＃是否有助于为函数式编程带来更大程度的普及。

评论

---

递归关系是始终可以很好地映射到FP的事物之一。

– J D
10 Mar 18 '10在0:28

---

“对于大多数人来说，函数式编程并不是一种自然的思考方式”：只要我使用Basic进行编程，结构化编程对于我来说并不是一种自然的思考方式。然后我搬到帕斯卡。只要我使用Pascal和C进行编程，面向对象的编程就不是我思考的一种自然方法。然后我转向了C ++和Java。在我开始学习Haskell和其他FP语言之前，函数式编程对我来说似乎还很陌生，现在C ++对于某些任务显得如此尴尬。 :-)

–乔治
2012年7月28日12:00

---

#11 楼

我认为问题的核心是政治。 Ocaml开发人员主要对研究感兴趣，并且没有资源来提供和维护丰富的库。但是，他们也不愿意将产品的控制权释放给拥有这些资源的社区，其结果是解决该问题的几次尝试都依赖于第三方图书馆的不存在的合作和资助，而这些尝试都失败了。除非出于同样的原因，否则电池将失效，除非Ocaml开发人员改变了态度。

我使用Ocaml开发产品，而且我有一条简单的规则：将对第三方代码的依赖性降至最低。当第三方项目有用时，请尽可能将源代码直接包含在包装中。例如，OCS Scheme和Dypgen是Felix解析器的重要组成部分，因此它们被复制到我们的源代码中，因此我们可以对其进行一些控制。该控件有些虚幻（因为Dypgen至少是如此复杂，以至于我们不太可能维护它，但至少我们有一个我们认为可行的副本：）

由于许可证，我不会使用电池是限制性的，因此我无法复制该源，并且我对它作为独立产品的长期可移植性不信任：我可以使用它的唯一方法是将其直接并入Ocaml的标准发行版中。

在C ++世界中，我可能会考虑使用Boost：尽管它是不是标准的一部分的第三方库，但它得到了社区的大力支持，并且实际上与标准开发过程完美地同步。在Boost中开发和测试的想法成为可以标准化的现有实践，并且标准过程足够开放以允许社区参与。

Ocaml之所以获得了真正的普及，是因为它是一款出色的产品，但这还不足以使其成为主流语言。 Java很简陋，它在数十亿美元的市场营销和库开发中广受欢迎，但最终必须向社区发布才能生存。

#12 楼

我很喜欢用ML和C编写各种项目的代码。阻止我在嵌入式项目中使用ML的事情（大多数项目具有实时约束，并且需要验证）是垃圾收集。

有研究区域内存管理（请参阅MLKit），但是很复杂正确使用它们所需的实施和培训（以及随之而来的风险）阻碍了使用它们。

#13 楼

恕我直言，我认为OCaml的一个大问题不是语言（很棒），而是开发它的人，因此，他的许可证也是如此：

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

他们使用Q Public许可证进行编译！是的，用于Qt库的前Trolltech许可证！

如果您在大约7到8年前检查Language Shootout（http://shootout.alioth.debian.org/），就忘了获得任何贡献。 C和C ++以提高执行速度。一段时间以来，其他语言（例如Haskell）获得了更好的编译器（我认为是由于采用了不同的社区方法），而OCaml的执行速度却不如过去。

不久，我不会使用OCaml，因为如果没有一些非常好的黑客创建一个具有真正开源许可证和一个真正具有开源行为的社区的OCaml编译器，我看不到它能更好地发展。

#14 楼

好吧，就像@jrockway所说的，关于金钱，我们将看看F＃是否会像Java或C＃一样流行。

对我来说，我觉得开发人员对功能的实现方式感到不舒服事情（来自2009年techday的F＃会议上，大约有10个人说他们知道近100个人中的函数式编程。）

我从今年开始OCAML，我从没碰过函数式编程，但现在我真的总是从OCAML和解决问题的功能性方法中学习新事物（但我不能说我会放弃C＃来使用OCAML ：））。

#15 楼

好吧，也许F＃变得流行了。

#16 楼

c-> ocaml比c-> lisp更大的心理转变没有帮助。我已经考虑过ocaml几次，并且总是发现成本/收益对我而言并不存在，因此请再次搁置。不是让结构看起来很难，而是实际上看起来很整洁。它试图学习“！”的完全不同的含义。 Lisp至少看起来如此不同，很容易避免将其中的一小部分误解为c。

#17 楼

如果您想在实时嵌入式系统中使用某种语言，则需要使用指针，而您负担不起GC。

#18 楼

我认为主要原因是开发人员不了解OCaml。

当与其他开发人员（听说过Ocaml的人）交谈时，我总是给人一种印象，他们认为OCaml是一种“仅用于教育”的语言……可悲却是真实的

#19 楼

我非常喜欢O'caml ...我已经使用它实现了很多东西，编译器，解释器，系统来与C通讯...

当我了解它时，主要问题是错误消息还不是很清楚...例如，一开始我不太确定何时放';'真的很难找到那个;被放错了位置...