Lots of great stuff happening in the Haskell community at the moment. What is it they're doing that the OCaml crowd aren't? This is a genuine question, I want to know so we can do it too...
The OCaml community doesn't have anybody who promotes the language with quite as much gusto as dons, to my knowledge, and its library situation is a bit messy - there are nonstandard community replacements for the standard library[1] because Inria is just not going to fix some major warts. It has libraries[2] (and a pretty good library manager[3]), but OCaml has been around for quite a while and hasn't ever seemed to aquire critical mass. That degree of blatant fragmentation probably makes people wary.
Haskell seems to be stealing its thunder now. There are numerous "intro to Haskell" / monad tutorial / etc. articles out there, and the OCaml community seems very quiet, by comparison. I don't particularly care for Haskell* , but its designers and users have done a good job of ensuring people hear about it, and get at least a roughly accurate first impression of what makes it noteworthy.
* I don't like laziness as a default, I've been burned a couple times by portability issues (and the way that "whatever GHC does right now" has become a de-facto standard means that portability issues are probably not a priority), and it's academia-centric "avoid success at all costs" attitude doesn't sit right with me.
I, for one, adore the "avoid success at all costs" attitude
The trappings of success for programming languages are pain and suffering, having your community inundated with incurious idiots, losing the ability to do anything new and cool because you have to maintain stability for the horde.
Witness Alan Kay's experience with Smalltalk -- he was forced to fork himself and start over every time he succeeded in getting users.
It's a great stance for a language that focusing primarily on research and innovation, but it does put a damper on getting things done sometimes. Some stability and concessions to practicality go a long way.
I think that having a clean break at major revisions (e.g. Python 3, Lua 4.0 to Lua 5.0) and cleaning up cruft is probably a reasonable approach, as long as it's handled carefully and half the community doesn't stay with the old version. (It was easier with Lua because it's so small, and usually embedded in something else.)
"I've been burned a couple times by portability issues (and the way that "whatever GHC does right now" has become a de-facto standard means that portability issues are probably not a priority)"
I am interested in this issue and would love to hear more details. Portability between different Haskell implementations or portability of GHC to different operating systems?
In the early years of Haskell there were a number of implementations experimenting with different things, and eventually the surviving ones converged on a standard -- Haskell 98.
Since then (especially in the last 5 years), the GHC community has been regularly releasing all sorts of shiny new toys -- obviously introducing features unsupported by other implementations, but also frequently breaking compatibility with their own previous implementations. OS portability has not been much of an issue.
Haskell Prime is an effort underway by the GHC guys to not only define a new set of standard libraries, but to make Python3000-style purposefully incompatible changes to the core language. This is hoped to become a new standard, Haskell 2010.
I should preface this by noting that I haven't looked into the situation recently, and the problem may have been fixed, but it really soured me on Haskell. (At a glance, it looks the same, and discussions with a presenter at a local barcamp implied no real change.) I stopped worrying about it because I'm quite content with Lua for small personal projects, and OCaml and Erlang seem to be more my style than Haskell for larger ones.
So, that said: I primarily use OpenBSD and FreeBSD, and bootstrapping recent versions of GHC from source has been broken for a long time. OpenBSD's current GHC is 6.6.1, and FreeBSD's is 6.8.x, but (last time I checked) was marked as broken. While porting language runtimes to OpenBSD can be tricky due to e.g. its randomized malloc, an open-source language that doesn't even build from source on FreeBSD probably doesn't place much of a priority on portability. GHC 6.6.1's ghci segfaults on my openbsd/amd64 system, too.
Just after I got settled with XMonad, GHC updated without a clear plan for source bootstrapping. I get the impression that a lot of people just use Debian/Arch/etc., like dons did[1]. (I'm a (somewhat minor) OpenBSD porter, so I probably care about this more than many people.)
Here's a Hackage bug ticket, closed after a year and a half with the note that they're probably just not going to support building that way anymore:(http://hackage.haskell.org/trac/ghc/ticket/1346). It's not hard to find griping about the situation on the openbsd-ports list.
While GHC is just one compiler (and I've put some time into helping with updating Common Lisp and Scheme ports in the past, due to similar issues), Haskell programmers seem to assume a recent version of GHC and its extensions, making "whatever GHC does" a de-facto standard. That rules it out for me entirely, and I wonder if anybody else feels the same.
What's also weird is that OCaml doesn't even have a big following in France, the French are well-known for championing their own ideas in the face of whatever Les Rosbifs are doing.
I get the impression that it may have been more popular several years ago - OCaml, Caml Light, and predecessors have been around for a rather long time, and have been used in education. It has a long, parallel history to SML.
I'm not sure about the above because I can't read French, but I remember reading it somewhere relatively 'official'. (Perhaps in the translated O'Reilly book?) Either way, having half the stuff written about your language only available in French is probably not a strong life sign.
Fundamentally, I think it is the cathedral (INRIA) vs the bazaar (Haskell.org open source) leading to long term efficiencies for the Haskell community.
Also, the OCaml community seems more fragmented, so its harder to organize group efforts. Haskell hackathons are happening every 4 months or so, in the US and Europe (we've had 9 in 3 years). I don't know that the OCaml open source community has held any similar kind of event.
OCaml is a well designed, well implemented language.
Unfortunately, it sits at an unstable point in language design space. If you like it because it's practical, there are other languages (C++ and Java) that are even more practical. If you like it because it's functional, there are other languages (Haskell, Erlang) that are even more functional. If you like it for being ML with objects, then you would probably like F# even better. And so forth.
The result is that there just aren't that many people who like Ocaml more than another language.
I was working on a project in Fortran. I recommended OCaml, saying that it had all the same capabilities as Fortran (high performance, portability, compiling to native code, support for similar programming style) but also had additional features that would make me more productive. OCaml's position in language design space was perfect for a project in which a functional programmer would be doing most of the work, but a client felt more comfortable with something Fortran-like, in case he ever had to maintain it himself.
If I were making the decision completely on my own, I would prefer Haskell, but in-between languages like OCaml can make good compromise options. I also learned OCaml before Haskell, and consider it to have been a good stepping stone.
OCaml works well as a multiparadigm language. While it has some implementation quirks* , I like that its design doesn't force a pure functional approach. There's a quote in the French O'Reilly book, something like "Write your code in the style that is most natural, and give it a functional interface.". It seems like a good summary of the direction the language design points. (I just think there's a smaller, cleaner language buried inside OCaml...) Being "in between" can sometimes be a major strength.
* In particular, adding typeclasses would nicely resolve several minor annoyances with the languags.
