如果我已经知道了OCaml，我应该学习Haskell或f#吗?

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

我想知道我是否应该继续学习OCaml或者切换到f#或者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?
  • Inria，微软，格拉斯哥大学是否会继续长期支持他们各自的编译器?

• 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.
  • 像这样的文章让我害怕使用Haskell。哈希表是快速检索的最佳结构。Haskell的支持者建议使用数据。映射是一个二叉树。
  • I don't like being tied to a bulky .NET framework unless the benefits are large.
  • 我不喜欢被捆绑在一个庞大的。net框架，除非它的好处很大。
  • 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.

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

8 个解决方案

#1

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.

  Haskell实际上是函数式编程研究的主导语言。Haskell 98将以稳定的形式持续很多年，而Haskell可能会持续10到30年——尽管语言将继续进化。社区在Haskell有一个重大的投资，即使主要的GHC开发人员明天被一辆公共汽车撞了(著名的“剑桥的公共汽车错误”问题)，也有很多人可以站出来。还有其他不那么复杂的编译器。

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

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

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

  谁知道一家公司会做什么?如果f#成功了，微软可能会支持它20年。如果不成功，他们可能在2012年退出。我猜不出来，也不想尝试。

Practicality

实用性

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

哈希表是快速检索的最佳结构。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.

这取决于你在搜索什么。当你的键是字符串时，三元搜索树通常比哈希表快。当你的键是整数时，冈崎和吉尔的二叉帕特里夏树就可以与散列竞争。如果您真的想这样做，您可以使用IO monad在Haskell中构建一个哈希表，但是很少需要这样做。

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.

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

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

  f#在中间(谁知道。net和JIT会做什么?)

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

  Haskell有最好的分析工具，从长远来看，这是最好的性能。

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.

要了解Haskell中可能存在的范围，请查看xmonad窗口管理器和hackage.haskell.org上的大量软件包。

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

我不喜欢被捆绑在一个庞大的。net框架，除非它的好处很大。

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的具体语法设计得非常好;哈斯卡尔委员会的出色工作给我留下了深刻的印象。OCaml语法是可以的，但是比较起来就比较困难了。f#从Caml核心语法开始，有很多相似之处。

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

  Haskell和OCaml对于操作符重载的描述都非常一致。Haskell有一个持续的、强大的机制，您可以扩展自己。OCaml没有任何超载。

• 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拥有最简单的类型系统，特别是如果您不编写对象和函数(许多Caml程序员都不编写对象和函数)(尽管在我看来，如果您编写ML，那么不编写函数函数似乎很疯狂)。Haskell的类型系统是雄心勃勃和强大的，但是它正在不断地改进，这意味着历史会导致一些不一致。f#本质上使用了。net类型系统，加上与ml相似的Hindley-Milner多态性(参见问题“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认为变量应该是静态类型还是动态类型，因此它同时提供了(“代数数据类型”和“多态变体”)。由此产生的语言有很多表达能力，这对于专家来说是很好的，但是对于业余爱好者来说，使用哪个结构并不总是显而易见的。

• 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的评估顺序是没有定义的，这是一种有副作用的语言的糟糕的设计选择。更糟糕的是，实现是不一致的:字节码虚拟机使用一个顺序，而本机代码编译器使用另一个顺序。

#2

Should you learn F# or Haskell if you know OCaml?

如果你知道OCaml，你应该学f#或者Haskell吗?

I believe the answer is certainly yes, ideally you should learn all three languages because each one has something to offer but F# is the only one with a significant future so, if you can only feasibly learn one language, learn F# by reading my Visual F# 2010 for Technical Computing book or subscribing to our The F#.NET Journal.

我相信答案无疑是肯定的,理想情况下你应该学习三种语言,因为每个人都有一些东西可以提供但是f#是唯一重要的未来,如果你对此只能学习一种语言,学习f#通过阅读我的视觉f# 2010技术计算的书或订阅我们的f#。网络杂志。

Longevity

长寿

Microsoft committed to supporting F# when they released it as part of Visual Studio 2010 in April. So F# is guaranteed a rosy future for at least a few years. With a powerful combination of practically-important features like a high performance native-code REPL, high-level constructs for parallelism built-in to .NET 4 and a production-quality IDE mode, F# is a long way ahead of any other functional programming language in terms of real world applicability now. Frankly, nobody is even working on anything that might be able to compete with F# in the near future. My own open source HLVM project is an attempt to do so but it is far from ready.

