如果我已经知道 OCaml，我应该学习 Haskell 还是 F#？ [关闭]答案

【问题标题】：Should I learn Haskell or F# if I already know OCaml? [closed]如果我已经知道 OCaml，我应该学习 Haskell 还是 F#？ [关闭]
【发布时间】：2009-05-05 00:18:20
【问题描述】：

我想知道是否应该继续学习 OCaml 或切换到 F# 或 Haskell。

以下是我最感兴趣的标准：

长寿
- 哪种语言会持续更长时间？我不想学习可能在几年内被用户和开发人员抛弃的东西。
- Inria、Microsoft、格拉斯哥大学是否会继续长期支持各自的编译器？
实用性
- this 之类的文章让我不敢使用 Haskell。哈希表是快速检索的最佳结构。那里的 Haskell 支持者建议使用二叉树 Data.Map。
- 除非好处很大，否则我不喜欢与庞大的 .NET 框架绑定。
- 我希望能够开发的不仅仅是解析器和数学程序。
精心设计
- 我希望我的语言保持一致。

请用文章中的逻辑论据和引用来支持您的观点。谢谢。

【问题讨论】：

这是一篇关于 Haskell 的奇怪文章。一种无法制作快速哈希表的语言？我不是什么性能坚持者，但哈希表是一种一流的数据结构。
@mquander 是的，我一直使用其他语言的哈希表。另请注意，这篇文章仅来自 4 月，而且 GHC 已经很老了。
如果您遇到需要“散列”的特定问题，请使用 Data.IntMap 或 Hackage 上的散列表库之一。
整个哈希表的事情已经被吹得不成比例了。事实上，.NET 具有自动拆箱功能，其哈希表实现使用该功能效果非常好，您可以编写基准测试来证明这一点。如果您的问题符合该模式，或者您可以这样做，那么您将从 .NET 获得比 Haskell 的 Data.Hash 库更好的性能。当您试图从中得出一般性结论时，问题就来了：除了我所说的之外，没有任何可得出的结论。另请查看 Haskell 哈希图库。
@Simon：“当你试图从中得出一般性结论时：除了我所说的之外，没有什么可以得出的”。 Haskell 似乎由于几个一般原因而变慢：GC 中的性能错误（将元素写入可变数组会弄脏整个数组），缺少值类型和参数多态性的装箱。

标签： haskell f# ocaml language-comparisons

【解决方案1】：

长寿

Haskell 事实上是函数式编程研究的主要语言。 Haskell 98 将以稳定的形式持续多年，而称为 Haskell 的东西可能会持续 10 到 30 年——尽管该语言将继续发展。社区对 Haskell 进行了重大投资，即使主要的 GHC 开发人员明天被公共汽车撞到（著名的“剑桥公共汽车错误”问题），还有很多其他人可以挺身而出。还有其他不太复杂的编译器。
Caml 由法国国家实验室 INRIA 的一个小组控制。他们也有很大的投入，其他的也有Caml的投入，而且代码是开源的，编译器也不太复杂，所以也会维护很久。我预测 Caml 将比 Haskell 稳定得多，因为 INRIA 的人们似乎不再将它用作探索新语言想法的工具（或者至少他们这样做的速度比过去要低）。
谁知道公司会做什么？如果 F# 成功，微软可以支持它 20 年。如果不成功，他们可能会在2012年拔掉插头。我猜不出来，也不会尝试。

实用性

哈希表是快速检索的最佳结构。那里的 Haskell 支持者建议使用二叉树 Data.Map。

这取决于您要搜索的内容。当您的键是字符串时，ternary search trees 通常比哈希表快。当您的键是整数时，Okasaki 和 Gill 的 binary Patricia trees 可以与散列竞争。如果你真的想，你可以使用 IO monad 在 Haskell 中构建一个哈希表，但很少需要这样做。

我认为延迟评估总会有性能损失。但“实用”不等于“尽可能快”。以下关于性能的说法是正确的：

