I know this is an old thread, but I can't help but throw in my 2 cents on ocaml's popularity. I'm relatively new to ocaml, but I have experience with many other languages, and think that I have a good sense for the new-comer's perspective. Here's my take:

1. I agree that the major factor is lack of industry backing. Java is successful because of Sun's marketing muscle. Same goes for C#/Microsoft.

2. Lack of university backing. Although there is a lot more support for ocaml at universities, there's still a large degree of fragmentation in terms of languages used for teaching: java, scheme, haskell, etc. Lack of knowledgeable students leads to a lack of demand for ocaml by industry people.

3. Difficulty to learn. I don't really think ocaml is that difficult to learn, but there are two main factors:

    (a) it's "different enough" from most languages that people are familiar with and many people are too lazy or impatient to wade through the differences to make it to the rewards, and

    (b) often the introductory treatments have an academic slant rather than a get-things-done approach (already mentioned in this thread -- need for "cookbook"). Ocaml is really much better than other "academic" languages in this regard (I find the O'Reilly book very pragmatic and not sure why so many people seem to love to hate it). I mean at least you don't need to understand monads to get useful work done in ocaml.

4. Tools. Lack of proper tools is the downfall of many languages. Although ocaml is really quite good in this dept, the major flaws are lack of a debugger on win32, and lack of an IDE (yes, there's emacs, and some integration with VC6, but it's far from what your typical Visual Studio guy is looking for).

About the debugger:

First I'll say that the debugger isn't nearly as necessary in ocaml for several reasons:

    (a) There's a read-eval-print loop (REPL) that can be used for interactive testing and development. This allows programs to be built from the bottom-up, verifying the smallest pieces first before building things that depend on them. This is the same as lisp/scheme/python/perl/js, and in stark contrast to C++/Java/C# where you often need to write a large part of the program (and lots of boilerplate) to get to the point where you can test anything.

    (b) The fact that in the REPL you don't need to specify types further lends itself to interactive development (again, in contrast to Java).

    (c) All data types can be used as literals, and printed to the console further aids interactive development.

    (d) Pretty-printing and the formatter are great tools, make things easier to read, and are very easy to use.

The reason for the lack of the debugger on Windows is the lack of fork/exec primitives, and these are used to implement checkpoints (ability to roll back to a previous debugger state). Although this is a nice feature, I for one don't find it that useful -- primarily because with every other debugger I've used I get used to putting breakpoints in places where I need to begin paying attention, or at least, I can restart the computationfrom the beginning to get back to an earlier point. I think most programmers would agree with this.

    (I'm not sure if there isn't a slight anti-Windows bias in the ocaml community, but I think there are two potentially conflicting goals for ocaml: (1) promoting an alternative to the dominant platform by offering ocaml as a better tool/language for Linux and open source development, or (2) promoting wide-scale adoption of ocaml language in general, which means making it work well on the dominant platform.)

5. Learning the language. Here's where I'll list what I think is "different enough" about the language that keeps people from using it:

    (a) Syntax of types -- in particular use of * and ->. I know where they come from, why they're good, etc, but I know they put some people off. This is compounded by type variables prepended with apostrophes and postfix type functions. Also currying is foreign to most people -- the fact that functions return functions that take more arguments. On the surface this must seem useless, and inefficient (although once you understand the power you'll wonder how you lived without them).

At the very least, I think ocaml type expressions would benefit from the ability to label arguments with symbolic names. This would aid in understanding. E.g.

    val assoc : 'a -> ('a * 'b) list -> 'b

might be expressed as:

    val assoc(key:'a) : fun(l: list(key:'a, value:'b)) : (value:'b)

(Just a suggestion -- I know this is more verbose, but if it makes the language easier to learn it might be a good thing.)

    (b) Constructors, patterns and values. This is no doubt one of the great things about ocaml -- the fact that these three things are expressed uniformly, i.e. that I can construct one by saying Foo(x), match and destructure by saying Foo(x), or return a value and see it print out as Foo(x). But to the beginner these three distinct things might be confused. People are very used to seeing "new" in front of constructors, and pulling apart nested structures one dereference at a time. So I believe this is one reason why ocaml is different/hard to learn.

    (c) Union types. (Or do you call them sums?) It's probably also lost on many newcomers how great unions are in ocaml -- the fact that the compiler will tell you all the functions that need to handle a new constructor of the union when it's introduced (as long as you don't add catch-all patterns), and how the pattern-matching cases are checked exhaustively. Unions seem to suffice for 99% of the things that people use OOP for (representing cases as disjunctive function clauses rather than methods on classes) -- but without all the boilerplate. Unions are great, but foreign to newcomers, and unwelcome to those that think they only want OOP.

    (Perhaps some sort of document is in order that shows exactly the class of problems that requires overloaded methods, distinguishing this from the cases where choosing ocaml's object system over union types is simply a matter of taste to the programmer. Or better yet, a document that describes how numerous problems expressed in Java or C++ can be better (more concisely and efficiently) expressed with unions.)

    (d) Heavy reliance on recursion. Although ocaml provides some iterative constructs, for many things you still need to write recursive functions. Fortunately, due to tail recursion elimination and a very good compiler, recursion is very efficient in ocaml, but nonetheless it requires programmers to contort their normal way of thinking about common program idioms. Higher-order functional library routines also fill the gap when iterative constructs are often used, but for whatever reason, most people don't think in terms of List.map or Array.iter. I think ocaml would benefit from a little more syntactic sugar in this dept:

    for x in l do e       == List.iter (fun x -> e) l
    for x in l collect e  == List.map (fun x -> e) l

    (e) Assignment and mutability. The first hurdle is that people often think ocaml is a "functional language," doesn't have assignment, and consequently isn't practical. If they get past this, they may find that refs require some change in the way you think about assignment. Programmers are used to dealing with references and dereferencing when pointers are involved, but for ordinary data types like int, bool and char they think of variables being mutable or "const". Although ocaml's treatment of references is more consistent, it presents a slight rethinking. Also, ocaml's mutable record fields further confounds the problem because unlike ordinary lexical variables, they can be modified. Perhaps ocaml should consider adding mutable local variables:

    let sum_until n =
      let mutable sum = 0 in
        for i = 0 to n-1 do
          sum <- sum + i
        done;
        sum

    (f) Type-checker error messages. When something fails to type check in ocaml, the error messages can be uninformative or confusing. Often times the source of a type constraint is far removed from the location where the problem is reported. Showing the source of the constraint would be very helpful. Also, often times the type conflict that's reported fails to narrow down the conflict sufficiently. It would be very helpful if the expected and actual type expressions were unified in some way to pinpoint the exact discrepancy.

    (g) Module system. Once you become proficient in the base language, you move on to the module system, with it's own learning curve. For instance, the beginner may wonder why they need to redefine all the types in the mli file again in the corresponding ml file (not something you have to do with import/include file in Java/C++). They may also be confused by the difference between a a functor that takes a type as a parameter, and a module struct specialized by a 'with' type constraint (ok, maybe I'm the only one confused by the difference here).