
Real World Ocaml announced - j2labs
http://realworldocaml.org/
======
antics
Discussions of whether OCaml is "practical" or useful or good aside, this book
really, _really_ needed to be written.

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.

~~~
Drbble
Are OCaml or Haskell taught in CS51 these days? That would be wonderful.
Neither language was used on the general (non-PL theory, except a bit in the
compilers/languages area) CS track in the 90s.

Also, OCaml is spelled "F#" in English.

~~~
spicyj
Looks like OCaml is:

<http://cs51.seas.harvard.edu/docs/CS51Syllabus.pdf>

------
dustingetz
Yaron Minsky is the technical director at Jane Street Capital, which is one of
the most prestigious functional programming shops in the world.

<http://janestreet.com/technology/articles.php>

~~~
agumonkey
I wonder how goes an interview at their company.

~~~
dustingetz
a few people have blogged about it, its supposedly one of the hardest software
interviews in the world. one blogger said the final in-person interview prompt
was to write a regular expression matcher on the whiteboard in ocaml in 45
minutes.

------
CoffeeDregs
Perhaps OT: I've tried to like OCaml 2 or 3 times so far and have not
succeeded. I've loved Haskell (until I hit the wall), enjoy Python, enjoyed
Ruby, am very happy with JS, had a love/hate relationship with C/C++ (really,
header files?!), loved Java compared to C/C++ (until I learned to hate Java).
And I'm generally really excited by what's going on in languages right now.

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.

~~~
crntaylor
My only experience with OCaml is two hours that I spent coding in it for an
interview problem. So, from a complete beginner's perspective:

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.

~~~
Yoric
For i), it's in progress: see OCaml Batteries Included
<http://batteries.forge.ocamlcore.org/>

------
amirmc
I'm curious. How many folks here have used OCaml for production work? I'd just
like to get an idea of the numbers.

Edit: By 'production work' I meant built things that are being used by other
people.

~~~
ths
You might find this interesting: <https://ocaml.janestreet.com/?q=node/61>

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.

~~~
crntaylor
By "several people programming in it full-time" you mean "everyone who writes
code in the company (IT, developers, researchers and traders) writes code in
OCaml" right?. Yaron has said (perhaps in that video, perhaps somewhere else)
that the founding partners (who were voice traders, not programmers) learned
OCaml as their second programming language, after VBA. The language pervades
the company.

~~~
ths
That's right. All I know is what I saw in that video, though, so you probably
know more about this than I do.

------
haberman
As a primarily imperative programmer who is just becoming more familiar with
Haskell, I'd love to see a compare/contrast between Haskell and Ocaml from
someone with expertise in this area.

~~~
cageface
The biggest differences are that Haskell defaults to lazy evaluation and OCaml
defaults to strict and that OCaml allows you to mix in imperative code without
explicitly using constructs like monads.

~~~
getsat
The monad in question:
<http://en.wikipedia.org/wiki/Haskell_features#ST_monad>

~~~
Drbble
Sort of. It is more like every function in OCaml is in IO. There is just no
purity guarantee anywhere.

------
ilaksh
Oh.. I thought that this was going to be an actual version of Ocaml that was
practical in the real world, rather than a book.

~~~
chubot
So what's impractical about Ocaml? I just looked at it and it looks cool, but
I haven't tried it for anything.

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++?

~~~
oconnor0
> So what's impractical about Ocaml?

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.

~~~
pnathan
As annoying as that is, it _could_ be turned into a design feature of your
programs - only doing message passing.

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.

~~~
pgroves
I'm doing a project using Python on AppEngine. AppEngine forces you to use a
bunch of single threads doing what is really message passing, but implemented
in Python so it's slower than Ocaml.

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.

~~~
cageface
_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._

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.

~~~
oconnor0
Certainly, but there are circumstances - say high-performance math & data
heavy stuff - that benefits _greatly_ from a shared memory implementation.

And the ease of use of multi-process architectures needs to be improved as
well.

~~~
avsm2
Note that OCaml is just fine for heavy math and data stuff: the _garbage
collector_ has a global lock, but threads work just fine for CPU intensive
activities. Just don't generate much garbage (which is important for any data-
heavy processing), and all is good.

------
gtani
Really overdue. Not sure if it closely follows Hickey's PDF draft from a
couple years ago, but thought it was well done.

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

Except Ocaml

------
wbkang
It's called F#. It comes with a much more succinct syntax, too.