最容易预测 Caml 程序的时间和空间行为。
F# 在中间（谁真正知道 .NET 和 JIT 会做什么？）。
最难预测 Haskell 程序的时间和空间行为。
Haskell 拥有最好的分析工具，从长远来看，这是产生最佳性能的原因。

我希望能够开发的不仅仅是解析器和数学程序。

要了解 Haskell 中的功能范围，请查看 xmonad 窗口管理器和 hackage.haskell.org 上的 vast array ofpackages。

除非好处很大，否则我不喜欢与庞大的 .NET 框架绑定。

我无法评论：

精心设计

我希望我的语言保持一致。

评估一致性的几点：

Haskell 的具体语法设计得非常好； Haskell 委员会的出色工作给我留下了深刻的印象。 OCaml 语法还可以，但相比之下会受到影响。 F#从Caml核心语法开始，有很多相似之处。
Haskell 和 OCaml 都有关于运算符重载的非常一致的故事。 Haskell 具有一致且强大的机制，您可以自行扩展。 OCaml 没有任何类型的重载。
OCaml 具有最简单的类型系统，尤其是如果您不编写对象和函子（许多 Caml 程序员不这样做，尽管在编写 ML 时不编写函子对我来说似乎很疯狂）。 Haskell 的类型系统雄心勃勃且功能强大，但它仍在不断改进，这意味着由于历史原因存在一些不一致之处。 F# 本质上使用 .NET 类型系统，以及类似 ML 的 Hindley-Milner 多态性（参见问题 "What is Hindley-Milner"。）
OCaml 在它认为变体应该是静态类型还是动态类型方面并不太一致，因此它同时提供了（“代数数据类型”和“多态变体”）。由此产生的语言具有很强的表达能力，这对专家来说非常有用，但对于业余爱好者来说，使用哪种结构并不总是显而易见的。
OCaml 的评估顺序是官方未定义的，这在具有副作用的语言中是一个糟糕的设计选择。更糟糕的是，实现不一致：字节编码的虚拟机使用一种顺序，而本机代码编译器使用另一种。

【讨论】：

一些优点，但是：您关于树与哈希表性能的建议具有误导性。您断言 Haskell 比 .NET 具有更好的分析支持是荒谬的。您断言许多 OCaml 程序员忽略对象和函子是错误的（否则您甚至不能使用 Set 和 Map 并且 OCaml 的几个最流行的库严重依赖对象）并且您忽略了多态变体，这是 OCaml 相对于其他变量的最大优势之一静态类型的 FPL。您关于 OCaml 的评估顺序“不一致”的断言是错误的：它一直是未定义的。
我开始学习更多关于 Haskell 的知识，发现它的语法比 OCaml so_much_better。但是我仍然不喜欢默认的懒惰评估，哈希表的东西仍然困扰着我。因此，我仍然在这些语言之间纠结。
@Jon Harrop（GHC 和 .NET 中的分析支持）：.NET 提供的哪些方面与 GHC 的成本中心和 GHC 的堆分析器一样好？
@Jon Harrop（许多 OCaml 程序员会忽略对象和函子吗？）：虽然我自己喜欢函子但讨厌对象，当我参加国际会议时，如果您阅读我的 ML 论文，您就会知道在函数式编程中，我经常听到诸如“我从未见过我喜欢的对象或函子”之类的 cmets。
@Unknown：我花了大约 5 年的时间才停止担心并学会默认喜欢惰性评估，直到我在没有计划的大型程序中获得了一些重大胜利提前让结构变得懒惰。所以我很同情。对于哈希表，我认为您将很难找到重要的应用程序。

【解决方案2】：

如果你知道 OCaml，你应该学习 F# 还是 Haskell？

