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

问题描述

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

• 长寿
  
  

  
  
  • 哪种语言会持续更久？我不想学习用户和开发人员可能会在几年内放弃的东西。
  
  
  • 从长远来看，Inria，Microsoft，格拉斯哥大学是否会继续支持他们各自的编译器？

  • 实用性

    
    
    
    
    
    • 类似让我不敢使用Haskell。哈希表是快速检索的最佳结构。那里的Haskell支持者建议使用Data.Map，它是一棵二叉树。
    
    
    • 我不喜欢绑定到笨重的.NET框架，除非它的优势很大。
    
    
    • 我希望能够开发更多只是解析器和数学程序。
      
  
  

  • 精心设计
    
    

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

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

  解决方案

  
  

  长寿
  

  
  
  

  
  

  • Haskell实际上是功能编程研究的主要语言。 Haskell 98将以稳定的形式持续多年，而Haskell可能会持续10到30年 - 尽管语言将继续发展。社区对Haskell进行了重大投资，即使主要的GHC开发者明天被公共汽车撞上（着名的在剑桥出现的公交误差问题），也有很多其他人可以上台。还有其他一些不太复杂的编译器。

  Caml由法国国家实验室INRIA的一个小组控制。他们也有很大的投资，其他人也投资于Caml，代码是开源的，编译器不是太复杂，所以也会长期维护。我预测Caml将比Haskell更加稳定，因为INRIA人们似乎不再将其用作探索新语言理念的工具（或者至少他们以比过去更小的速度进行）。 p>
  

  • 谁知道公司会做什么？如果F＃成功，微软可以支持它20年。如果它不成功，他们可能会在2012年推出插件。我无法猜测，也不会尝试。

  
  
  
  
  < blockquote>
  

  实用性
  
  

  
  

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

  
  

  这取决于什么你正在寻找。当你的密钥是字符串时，三元搜索树通常比散列表快。当你的密钥是整数时，Okasaki和Gill的二元帕特里夏树

  a>与哈希竞争。如果你真的想，你可以使用IO monad在Haskell中构建一个哈希表，但是很少需要。
  
  
  

  我认为总会有一个性能损失为懒惰评估。但实用与尽可能快并不相同。以下是关于性能的真实情况：

  
  
  
  
  

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

  
  

  • F＃在中间（谁真的知道.NET和JIT会做什么？）。

  对于Haskell程序来说，预测时间和空间行为是最难的。 Haskell拥有最好的分析工具，从长远来看，这是什么产生最佳表现。
  
  
  
  
  

  
  

  我希望能够开发更多解析器和数学程序。
  

  想要了解Haskell中可能的范围，请查看 xmonad 窗口管理器和大量数据包 at hackage.haskell.org 。

  
  

  我不喜欢绑定到笨重的.NET框架，除非好处很大。

  
  

  我无法评论：
  
  

  
  

  精心设计

  
  

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

  
  

  评估一致性的几点：
  
  

  
  

  • Haskell的具体语法设计得非常好; Haskell委员会所做的工作让我印象深刻。 OCaml语法正常，但比较受到影响。 F＃从Caml核心语法开始，并且有很多相似之处。

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

  • OCaml拥有最简单的类型系统，特别是如果您不写对象和函子（许多Caml程序员不会这样做）吨，尽管如果你写ML的话，我觉得不写函数是件疯狂的事）。 Haskell的类型系统雄心勃勃，功能强大，但它不断得到改进，这意味着由于历史原因存在一些不一致。 F＃基本上使用.NET类型系统，加上类似Hindley-Milner的ML多态性（请参阅问题什么是Hindley -Milner。）

  
  

  • OCaml在它认为变体是静态类型还是动态类型方面并不完全一致，所以它提供了代数数据类型和多态变体）。由此产生的语言具有很强的表现力，这对专家来说非常有用，但是对于业余爱好者来说，使用哪种结构并不总是显而易见的。

  评估是官方未定义的，对于有副作用的语言来说，这是一个糟糕的设计选择。更糟糕的是，这些实现不一致：字节编码的虚拟机使用一个命令，而本地代码编译器使用另一个命令。
  

  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:

  • Longevity

    • Which language will last longer? I don't want to learn something that might be abandoned in a couple years by users and developers.
    • Will Inria, Microsoft, University of Glasgow continue to support their respective compilers for the long run?

  • Practicality

    • 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.

  • Well Designed

    • I like my languages to be consistent.

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

  解决方案

  Longevity

  • 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 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).

  • 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.

  Practicality

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

  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:

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

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

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

  • 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.

  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.

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

  I can't comment:

  Well Designed

  I like my languages to be consistent.

  Some points on which to evaluate consistency:

  • 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 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 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 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'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屋！