微软在4月份发布f#作为Visual Studio 2010的一部分时承诺支持f#。因此，至少在未来几年内，f#将保证一个美好的未来。f#具有强大的实用功能组合，如高性能的本地代码REPL、内置在. net 4中的高级并行构造和高质量的IDE模式，在现实世界的适用性方面，f#远远领先于任何其他函数式编程语言。坦率地说，在不久的将来，甚至没有人从事任何可能与f#竞争的工作。我自己的开源HLVM项目正在尝试这么做，但还远远没有准备好。

In contrast, both OCaml and Haskell are being developed in extremely unproductive directions. This has been killing OCaml for several years now and I expect Haskell to follow suit over the next few years. Most former professional OCaml and Haskell programmers already moved on to F# (e.g. Credit Suisse, Flying Frog Consultancy) and most of the rest will doubtless migrate to more practical alternatives such as Clojure and Scala in the near future.

相比之下，OCaml和Haskell都是在极其低效的方向发展的。这已经杀死OCaml好几年了，我希望Haskell在接下来的几年里也能继续这样做。大多数以前的专业OCaml和Haskell程序员已经转向了f#(例如，瑞士信贷，飞行青蛙咨询公司)，其余的大部分将在不久的将来迁移到Clojure和Scala等更实用的替代品。

Specifically, OCaml's QPL license prevents anyone else from fixing its growing number of fundamental design flaws (16Mb string and array limits on 32-bit machines, no shared-memory parallelism, no value types, parametric polymorphism via type erasure, interpreted REPL, cumbersome FFI etc.) because they must distribute derivative works only in the form of patches to the original and the Debian package maintainers refuse to acknowledge an alternative upstream. The new features being added to the language, such as first-class modules in OCaml 3.12, are nowhere near as valuable as multicore capability would have been.

具体来说,OCaml产品一览表许可阻止其他人修复其越来越多的基本设计缺陷(16 mb字符串和数组在32位机器上限制,没有共享内存并行性,没有值类型,参数多态性通过类型擦除、解释REPL,麻烦FFI等等),因为他们必须分配派生作品只有在补丁到原始的形式和Debian软件包维护人员拒绝承认另一个上游。添加到语言中的新特性，比如OCaml 3.12中的一流模块，远不如多核能力有价值。

Some projects were started in an attempt to save OCaml but they proved to be too little too late. The parallel GC is practically useless and David Teller quit the batteries included project (although it has been picked up and released in a cut-down form). Consequently, OCaml has gone from being the most popular functional language in 2007 to severe decline today, with caml-list traffic down over 50% since 2007.

有些项目是为了拯救OCaml而开始的，但事实证明这些项目太迟了。并行GC实际上是无用的，而且David Teller退出了包括电池在内的项目(尽管它已经被取下来并以精简的形式发布)。因此，OCaml已经从2007年最流行的函数式语言发展到今天的严重衰退，自2007年以来，caml列表的流量下降了50%以上。

Haskell has fewer industrial users than OCaml and, although it does have multicore support, it is still being developed in a very unproductive direction. Haskell is developed almost entirely by two people at Microsoft Research in Cambridge (UK). Despite the fact that purely functional programming is bad for performance by design, they are continuing to try to develop solutions for parallel Haskell aimed at multicores when the massive amounts of unnecessary copying it incurs hits the memory wall and destroys any hope of scalable parallelism on a multicore.

Haskell的工业用户比OCaml少，虽然它有多核支持，但是它仍然在一个非常没有效率的方向上开发。Haskell几乎完全由两个人在剑桥(英国)的微软研究院开发。尽管纯粹的函数式编程在设计上不利于性能，但是当大量不必要的拷贝到达内存壁并破坏在多核上可伸缩并行性的希望时，他们仍在尝试为针对多核的并行Haskell开发解决方案。

The only major user of Haskell in industry is Galois with around 30 full-time Haskell programmers. I doubt they will let Haskell die completely but that does not mean they will develop it into a more generally-useful language.

在业界，Haskell的唯一主要用户是Galois，拥有大约30名全职Haskell程序员。我怀疑他们是否会完全放弃Haskell，但这并不意味着他们将把它发展成一种更通用的语言。

Practicality

实用性