我相信答案肯定是肯定的，理想情况下，您应该学习所有三种语言，因为每种语言都有所提供的东西，但 F# 是唯一具有重要未来的语言，因此，如果您只能学习一种语言，请通过阅读来学习 F#我的Visual F# 2010 for Technical Computing book 或订阅我们的The F#.NET Journal。

长寿

微软在 4 月将 F# 作为 Visual Studio 2010 的一部分发布时承诺支持它。因此，F# 至少在几年内保证了美好的未来。 F# 结合了实际重要的功能，如高性能本机代码 REPL、.NET 4 内置的高级并行结构和生产质量的 IDE 模式，long现在在现实世界的适用性方面领先于任何其他函数式编程语言。坦率地说，在不久的将来，甚至没有人在研究任何可能与 F# 竞争的东西。我自己的开源HLVM 项目正在尝试这样做，但还远远没有准备好。

相比之下，OCaml 和 Haskell 的开发方向都非常低效。这已经扼杀了 OCaml 好几年了，我希望 Haskell 在接下来的几年里也会效仿。大多数以前的专业 OCaml 和 Haskell 程序员已经转向 F#（例如 Credit Suisse、Flying Frog Consultancy），其余的大多数人无疑会在不久的将来转向更实用的替代方案，例如 Clojure 和 Scala。

具体来说，OCaml 的 QPL 许可证阻止其他任何人修复其不断增长的基本设计缺陷（32 位机器上的 16Mb 字符串和数组限制、没有共享内存并行性、没有值类型、通过类型擦除的参数多态性、解释性 REPL ，繁琐的 FFI 等），因为他们必须仅以补丁的形式分发衍生作品到原始作品，并且 Debian 软件包维护者拒绝承认上游的替代作品。该语言中添加的新功能（例如 OCaml 3.12 中的一流模块）远没有多核功能所具有的价值。

为了拯救 OCaml 而启动了一些项目，但事实证明它们为时已晚。 parallel GC 几乎没用，David Teller 退出了 batteries included 项目（尽管它已被捡起并以缩减的形式发布）。因此，OCaml 已经从 the most popular functional language in 2007 变成了今天的严重衰退，caml-list traffic down over 50% since 2007。

Haskell 的工业用户比 OCaml 少，虽然它确实支持多核，但它仍在朝着一个非常低效的方向发展。 Haskell 几乎完全由剑桥（英国）微软研究院的两个人开发。尽管纯粹的函数式编程在设计上不利于性能，但他们仍在继续尝试开发针对多核的并行 Haskell 解决方案，因为它所招致的大量不必要的复制撞到了内存墙并破坏了在一个可扩展并行性上的任何希望多核。

业界唯一的 Haskell 主要用户是 Galois，拥有大约 30 名全职 Haskell 程序员。我怀疑他们会让 Haskell 彻底死掉，但这并不意味着他们会把它发展成一种更普遍有用的语言。

实用性

我写了你引用的关于哈希表的文章。它们是一个很好的数据结构。其他人提到了诸如三叉树和帕特里夏树之类的纯功能替代方案，但在实践中这些通常比哈希表慢约 10 倍。原因很简单，缓存未命中在当今的性能问题中占主导地位，并且树会导致额外的 O(log n) 指针间接寻址。

我个人偏爱可选的惰性和可选的纯度，因为两者在现实世界中通常会适得其反（例如，惰性会使性能和内存消耗变得不可预测，而纯度会严重降低平均情况下的性能并使互操作性成为一场噩梦）。我是仅有的通过我自己的公司完全靠函数式编程谋生的人之一。可以这么说，如果我认为 Haskell 是可行的，我会在几年前将其多元化，但我一直选择不这样做，因为我认为它在商业上不可行。

