如果我已经知道 OCaml，我应该学习 Haskell 还是 F#? [英] Should I learn Haskell or F# if I already know OCaml?

问题描述

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

I am wondering if I should continue to learn OCaml or switch to F# or Haskell.

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

Here are the criteria I am most interested in:

• 长寿

• 哪种语言会持续更长时间?我不想学习可能在几年内被用户和开发人员放弃的东西.
• 从长远来看，Inria、微软和格拉斯哥大学是否会继续支持各自的编译器?

实用性

• 类似this 让我害怕使用 Haskell.哈希表是快速检索的最佳结构.那里的 Haskell 支持者建议使用 Data.Map，它是一个二叉树.
• 除非好处很大，否则我不喜欢受制于庞大的 .NET 框架.
• 我希望能够开发的不仅仅是解析器和数学程序.

• Articles like this make me afraid to use Haskell. A hash table is the best structure for fast retrieval. Haskell proponents in there suggest using Data.Map which is a binary tree.
• I don't like being tied to a bulky .NET framework unless the benefits are large.
• I want to be able to develop more than just parsers and math programs.

精心设计

• 我喜欢我的语言保持一致.

请用合乎逻辑的论点和文章中的引文来支持您的观点.谢谢.

Please support your opinion with logical arguments and citations from articles. Thank you.

推荐答案

长寿

