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.
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.
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.
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 can’t comment:
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.