您说“我不喜欢被捆绑到庞大的 .NET 框架，除非好处很大”。好处是巨大的。您将获得一个生产质量的 IDE，一个生产质量的 JIT 编译器，它执行非常有效的优化，如类型专用泛型，生产质量的库，适用于从 GUI 编程（参见Game of Life in 32 lines of F#）到数字运算的所有内容。但 .NET 的真正好处，至少对我而言，是你可以出售你用 F# 编写的库并赚很多钱。没有人成功地向 OCaml 和 Haskell 程序员销售库（我是少数尝试过的人之一），但 F# 库已经大量销售。因此，如果您想通过编写软件谋生，那么庞大的 .NET 框架非常值得。

精心设计

这些语言都经过精心设计，但用途不同。 OCaml 是专门为编写定理证明器而设计的，而 Haskell 是专门为研究 Haskell 而设计的。 F# 旨在解决 OCaml 和 Haskell 的所有最严重的实际问题，例如互操作性差、缺乏并发垃圾收集以及缺乏 WPF 等成熟的现代库，以便为广大受众带来高效的现代语言。

【讨论】：

投票赞成，因为我认为这个答案不值得（未注释）反对
投票否决，因为乔恩改变了过去的合理答案。
Reid 在这点上是对的。查看这篇文章的历史，您会看到从不偏不倚的方法到结合助推主义和 FUD 的急剧转变。诚然，F# 有一个强大的内置基础，它是一种 .NET 语言，但这篇文章的原始版本是正确的——没有证据表明 OCaml 或 Haskell，这两者的用户群和受欢迎程度都在不断增长，并且会走向任何地方。
投反对票。除了其他不准确之处，我不知道这些言论的任何证据：“.. 它所导致的大量不必要的复制击中了内存墙，破坏了多核上可扩展并行性的任何希望。”可以构建在多核上表现非常好的垃圾收集器，并且已经知道如何做到这一点已有一段时间了（参见例如citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.52.9494）。事实上，要利用这样的设计，您需要大部分不可变数据，即函数式编程语言。
@Jon 你没抓住重点。该论文描述了一种在年轻代中进行本地 per-CPU GC 的 GC 架构，这是一种有效的多核设计。这种设计的一个变体已被证明可以在 Manticore 中工作。我没有说我们是在 GHC 中做的，尽管这对我们来说是合乎逻辑的下一步（我们不会“复制他们的基本架构”，你读过论文吗？）。请注意，不变性对于执行本地 GC 变得非常重要，比分代 GC 更重要：我猜这就是 .NET 和 JVM 中的“工业实力”GC 没有实现它的原因。

【解决方案3】：

这不是您的标准之一，但您是否考虑过工作可用性？ Haskell 目前确实列出了 144 个工作，Ocaml 列表 12 和 C# 列表 26,000。这些数字并不完美，但我敢打赌，一旦 F# 发布，它的工作列表数量很快就会超过 Haskell 和 Ocaml。

到目前为止，Visual Studios 中包含的每种编程语言都有数以千计的职位列表。在我看来，如果你想要最好的机会使用函数式编程语言作为你的日常工作，那么 F# 很快就会实现。

【讨论】：

从实用的角度来看，这差不多。
我很惊讶我有 2 票反对票和 3 票赞成票。我认为否决投票的目的是删除不相关或错误的信息，不要不同意。
反对票来自“微软是一个邪恶的帝国”人群。
我宁愿在 Haskell 中编程...
@Thorbjørn Ravn Andersen：为什么？

【解决方案4】：

长寿

没有人可以预测未来，但是

OCaml 和 Haskell 多年来一直经营良好，这对他们的未来来说是个好兆头
当 F# 附带 VS2010 时，MS 将有法律义务为其提供至少 5 年的支持

实用性

Perf：我对 Haskell 没有足够的第一手经验，但基于二手和三手信息，我认为 OCaml 或 F# 更实用，在某种意义上我认为你不太可能'将能够在 Haskell 中获得与在 F# 的 OCaml 中相同的运行时性能。

