It may be the case that there are truly excellent resources for learning OCaml, but I know the language, and I've never heard of them. There's Jason Hickey's tutorial, an introduction or two scattered around the internet, and some book that was fan-translated from French, sure, but OCaml lacks the hackerly dialogue that typifies discussion of languages like Haskell. It is a problem, for example, that these usually very incomplete hobbyist-curated tutorials almost always outstrip the professional literature: when people do publish books about OCaml, they are often littered with errors or flat-out wrong (I'm looking at you, Practical OCaml).
Regardless of whether we can all get on board with asynchronous whatever, or pronouncements about its "real" speed, or whether it should be used when Haskell is around, it is clear that there is a huge divide between the people who actually can argue these things well, and those who cannot, and switching from the first group to the second by yourself is tempestuous and trying. Is it the case that there are no OCaml experts in the world? If you are going by the amount of information on the Internet, it is not really obvious that this is actually the case. How can you, then, become one?
Besides that, though, having a sound OCaml counterpoint will do communities like Haskell good. I hope this finally ushers in the golden era of learning OCaml. Not everyone can take CS51 at Harvard, and besides, the credulity of a real (and good?) book about OCaml will hopefully advance the dialogue further than the typical questions of whether it can actually be done in X, Y and Z enterprise environments. That is a debate I (and probably many OCaml fans) have heard enough of.
I'm reviewing drafts of Real World OCaml too, but after the sheer amount of work (and what went wrong) with P.O., I'm just going to informally comment on them.
OCaml as a language is extremely useful and practical. A good book on it really needs to be written.
Also, OCaml is spelled "F#" in English.
EDIT: it was already posted below.
I just wish there was an SML for the JVM. But until then Ocaml is probably the gear and I look forward to reading this book.
And, oh my golly, have you seen OCaml's Eliom for Ocsigen? Absurdly interesting. http://ocsigen.org/eliom/ One language for the browser and server, with client/server transparency and best-in-class server performance.
i) It needs better libraries, or perhaps better library documentation. A full hour of my time was spent working out how to read lines from a file.
ii) It is a beautiful language. The code I wrote, as someone completely new to the language and not using any libraries, was much shorter than the equivalent code I would have written in Python, a language which I know much better, and an order of magnitude shorter than what I would have written in Java or C. It makes functional abstraction easy in the same way that Haskell does, but the ability to mix in imperative code if it gets the job done in fewer lines (or in a less mind-bending way) is supremely useful.
Edit: By 'production work' I meant built things that are being used by other people.
TL;DR: Jane Street is a quantitative trading firm whose language of choice is OCaml and has several people programming in it full-time. Besides experiencing the commonly-cited advantages of FP (productivity, expressiveness, local reasoning), they also found it highly performant, useful for rapid prototyping and resilient to changing requirements.
There's also a list of companies using it here: http://ffconsultancy.com/products/ocaml_journal/free/introdu...
* generating code, bindings etc in libguestfs (http://libguestfs.org/)
* analysing Windows Registries for hivex, using ocaml-bitstring
There are other differences as well, but imho that one sets Haskell apart moreso than any of the others, and not just from Ocaml but from every other language (that I know of at least).
(yes, from 1998, but worth the PS conversion if youre on windows)
If they actually have event driven programming that seems like a big step over most functional languages, where I/O is kind of an afterthought.
Steve Yegge wrote some points about Ocaml quite awhile ago. http://sites.google.com/site/steveyegge2/ocaml He says it is quite fast and I've seen that in other places.
The thing I don't like about competing with C/C++ in "fast" is that those languages invariably are memory hogs. They hide that in the benchmarks.
Anyone know if you have control over memory layout in Ocaml? Or if you can reason about it like you can in C/C++?
There are several event-driven programming libraries in OCaml, and two that I like that use monadic abstractions (to hide the messy control flow that makes node.js so painful) are Async (https://ocaml.janestreet.com/?q=node%2F100) and Lwt (http://ocsigen.org).
You have good low-level memory layout in OCaml, either via an FFI or the Ancient module to import in non-GCed values. You can read about the OCaml heap and GC at this blog series by Richard Jones. http://rwmj.wordpress.com/2009/08/04/ocaml-internals/ (and yes, the memory representation is a straightforward mapping from the type declaration; very little magic happens in the compiler)
OCaml is used all over the Xen Cloud Platform (http://github.com/xen-org/xen-api), and I'm running an ongoing microkernel research project called Mirage (http://www.openmirage.org) which has a full network stack written in pure OCaml (and is also competitive performance-wise).
I have been meaning to give OCaml a try for awhile but it's bumped on my list now. (Though it seems that the thing that people keep complaining about is lack of a polymorphic print...)
The biggest issue Ocaml has is that its GC is single-threaded which basically removes the ability to do parallel programming inside a single executable. You have to resort to message passing between multiple processes.
For what it's worth, I think I heard rumors there's work on an improved GC.
# print_endline (String.uppercase "Jérôme");;
I really like OCaml, it's probably my favorite language, and I hope that RWO will increase its popularity and that this will in turn help improve the language. I'm reading a lot about Haskell these because of the times when I want to do some multi-programming with unicode text.
Hoare's CSP pretty much takes this approach, and for my money, I think that sort of approach makes the common case of parallel programming easier.
I think this is going to turn out to be a killer feature of Ocaml once people get used to the fact that using 8 cores at once isn't that great of a goal when on-demand computing platforms let you scale much much larger. Pretty soon no one will be all that concerned about how much happens on any one machine. It will be how much gets done per process, and how much gets done per 'cloud'. AppEngine already does this.
And it already is a design feature. The GC is not single threaded b/c they're too dumb to figure out how to fix it (not that you were saying that, but people tend to jump to that conclusion). It's because they want the fastest possible single threaded performance, which means not polluting the GC with the kinds of locking mechanisms necessary to support multi-threaded operation.
I think this point isn't made often enough. There certainly are times when scaling within a single machine is useful but, as is more often the case, if you have to scale beyond a single physical instance you might as well plan for process-oriented parallelism up front.
And the ease of use of multi-process architectures needs to be improved as well.
For the other 20% of the time... threads are awesome. :)
My biggest complaints:
* Poor libraries - This is getting better, but it used to be a real pain to do stuff like make an HTTP request, parse JSON or XML, or connect to a database. They definitely weren't in the stdlib, and it was even pretty hard to find good third party libraries for it.
* Awkward library interfaces - Even the libraries that are included are awkward to use, like the Set and Map.
* Poor documentation - There's nothing (or was nothing) like http://perldoc.perl.org/ or http://docs.python.org/
And, off-hand, one language nitpick:
* Poorly handled strong typing - For example '+' is used to add integers while '+.' is used to add floats. The underlying reason makes sense, but there's awkward stuff like that all over. Haskell handles it better, IMO.
This is something I have been working on http://gaiustech.github.com/ociml/
Of the 8 most frequently encountered FP languages (clojure, scheme, CL) (haskell, ocaml, F#, erlang, scala) all have at least a handful of good intro texts, plus a few intermediate +.