I wrote the article you cited about hash tables. They are a good data structure. Other people have referred to purely functional alternatives like ternary trees and Patricia trees but these are usually ~10× slower than hash tables in practice. The reason is simply that cache misses dominate performance concerns today and trees incur an extra O(log n) pointer indirections.

我写了你提到的关于哈希表的文章。它们是一个很好的数据结构。三元等人称为纯粹的功能性替代树木和帕特丽夏树但这些通常~ 10×慢于在实践中哈希表。原因很简单，缓存丢失是当前主要的性能问题，并且树会产生一个额外的O(log n)指针指向。

My personal preference is for optional laziness and optional purity because both are generally counter productive in the real world (e.g. laziness makes performance and memory consumption wildly unpredictable and purity severely degrades average-case performance and makes interoperability a nightmare). I am one of the only people earning a living entirely from functional programming through my own company. Suffice to say, if I thought Haskell were viable I would have diversified into it years ago but I keep choosing not to because I do not believe it is commercially viable.

我个人比较喜欢可选的惰性和可选的纯粹性，因为两者在现实世界中通常都是相反的(例如，惰性使得性能和内存消耗不可预知，纯度严重降低了一般情况下的性能，使互操作性成为一场噩梦)。我是唯一通过我自己的公司通过函数式编程谋生的人之一。我只想说，如果我认为Haskell是可行的，我会在几年前对它进行多样化投资，但我一直选择不这么做，因为我不认为Haskell在商业上是可行的。