库：轻松访问 .Net Framework 是 F# 的一大优势。如果您愿意，您可以将其视为“与这个庞大的东西相关联”，但不要忘记“您可以访问一个庞大的、包含通常非常有用的东西的庞大库”。与 .Net 的“连接性”是 F# 的一大卖点。 F# 更年轻，因此第三方库更少，但已经有例如FsCheck、FParsec、Fake 和其他一堆，除了 .Net 上的“盒子里”库。

工具：我没有足够的个人经验来比较，但我认为 VS 与 F# 的集成优于你今天为 OCaml/Haskell 找到的任何东西（并且 F# 将在接下来继续改进一点年）。

改变： F# 在接近 VS2010 中的第一个受支持版本时仍在发生变化，因此在不久的将来您可能不得不忍受对语言/库的一些重大更改。

精心设计

Haskell 绝对是美丽和一致的。我不太了解 OCaml，但我的直觉是它同样具有吸引力。我认为 F# 比其中任何一个都“更大”，这意味着更多尘土飞扬的角落和不一致（主要是由于调解 FP 和 .Net 之间的阻抗不匹配），但总体而言 F# 对我来说仍然感觉“干净”，而且确实存在的不一致至少是合理/有意的。

总体

在我看来，你会“很好”地了解这三种语言中的任何一种。如果你知道一个你想用它做的大型长期项目，一个可能会脱颖而出，但我认为许多技能将是可以转移的（在 F# 和 OCaml 之间比在 Haskell 之间更容易转移，但在任何技能中也更容易转移）这三个比使用 Java）。

【讨论】：

好吧，与庞大的 .NET 捆绑在一起的问题在于，它会迫使您故意捆绑它，而不是仅选择性地包含您使用的库。
好吧，从技术上讲，F# 会强制您捆绑 .NET，但实际上它已经在您之前存在。这有点像说它强制你捆绑 Windows。此外，如果您使用 Mono，他们有一个工具可以让您只选择您正在使用的功能。这在您将支持库包含到应用程序包中的 Mac 上很有用（Mono 可能尚未安装）。

【解决方案5】：

这个问题没有简单的答案，但这里有一些事情需要考虑：

Haskell 和 OCaml 都是具有强大实现的成熟语言。实际上，Haskell 有多种很好的实现，但我认为这不是有利于您的目的的重点。

F# 要年轻得多，谁能预测微软会决定把它带到哪里？您对此的看法更多地取决于您对 Microsoft 的看法，而不是任何人都可以告诉您的有关编程语言的任何事情。

OCaml（或一般的 ML）是一种很好的实用语言选择，它支持做很酷的功能性工作，而不会强迫您以可能不舒服的方式工作。您可以充分利用代数数据类型、模式匹配、类型推断以及其他所有人最喜欢的东西。哦，还有对象。

Haskell 为您提供了所有这些（几乎除了对象），但也或多或少地迫使您重新思考您认为自己对编程了解的一切。如果您想学习新的东西，这可能是一件非常好的事情，但它可能比您想要的更多。我这样说是作为一个可能只是在成为一名高效、快乐的 Haskell 程序员道路上的人。

OCaml 和 Haskell 都被用于编写许多不同类型的程序，而不仅仅是编译器和 AI 或其他。 Google 是您的朋友。

最后一点：OCaml 为您提供哈希表，但如果您真的想接受函数式编程，在代码中使用它几乎是不明智的。持久化树（如 Data.Map）确实是 Haskell 的正确解决方案，并且具有许多不错的属性，这是学习 Haskell 时需要了解的很酷的事情之一。

【讨论】：