• Haskell 是事实上函数式编程研究的主要语言.Haskell 98 将以稳定的形式持续很多年，而一种叫做 Haskell 的东西可能会持续 10 到 30 年——尽管该语言将继续发展.社区对 Haskell 进行了大量投资，即使主要的 GHC 开发人员明天被公共汽车撞倒(著名的剑桥公共汽车错误"问题)，也有很多其他人可以挺身而出.还有其他不太复杂的编译器.

  • Haskell is de facto the dominant language of functional-programming research. Haskell 98 will last for many more years in stable form, and something called Haskell may last 10 to 30 years---although the language will continue to evolve. The community has a major investment in Haskell and even if the main GHC developers are hit by a bus tomorrow (the famous "bus error in Cambridge" problem), there are plenty of others who can step up to the plate. There are also other, less elaborate compilers.

    Caml 由法国国家实验室 INRIA 的一个小组控制.他们也有很大的投资，其他人也投资了Caml，而且代码是开源的，编译器也不是太复杂，所以也会长期维护.我预测 Caml 将比 Haskell 稳定得多，因为 INRIA 的人似乎不再使用它作为探索新语言思想的工具(或者至少他们这样做的速度比过去小).

    Caml is controlled by a small group at INRIA, the French national laboratory. They also have a significant investment, Others are also invested in Caml, and the code is open source, and the compiler is not too complicated, so that too will be maintained for a long time. I predict Caml will be much more stable than Haskell, as the INRIA folks appear no longer to be using it as a vehicle for exploring new language ideas (or at least they are doing so at a smaller rate than in the past).

    谁知道公司会做什么?如果 F# 成功，微软可以支持它 20 年.如果不成功，他们可以在 2012 年拔掉插头.我猜不到，也不会尝试.

    Who knows what a company will do? If F# is successful, Microsoft could support it for 20 years. If it is not successful, they could pull the plug in 2012. I can't guess and won't try.

    实用性

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

    A hash table is the best structure for fast retrieval. Haskell proponents in there suggest using Data.Map which is a binary tree.

    这取决于您要搜索的内容.当您的键是字符串时，三元搜索树通常比哈希表快.当您的键是整数时，Okasaki 和 Gill 的 二叉 Patricia 树 与哈希竞争.如果你真的想要，你可以使用 IO monad 在 Haskell 中构建一个哈希表，但很少需要.

    It depends on what you are searching. When your keys are strings, ternary search trees are often faster than hash tables. When your keys are integers, Okasaki and Gill's binary Patricia trees are competitive with hashing. If you really want to, you can build a hash table in Haskell using the IO monad, but it's rare to need to.

    我认为惰性求值总是会有性能损失.但实用"不等于尽可能快".以下关于性能的说法是正确的:

    I think there will always be a performance penalty for lazy evaluation. But "practical" is not the same as "as fast as possible". The following are true about performance:

    • 最容易预测 Caml 程序的时间和空间行为.

    • It is easiest to predict the time and space behavior of a Caml program.

    F# 处于中间位置(谁真的知道 .NET 和 JIT 会做什么?).

    F# is in the middle (who really knows what .NET and the JIT will do?).

    最难预测 Haskell 程序的时间和空间行为.

    It is hardest to predict the time and space behavior of Haskell programs.

    Haskell 拥有最好的分析工具，从长远来看，这是产生最佳性能的工具.

    Haskell has the best profiling tools, and in the long run, this is what yields the best performance.

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

    I want to be able to develop more than just parsers and math programs.

    要了解 Haskell 的可能性范围，请查看 xmonad 窗口管理器和 大量软件包位于 <代码>hackage.haskell.org.

    For an idea of the range of what's possible in Haskell, check out the xmonad window manager and the vast array ofpackages at hackage.haskell.org.

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

    I don't like being tied to a bulky .NET framework unless the benefits are large.

    我无法评论:

    精心设计

    我喜欢我的语言保持一致.

    I like my languages to be consistent.

    评估一致性的一些要点:

    Some points on which to evaluate consistency:

    • Haskell 的具体语法设计得非常好；我一直对 Haskell 委员会所做的出色工作印象深刻.OCaml 语法是可以的，但相比之下却受到了影响.F# 从 Caml 核心语法开始，有很多相似之处.

    • Haskell's concrete syntax is extremely well designed; I'm continually impressed at the good job done by the Haskell committee. OCaml syntax is OK but suffers by comparison. F# started from Caml core syntax and has many similarities.

    Haskell 和 OCaml 都有关于运算符重载的非常一致的故事.Haskell 有一个一致且强大的机制，你可以扩展自己.OCaml 没有任何类型的重载.

    Haskell and OCaml both have very consistent stories about operator overloading. Haskell has a consistent and powerful mechanism you can extend yourself. OCaml has no overloading of any kind.

    OCaml 拥有最简单的类型系统，特别是如果您不编写对象和函子(许多 Caml 程序员不会这样做，尽管在我编写机器学习时不编写函子对我来说似乎很疯狂).Haskell 的类型系统雄心勃勃且功能强大，但它正在不断改进，这意味着由于历史原因存在一些不一致.F# 本质上使用 .NET 类型系统，加上类似 ML 的 Hindley-Milner 多态性(参见问题 什么是 Hindley-米尔纳".)

    OCaml has the simplest type system, especially if you don't write objects and functors (which many Caml programmers don't, although it seems crazy to me not to write functors if you're writing ML). Haskell's type system is ambitious and powerful, but it is continually being improved, which means there is some inconsistency as a result of history. F# essentially uses the .NET type system, plus ML-like Hindley-Milner polymorphism (See question "What is Hindley-Milner".)

    OCaml 在认为变体应该是静态类型还是动态类型方面并不一致，因此它同时提供了(代数数据类型"和多态变体").由此产生的语言具有很强的表达能力，这对专家来说非常有用，但对于业余爱好者来说，使用哪种结构并不总是很明显.

    OCaml is not quite consistent on whether it thinks variants should be statically typed or dynamically typed, so it provides both ("algebraic data types" and "polymorphic variants"). The resulting language has a lot of expressive power, which is great for experts, but which construct to use is not always obvious to the amateur.

    OCaml 的求值顺序是官方未定义的，在具有副作用的语言中这是一个糟糕的设计选择.更糟糕的是，实现不一致:字节码虚拟机使用一种顺序，而本机代码编译器使用另一种.

    OCaml's order of evaluation is officially undefined, which is a poor design choice in a language with side effects. Worse, the implementations are inconsistent: the bytecoded virtual machine uses one order and the native-code compiler uses the other.

    这篇关于如果我已经知道 OCaml，我应该学习 Haskell 还是 F#?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！