This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

3

That's a bizarre article about Haskell. A language where you can't make a fast hash table? I'm not some performance stickler, but a hash table is kind of a first class data structure.
–
mquanderMay 5 '09 at 0:20

@mquander yep, I use hash tables all the time in other languages. Also note that the article is only from April and GHC is pretty old.
–
UnknownMay 5 '09 at 0:25

10

Use Data.IntMap, or one of the hashtable libraries on Hackage, if you have a particular problem that requires "hashing".
–
Don StewartMay 5 '09 at 7:06

6

The whole hash table thing has been blown way out of proportion. The fact is, .NET has automatic unboxing, which its hash table implementation uses to great effect, and you can write benchmarks to show that. If your problem fits that pattern, or you can make it do so, then you'll get (much) better performance from .NET than Haskell's Data.Hash library. The problem comes when you try to draw general conclusions from this: there aren't any to draw, beyond what I've said. Also take a look at the Haskell hashmap library.
–
Simon MarlowAug 13 '10 at 11:42

@Simon: "when you try to draw general conclusions from this: there aren't any to draw, beyond what I've said". Haskell seems to be slower for several general reasons: a perf bug in the GC (writing an element into a mutable array dirtied the whole array), lack of value types and boxing for parametric polymorphism.
–
Jon HarropAug 25 '10 at 15:25

8 Answers
8

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.

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.

Some good points but: your advice about the performance of trees vs hash tables is misleading. Your assertion that Haskell has better profiling support than .NET is absurd. Your assertion that many OCaml programmers ignore objects and functors is wrong (you cannot even use Set and Map otherwise and several of OCaml's most popular libraries rely heavily upon objects) and you've neglected polymorphic variants, which are one of OCaml's greatest advantages over other statically-typed FPLs. Your assertion about OCaml's evaluation order being "inconsistent" is wrong: it has always been undefined.
–
Jon HarropMay 6 '09 at 0:05

6

I've started learning a little more about Haskell, and found out that the syntax is so_much_better than OCaml. But I still don't like lazy evaulation by default, and the hash table stuff still bothers me. So as a result, I am still torn between these languages.
–
UnknownMay 7 '09 at 2:00

8

@Jon Harrop (profiling support in GHC and .NET): what does .NET offer that is as good as GHC's cost centers and GHC's heap profiler?
–
Norman RamseyMay 7 '09 at 2:54

3

@Jon Harrop (do many OCaml programmers ignore objects and functors?): while I myself love functors and hate objects, as you'll learn if you read my ML papers, when I attend the International Conference on Functional Programming I routinely hear comments like "I never saw an object or a functor I liked".
–
Norman RamseyMay 7 '09 at 2:56

6

@Unknown: It took me about 5 years to stop worrying and learn to like lazy evlauation by default, and it wasn't until I got a few big wins in large programs where I hadn't planned in advance for structures to be lazy. So I sympathize. For the hash table I think you'll be hard pressed to find an app where it matters.
–
Norman RamseyMay 7 '09 at 3:06

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Voting down because Jon changed what used to be a reasonable answer.
–
Reid BartonMay 19 '10 at 23:51

11

Reid is right about this. Examine the history of this post and you'll see a sharp about-face from an even-handed approach to a combination of boosterism and FUD. True, F# has a strong built-in base being a .NET language, but the original version of this post had it right -- there's no evidence that OCaml or Haskell, both of which have growing userbases and popularity, are going anywhere.
–
sclvJun 23 '10 at 18:47

12

Voting down. Amongst other inaccuracies, I don't know of any evidence for these remarks: ".. the massive amounts of unnecessary copying it incurs hits the memory wall and destroys any hope of scalable parallelism on a multicore." Garbage collectors can be built that perform very well on multicores, and it's been known how to do so for some time (see e.g. citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.52.9494). The fact is, to take advantage of designs like this you need a majority of immutable data, i.e. a functional programming language.
–
Simon MarlowAug 13 '10 at 11:57

9

@Jon you missed the point. The paper describes a GC architecture that does local per-CPU GC in the young generation, which is an effective design for multicore. A variation of this design has been shown to work in Manticore. I didn't say we did it in GHC, though it would be a logical next step for us (we don't "copy their basic architecture", have you read the papers?). Note how immutability becomes really important for doing local GC, much more so than in generational GC: it's my guess this is why the "industrial strength" GCs in .NET and JVMs haven't implemented it.
–
Simon MarlowAug 14 '10 at 19:52

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.

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.

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

Well the thing about being tied to the big bulky .NET, is that it forces you to bundle with it on purpose, instead of only selectively including the libraries you use.
–
UnknownMay 5 '09 at 8:17

3

Well, technically F# forces you to bundle .NET but in reality it will already be there before you. It is kind of like saying that it forces you to bundle Windows. Also, if you use Mono, they have a tool that lets you select only the functionality you are using. This is useful on the Mac where you include the supporting libraries into an app bundle (Mono is likely not already installed).
–
JustinNov 14 '10 at 18:29

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.

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.

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.

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.

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.

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.

But the problem is that I would rather have O(1) access. O(log n) access for a large set is ridiculous. It doesn't matter if you have a persistent tree, because you can sure have a persistent hash table.
–
UnknownMay 5 '09 at 1:12

1

If you just want O(1) because it sounds good, then as another poster said feel free to use a hashtable in Haskell, even though it's not a great fit. My point was that a language with lazy evaluation and no side-effects really begs for persistent data structures (en.wikipedia.org/wiki/Persistent_data_structure). This is a powerful idea and worth some study and reflection. In my opinion this is more important than O(1) vs. O(log n), and it's certainly more important than somebody's random timing exercise. Say it with me: "micro-benchmarks are evil!"
–
Moss PrescottMay 5 '09 at 5:06

@Moss, unfortunately, I have run into plenty of situations where the difference between O(k) and O(log n) where k is from 1-20 and n is in the hundreds of thousands. I quite seriously doubt that "persistent data structure" is a legitimate excuse for not having a decent hash table. If you can have persistent trees, why not have persistent hash tables?
–
UnknownMay 5 '09 at 7:14

I guess the short answer is that the conventional wisdom says you can't (easily) implement a persistent hashtable with good performance, but now I see that not everyone agrees on that point, so here are a couple of links for anyone who's reading: en.wikipedia.org/wiki/Purely_functional (this includes a link to Chris Okasaki's thesis -- everyone out there: stop reading this thread and go read the thesis or the book version right now!) A posting by LtU regular cdiggins taking the contrarian position: artima.com/forums/flat.jsp?forum=106&thread=137924 Also, log 100k = 17.
–
Moss PrescottMay 5 '09 at 23:34

F# and OCaml are very similar in syntax, though, obviously, F# is better with .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.

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.

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.

F# has asynchronous workflows, which is admittedly pretty nice for doing parallelisation. Nonetheless, with Parallel Extensions appearing in the .NET Framework 4.0, I would argue that realtively easy OOP on multiple cores is just around the corner.
–
NoldorinMay 5 '09 at 0:46

Not sure what you mean by F# not using all the processors on a machine. I have no trouble getting F# code to load to 100%. Depends on what I'm doing.
–
sblomMay 5 '09 at 1:03

There was an article I read a few months ago where the author mentioned that unlike OCaml, F# didn't properly use all eight of his processors. My laptop doesn't have that, so I can't verify, but I expect it was due to the version that was being used, and I figured it would be fixed when it was a high enough priority.
–
James BlackMay 5 '09 at 1:46

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 :-