但问题是我宁愿拥有 O(1) 访问权限。大集合的 O(log n) 访问是荒谬的。如果你有一个持久化的树并不重要，因为你肯定有一个持久化的哈希表。
如果你只想要 O(1) 因为它听起来不错，那么正如另一位发帖者所说，尽管它不是一个很好的选择，但你可以随意在 Haskell 中使用哈希表。我的观点是，一种具有惰性求值且没有副作用的语言确实需要持久数据结构 (en.wikipedia.org/wiki/Persistent_data_structure)。这是一个强有力的想法，值得研究和反思。在我看来，这比 O(1) 与 O(log n) 更重要，而且它肯定比某人的随机计时练习更重要。跟我说：“微基准是邪恶的！”
@Moss，不幸的是，我遇到过很多情况，即 O(k) 和 O(log n) 之间的差异，其中 k 介于 1-20 之间，n 为数十万。我非常怀疑“持久数据结构”是否是没有像样的哈希表的正当借口。如果可以拥有持久化树，为什么不拥有持久化哈希表？
尝试使用 IntMap（或 hackage 上的哈希表库——有一个 judy 数组绑定），如果遇到问题，请报告问题。我猜你可能不会有问题。
我想简短的回答是，传统观点认为您不能（轻松）实现具有良好性能的持久哈希表，但现在我发现并不是每个人都同意这一点，所以这里有一个给正在阅读的人的几个链接：en.wikipedia.org/wiki/Purely_functional（这包括一个指向 Chris Okasaki 论文的链接——所有人：停止阅读这个线程，现在就去阅读论文或书籍版本！）LtU 定期 cdiggins 的帖子逆势位置：artima.com/forums/flat.jsp?forum=106&thread=137924 另外，log 100k = 17。

【解决方案6】：

F# 和 OCaml 在语法上非常相似，但显然 F# 更适合 .NET。

你学习或使用哪一个取决于你的目标平台。

在 VS2010 中将包含 F#，由于它编译为 .NET 字节码，因此可以在支持您使用的 .NET 版本的 Windows 操作系统上使用。这会给你一个很大的区域，但是有一些限制，目前 F# 是 OCaml 没有的，因为 F# 似乎没有利用机器上的所有处理器，但是，这可能是由于 F# 仍在开发中，这可能是一个不那么重要的功能。

还有其他函数式语言，例如 Erlang，你可以看看，但是，基本上，如果你精通一种 FP 语言，那么你应该能够很快学会另一种语言，所以，只选择你喜欢的一种并尝试在其中开发有趣且具有挑战性的应用程序。

最终，语言编写者会找到一种方法让 OO 语言在多核上运行良好，而 FP 可能会再次被淘汰，但是，这似乎不会很快发生。

【讨论】：

F# 具有异步工作流，这对于进行并行化来说无疑是非常好的。尽管如此，随着 .NET Framework 4.0 中出现并行扩展，我认为多核上真正简单的 OOP 指日可待。
不确定您所说的 F# 不使用机器上的所有处理器是什么意思。我可以毫不费力地将 F# 代码加载到 100%。取决于我在做什么。
几个月前我读过一篇文章，作者提到与 OCaml 不同，F# 并没有正确使用他的所有八个处理器。我的笔记本电脑没有，所以我无法验证，但我认为这是由于正在使用的版本，我认为当它具有足够高的优先级时它会被修复。
Haskell 人刚刚发布了一些关于 8 核并行性能的惊人结果。请参阅 haskell.org/~simonmar/bib/bib.html 上的“多核 Haskell 的运行时支持”
@sblom：我认为 James 指的是编译。 OCaml 可以并行编译，但 F# 不能。

【解决方案7】：

这与 OP 关于是否学习 F# 的问题没有直接关系，而是一个真实世界 OCaml 在金融领域使用的示例： http://ocaml.janestreet.com/?q=node/61

非常有趣的谈话。

【讨论】：

恕我直言，F# 将成为金融领域的 Java - bit.ly/c87Yoi

【解决方案8】：

就寿命而言，很难判断语言的受欢迎程度，但在这里快速检查一下，这些是用适当（功能）语言标记的问题的数量：-

2672 斯卡拉， 1936 年哈斯克尔，第1674章第1126章 709计划，第332章

我想说这很好地表明了人们目前正在积极学习哪些语言，因此可能很好地表明了哪些语言在未来几年可能会流行。

【讨论】：