You said "I don't like being tied to a bulky .NET framework unless the benefits are large". The benefits are huge. You get a production-quality IDE, a production-quality JIT compiler that performs hugely-effective optimizations like type-specializing generics, production-quality libraries for everything from GUI programming (see Game of Life in 32 lines of F#) to number crunching. But the real benefit of .NET, at least for me, is that you can sell the libraries that you write in F# and earn lots of money. Nobody has ever succeeded selling libraries to OCaml and Haskell programmers (and I am one of the few people to have tried) but F# libraries already sell in significant quantities. So the bulky .NET framework is well worth it if you want to earn a living by writing software.

你说“我不喜欢被束缚在一个庞大的。net框架上，除非它的好处很大”。带来的好处是巨大的。您得到了一个生产质量的IDE，一个生产质量的JIT编译器，它对从GUI编程(参见32行f#的生命游戏)到数字处理的所有内容进行了大量有效的优化，比如类型专门化的泛型、生产质量的库。但是。net的真正好处，至少对我来说，是你可以卖掉用f#编写的库，赚很多钱。没有人成功地将库卖给OCaml和Haskell程序员(我也是为数不多的尝试过的人之一)，但是f#库已经大量出售。因此，如果你想通过编写软件谋生，那么庞大的。net框架是值得的。

Well designed

精心设计的

These languages are all well designed but for different purposes. OCaml is specifically designed for writing theorem provers and Haskell is specifically designed for researching Haskell. F# was designed to address all of the most serious practical problems with OCaml and Haskell such as poor interoperability, lack of concurrent garbage collection and lack of mature modern libraries like WPF in order to bring a productive modern language to a large audience.

这些语言都设计得很好，但用途不同。OCaml是专门为编写定理证明而设计的，Haskell是专门为研究Haskell而设计的。f#的设计目的是解决OCaml和Haskell的所有最严重的实际问题，比如互操作性差、缺乏并发垃圾收集，以及缺乏像WPF这样的成熟现代库，以便为广大读者带来富有成效的现代语言。

#3

This wasn't one of your criteria but have you considered job availability? Haskell currently list 144 jobs on indeed, Ocaml list 12 and C# list 26,000. These numbers are not perfect but I bet you that once F# ships it won't be long before it blows past Haskell and Ocaml in the number of job listings.

这不是你的标准之一，但你考虑过工作机会吗?Haskell目前列出了144个职位，Ocaml列出了12个，c#列出了26000个。这些数字并不完美，但我敢打赌，一旦f#发布，很快就会超过Haskell和Ocaml。

So far every programming language included in Visual Studios has thousands of job listings for it. Seems to me that if you want the best chance to use a functional programming language as your day job then F# will soon be it.

到目前为止，Visual studio中包含的每一种编程语言都有数以千计的招聘信息。在我看来，如果你想要最好的机会使用函数式编程语言作为你的日常工作，那么f#很快就会出现。

#4

Longevity

长寿

No one can predict the future, but

没有人能预测未来，但是

• OCaml and Haskell have been surving well for a number of years, which bodes well for their future
• 奥坎姆和哈斯卡尔多年来一直都很健康，这对他们的未来是个好兆头
• when F# ships with VS2010, MS will have legal obligations to support it for at least 5 years
• 当f#与VS2010一起发布时，MS将有法律义务支持它至少5年

Practicality

实用性

Perf: I don't have enough first-hand experience with Haskell, but based on second-hand and third-hand info, I think OCaml or F# are more pragmatic, in the sense that I think it is unlikely you'll be able to get the same run-time perf in Haskell that you do in OCaml of F#.

性能:我没有足够的第一手经验Haskell,但是基于二手三手的信息,我认为OCaml或f#更务实,在某种意义上,我认为这是不太可能你可以得到相同的运行时性能在Haskell中你OCaml f#。

Libraries: Easy access to the .Net Framework is a huge benefit of F#. You can view it as being "tied to this bulky thing" if you like, but don't forget that "you have access to a huge bulky library of often incredibly useful stuff". The 'connectivity' to .Net is one of the big selling points for F#. F# is younger and so has fewer third-party libraries, but there is already e.g. FsCheck, FParsec, Fake, and a bunch of others, in addition to the libraries "in the box" on .Net.

库:易于访问。net框架是f#的巨大好处。如果你喜欢，你可以把它看成是“与这个笨重的东西捆绑在一起”，但是不要忘记“你可以使用一个庞大的图书馆，里面有很多非常有用的东西”。与。net的“连接”是f#的一大卖点。f#更年轻，第三方库也更少，但是已经有了FsCheck、FParsec、Fake和其他一些例子，除了。net上的“盒子”库之外。

Tooling: I don't have enough personal experience to compare, but I think the VS integration with F# is superior to anything you'll find for OCaml/Haskell today (and F# will continue to improve a bit here over the next year).

工具:我没有足够的个人经验来进行比较，但是我认为VS与f#的集成优于您今天在OCaml/Haskell中可以找到的任何东西(f#将在明年继续改进)。

Change: F# is still changing as it approaches its first supported release in VS2010, so there are some breaking changes to language/library you may have to endure in the near future.

变化:f#在VS2010的第一个受支持的版本中仍然在变化，因此在不久的将来，您可能不得不忍受对语言/库的一些重大变化。

Well Designed

精心设计的

Haskell is definitely beautiful and consistent. I don't know enough OCaml but my hunch is it is similarly attractive. I think that F# is 'bigger' than either of those, which means more dusty corners and inconsistencies (largely as a result of mediating the impedence mismatch between FP and .Net), but overall F# still feels 'clean' to me, and the inconsistencies that do exist are at least well-reasoned/intentioned.

哈斯卡尔绝对是美丽和一贯的。我不太了解OCaml，但我的直觉是它同样具有吸引力。我认为f#比这两个都“大”，这意味着更多的灰尘和不一致(主要是由于在FP和。net之间的冲动不匹配)，但是总的来说f#对我来说仍然是“干净的”，并且存在的不一致至少是合理的/有意图的。

Overall

整体

In my opinion you will be in 'good shape' knowing any of these three languages well. If you know a big long-term project you want to use it for, one may stand out, but I think many of the skills will be transferable (more easily between F# and OCaml than to/from Haskell, but also more easily among any of these three than with, say, Java).

在我看来，你会很好地掌握这三种语言中的任何一种。如果你知道你想用它来做一个长期的大项目，你可能会脱颖而出，但是我认为很多技能是可以转移的(在f#和OCaml之间比在Haskell之间更容易，但是在这三者中也比在Java之间更容易)。

#5

There's no simple answer to that question, but here are some things to consider:

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

Haskell and OCaml are both mature languages with strong implementations. Actually, there are multiple good implementations of Haskell, but I don't think that's a major point in its favor for your purpose.

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

F# is much younger, and who can predict where Microsoft will decide to take it? How you feel about that depends more on how you feel about Microsoft than anything anyone can tell you about programming languages.

f#要年轻得多，谁能预测微软会在哪里选择它呢?你对此的看法更多地取决于你对微软的看法，而不是任何人对编程语言的看法。

OCaml (or ML in general), is a good practical language choice that supports doing cool functional stuff without forcing you to work in a way that might be uncomfortable. You get the full benefit of things like algebraic data types, pattern matching, type inference, and everybody else's favorite stuff. Oh, and objects.

OCaml(或一般的ML)是一种很好的实用语言选择，它支持做一些很酷的功能工作，而不会迫使您以一种可能不舒服的方式工作。你可以得到诸如代数数据类型、模式匹配、类型推断以及其他所有人最喜欢的东西的全部好处。哦,和对象。

Haskell gives you all that (except objects, pretty much), but also more or less forces you to rethink everything you think you know about programming. This might be a very good thing, if you're looking to learn something new, but it might be more than you want to bite off. I say this as someone who is only maybe halfway along the path to being a productive, happy Haskell programmer.

Haskell提供了所有的东西(除了对象之外)，但也或多或少地迫使您重新考虑您对编程所了解的一切。这可能是一件很好的事情，如果你想学习新的东西，但它可能比你想要的要多。

Both OCaml and Haskell are being used to write lots of different kinds of programs, not just compilers and AI or whatever. Google is your friend.

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

One last note: OCaml gives you hashtable, but it's hardly sensible to use it in code if you really want to embrace functional programming. Persistent trees (like Data.Map) are really the right solution for Haskell, and have lots of nice properties, which is one of the cool things to learn about when you pick up Haskell.

最后要注意的是:OCaml提供了hashtable，但是如果您真的想要使用函数式编程，那么在代码中使用它几乎是不明智的。持久树(如Data.Map)对于Haskell来说是真正的解决方案，并且拥有许多漂亮的属性，这是当您选择Haskell时要学习的一件很酷的事情。

#6

F# and OCaml are very similar in syntax, though, obviously, F# is better with .NET.

f#和OCaml在语法上非常相似，但是很明显，f#在。net中更好。

Which one you learn or use should be dependent on which platform you are aiming for.

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

In VS2010 F# is going to be included, and since it compiles to .NET bytecode, it can be used on a windows OS that supports the .NET version you used for it. This will give you a large area, but there are limits, currently with F# that OCaml don't have, in that F# appears not to take advantage of all the processors on a machine, but, that is probably due to F# still being developed, and this may be a feature that isn't as important yet.

在VS2010中，f#将包括在内，由于它编译成。net字节码，所以可以在windows OS上使用它，它支持您使用的。net版本。这将给你一个大的区域,但也有限制,目前的f# OCaml没有,在f#似乎并不是利用处理器的机器上,但是,这可能是由于f#仍在发展,这可能是一个功能还没有那么重要。

There are other functional languages, such as Erlang that you could look at, but, basically, if you are strong in one FP language then you should be able to pick up another fairly quickly, so, just pick one that you like and try to develop interesting and challenging applications in it.

还有其他函数式语言,例如Erlang,你可以看看,但是,基本上,如果你在一个强大FP语言那么你应该能很快拿起另一个,所以,就选择一个你喜欢的,努力开发有趣和具有挑战性的应用程序。

Eventually language writers will find a way to get OO languages to work well with multi-cores and FP may fall to the wayside again, but, that doesn't appear to be happening anytime soon.

最终，语言编写人员将找到一种方法，使面向对象语言能够在多核环境下正常工作，而FP可能再次被抛弃，但这似乎不会很快发生。

#7

This is not directly related to the OP's question as to whether or not to learn F#, but rather, an example of real world OCaml usage in the financial sector: http://ocaml.janestreet.com/?q=node/61

这与OP的问题没有直接关系，即是否要学习f#，而是一个真实世界的OCaml在金融领域使用的例子:http://ocaml.janestreet.com/?

Very interesting talk.

非常有趣的谈话。

#8

In terms of longevity, it's very difficult to judge popularity of languages, but just doing a quick check on here, these are the numbers of questions tagged with the appropriate (functional) language :-

就寿命而言，很难判断语言的流行程度，但只要在这里快速检查一下，这些就是带有适当(功能)语言的问题的数量:-。

2672 Scala, 1936 Haskell, 1674 F#, 1126 Clojure, 709 Scheme, 332 OCaml

2672 Scala, 1936 Haskell, 1674 F#， 1126 Clojure, 709 Scheme, 332 OCaml

I'd say this was a good indication of which languages people are actively learning at the moment and therefore might be a good indication of which ones might be popular in the next few years.

我想说，这是一个很好的迹象，表明人们目前正在积极学习哪些语言，因此，这可能是一个很好的迹象，表明哪些语言可能在未来几年受到欢迎。