Should I learn Haskell or F# if I already know OCaml? [closed]

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

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

Answer 2

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

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

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.

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

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.

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.

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