
Beginner's guide to OCaml beginner's guides - akerl_
http://blog.nullspace.io/beginners-guide-to-ocaml-beginners-guides.html
======
jallmann
Real World OCaml is indeed awesome -- while it is free, if you do find
yourself making good use of it, please also at least buy an ebook version.
Totally worth its bytes in gold. (No affiliation, just an OCaml dilettante
who's benefitted a lot from RWO).

For good code to learn from, I'd also recommend Batteries, another stdlib
replacement [1]. It's not as expansive as JSC Core, which arguably makes the
code easier to browse, IMO. Ditto for lwt in place of Async. Really, a lot of
the FOSS tools and libraries in the OCaml ecosystem are extremely high-quality
-- and still improving at a rapid pace, thanks to OPAM.

If any of the RWO authors are reading this, I'd love an expanded version (or
another book) with more advanced features of the language -- GADTs, a deeper
treatment of the functor/module system, covariant/contravariant types, Camlp4
and/or the extension points mechanism, etc.

[1] I recall reading somewhere the extlib/batteries author said he would have
written the library in a more functorial style if starting over today, but I
still find it an excellent example of clean, idiomatic OCaml.

~~~
avsm
> If any of the RWO authors are reading this, I'd love an expanded version (or
> another book) with more advanced features of the language -- GADTs, a deeper
> treatment of the functor/module system, covariant/contravariant types,
> Camlp4 and/or the extension points mechanism, etc.

I'm actually meeting our editor (Andy Oram) in a couple of weeks at OSCON to
discuss just this. We deliberately stayed away from newer features (e.g.
GADTs) that we didn't feel had enough of an outing in production codebases,
but with the release of OCaml 4.02 due in a few months this is a good time to
do a refresh and fix that. What aspects of the module system would you like to
see more of?

~~~
jallmann
> I'm actually meeting our editor (Andy Oram) in a couple of weeks at OSCON to
> discuss just this.

Great to hear that!

> What aspects of the module system would you like to see more of?

The book is actually comprehensive in this respect, but the module system is
just a lot to digest. I'm not actually an expert, so I really don't know what
could/should be done, only that sometimes it takes me a while to figure out
"best practices", or what's required by the compiler, or the semantic
implications of some of the more unfamiliar syntax. For example, recently I
saw:

    
    
        module Client : module type of Client.Make(IO)
    

which differs from the "module type of" usage discussed in the book. The OCaml
module system is extremely rich, with a learning curve to match. I don't
really feel that I know how to exploit the system to its fullest just yet.
Maybe a section on common patterns or best practices would be helpful.

On a side note, thanks for all your effort, not just on the book but also in
keeping the OCaml community vibrant. I wouldn't be nearly as interested
without all the work that's going on now.

~~~
avsm
Thanks, that's all very useful feedback. There have been several significant
improvements to the module system in 4.02 (including generative functors and
module aliases [1] in signatures), so I agree that there's quite a bit more to
write about. We have a very short section on common patterns that could
perhaps be expanded into a chapter.

[1] [https://blogs.janestreet.com/better-namespaces-through-
modul...](https://blogs.janestreet.com/better-namespaces-through-module-
aliases/)

------
dbpatterson
It is really bizarre to contrast Real World OCaml to Learn You a Haskell. The
former is a serious book, the latter is a very beginner level tutorial. Now
there may be real criticisms comparing Real World OCaml to Real World Haskell
(which, if from the names alone, would seem like a much more appropriate
comparison), but saying "this beginner tutorial doesn't explain how the
runtime works" is a little silly.

~~~
antics
(Author here)

I think it's totally fair. The whole reason I wrote this post is to help
people _decide which resources to not use_. I love LYAH but I don't care who
it was written for. I wanted people to know, specifically, what they were
missing with books like that, because it was not obvious to me when I started
that I should not start with LYAH (or at least, that I should have kept in
mind what it was missing).

~~~
hyperpape
I think the comparison is absolutely essential. I always want a guide to the
resources about a topic so that I can find out where to look to learn the way
I want to learn.

But the judgment is probably strong. Right now, my immediate reason to learn
OCaml is because Types and Programming Languages uses it for its type
checkers. For that purpose, I might just want quicker tutorials that don't
cover the runtime. Ditto if my primary goal is to learn more about using types
for good API design. On the other hand, if I learn and continue with the
language, or want to put it into production, the runtime is essential. There's
lots of use cases out there.

~~~
antics
Yeah, I agree, I was probably too hard on LYAH. But, even if my goals didn't
match your goals, I am hoping that the information I am giving you is sort of
useful either way. The emphasis is really on the reasoning, rather than the
conclusion.

~~~
hyperpape
It is useful either way. I love the idea of this post, and I wish it existed
and was findable for every topic I'm interested in.

------
tmountain
Can anyone speak to the pros/cons of learning OCaml vs Haskell? They seem
comparable in some respects, but it feels to me as if Haskell has more
momentum and presumably a more active community. Am I correct in this
assumption?

~~~
toolslive
In the popularity of programming languages list,
[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

F# is number 13; ML is number 26; Haskell is number 38; OCaml is ranked below
50.

So the ML family of languages is way more popular than Haskell, but is
fragmented.

Below are my impressions/experiences.

In general, the languages themselves are excellent, but the standard libraries
vary in quality, as do the tool chains. ML is eager by default, Haskell lazy.
Otherwise, it's the same mindset (although some people will think Haskell went
overboard on monads, some people think OCaml's libs aren't monadic enough)

For example f# is excellent in all of the above, but is _challenged_ in the
multi-platform aspect.

OCaml's standard library is limited, but this is compensated with Opam.
Considering OCaml on windows is simply looking for trouble. The OCaml compiler
is good, but other tools are limited or a bit primitive (heap profilers,
debuggers, performance profilers). The community is rather reserved, but very
helpful.

Haskell standard library is also limited (for example you ain't gonna jump far
with the string implementation that's offered by Prelude, and Num is also
warted). The toolchain is better than OCaml's. Also Cabal has libs for
everything, but ymmv. The community is really gentle and eager to help.

ML, sorry no experience, most other flavours seem dead or quiet. MLton is a
really interesting compiler.

~~~
toolslive
I forgot: learning a statically typed functional language will make you a
better developer. There is a catch though: some people will just refuse to go
back to the normal Java, C++ or python insanity.

~~~
codygman
Haskell does make Java and python a bit depressing to go back to for me, yes.

------
Mithaldu
Having recently (speaking in years) worked on improving the situation for
Perl, i have to say i find it fascinating how other languages come to realize,
and deal, with the fact that most tutorials and beginner guides may be well-
meaning, but are actively damaging to the newbie developer.

------
patmcguire
I would also like a beginner's guide to beginner's guides to monads. I've
started and given up on a half dozen of those.

~~~
cgag

        - Don't read the monad tutorials.
        - No really, don't read the monad tutorials.
        - Learn about Haskell types.
        - Learn what a typeclass is.
        - Read the Typeclassopedia.
        - Read the monad definitions.
        - Use monads in real code.
        - Don't write monad-analogy tutorials.
    

[http://dev.stephendiehl.com/hask/#monads](http://dev.stephendiehl.com/hask/#monads)

~~~
GregBuchholz
I think the best way to learn about monads is to write a monad tutorial. If
nothing else it is a rite-of-passage.

~~~
rwosync
Please don't do this. We have enough problems communicating this concept as it
is.

~~~
e12e
Please do _write_ one. Please don't _publish_ one. Writing is a great way to
think.

Without yet really understanding monads, I've come to realize that their only
real problem is the name -- being named after some rather obscure (for most!)
category theory concept -- that itself seems just about as simple and trivial
as monads are. I find they are a little like the y-combinator in that regard.

I'm not sure if what we need is category theory in elementary school, or a
different framework for discussing monads as it relates to programming -- but
I'm almost convinced the confusion has to do with the language used to
describe them.

Programming is a very _practical_ art that sits on top of the much more
_abstract_ art of mathematics. It's useful to know orders of magnitude, graph
theory, statistics, logic... but the art by which these concepts are animated
and put to use is rather prosaic. And the discipline of computing has forged a
set of concepts that are "appropriately abstract" (much, I think due to Knuth)
-- but monads seem to lie just outside the grasp of many programmers. And I
don't think it is because they are a particularly intrinsically hard concept.

------
xamlhacker
OCaml is a very nice language, and the compiler is pretty good but the only
issue is that the implementation doesn't allow you to use more than one CPU
core because of some issue with the GC design. F#, which is heavily OCaml
inspired, has good parallel support.

~~~
amirmc
This is one of the things OCaml Labs is working on [1]. We'll be talking about
it at OCaml 2014 later this year [2]

[1]
[http://www.cl.cam.ac.uk/~sd601/multicore.md](http://www.cl.cam.ac.uk/~sd601/multicore.md)

[2]
[http://ocaml.org/meetings/ocaml/2014/program.html](http://ocaml.org/meetings/ocaml/2014/program.html)

~~~
e12e
If one isn't running on Windows, is there still a strong argument to be made
for supporting OS threads over simply multiprocess (with some form of message
passing)?

In what kind of situations would one really benefit from threads over
processes? I'm genuinely curious, it's been a _long_ time since I've run into
blocking on 100% cpu in any kind of real world workload (doesn't mean they
don't exist!).

I understand that we will need multicore support, I'm just not sure why we
need multithread support?

------
groovy2shoes
> In addition, I would advise against reading other books, as they tend to be
> incorrect _and /or in French_. [emphasis mine]

Hey now, "Le Langage Caml" might be in French, and it might be pretty dated at
this point, but it's a solid introduction to functional programming and Caml
(note the lack of "O" \-- like I said, it's pretty dated).

One of the things I like about it is that it it has 5 chapters dedicated to
walking through some pretty complicated examples (following 11 chapters giving
a tutorial introduction to Caml). With many programming books the examples are
so simple that it's hard to see how they all fit together, but Weis and Leroy
do an outstanding job of showing how interesting programs would be written in
Caml: an interpreter for a little logic language, a file
compression/decompression utility, an emulator and assembler for a RISC
processor, a "mini-Pascal" compiler targeting said processor, and a regular
expression search utility (à la grep). It doesn't just show the code for these
programs, but it walks you through building it, from design(!) all the way to
the finished product, explaining every little bit in detail. I wish more
programming books did this kind of thing!

Like "Real World OCaml", it covers a bit of the runtime -- it's the Caml Light
runtime rather than the OCaml runtime, but some of the discussion applies
equally to OCaml as well.

Lastly, it has a style that I feel is lacking in many programming books: the
authors are careful to use rather precise phrasing. I think this is good
because it helps to eliminate a lot of ambiguous or misleading text.

So sure, advise against it for people who don't understand French. For people
who do understand French (even a little -- it's mostly technical terms), "Le
Langage Caml" is an excellent book.

~~~
omaranto
That line also caught my eye. It sounds insane: isn't it much more reasonable
to recomend books based on their quality rather than the language they are
written in? I agree with you that "Le Langage Caml" is a pretty good book, but
I disagree with what you say at the end about advising people who don't read
French against reading it. I would instead just advise everyone interested in
Ocaml to read it and people who can't read French will automatically ignore my
advice without me needing to say anything about it!

~~~
e12e
Thanks for this recommendation -- I could use a book to brush up on my French
on (and caml :). I'd love to hear some other "best-of" programming book
(originally) in French?

My native language is Norwegian, and I'm afraid I've not read a whole lot in
Norwegian that I feel I could recommend (mostly because a lot of the most
obvious interesting candidates like Simula and MVC is written in English
anyway). Besides, I'm afraid the set of people that don't already
speak/understand Norwegian, and would like to learn it in order to be literate
in programming/technical jargon/style is rather small...?

I also speak Japanese, but I can't really claim to be literate -- I'd be happy
to receive some best-of recommendations there too -- the only way to become
technically literate is to read, after all :-)

~~~
omaranto
I really like Christian Queinnec's Lisp in Small Pieces. I read the English
translation but the original is in French, Principes d'implantation de Scheme
et Lisp (that's actually the title of a revised edition, the first edition was
called Les Langages Lisp).

------
rwmj
Happy to have patches to the various real-world virt-* tools written in OCaml
here:

[https://github.com/libguestfs/libguestfs](https://github.com/libguestfs/libguestfs)

~~~
avsm
Just started a thread on ocaml.org about putting a list of recommended
projects for newcomers to look through the code for;
[https://github.com/ocaml/ocaml.org/issues/497](https://github.com/ocaml/ocaml.org/issues/497)

------
rudi-c
Any similar resource for other functional languages, that go deep into
justifying language features, explaining their implementations and the
underlying runtime? I come across way too many tutorials or books that only
show how to use the syntax, with occasionally a neat syntatic sugar or two.

------
cwyers
I've been thinking about teaching myself a functional programming language as
a side project. Is there any reason to pick OCaml over F#?

~~~
yawaramin
To be free from the .Net runtime. If you're deploying on an environment where
.Net would be unnecessary overhead, you can use OCaml, compile to native code,
and distribute with a minimal runtime.

~~~
cwyers
Well, my personal machine runs Windows, and at work we're a heavy C#/SQL
Server shop, so .Net is fine with me.

------
pepijndevos
Who is using OCaml in production outside of Jane Street?

I'm at the moment trying to run F# on Linux...

~~~
gnuvince
Facebook, Microsoft, Bloomberg, Citrix, etc.

[http://ocaml.org/learn/companies.html](http://ocaml.org/learn/companies.html)

[http://ocaml.org/learn/success.html](http://ocaml.org/learn/success.html)

~~~
wink
A small portion of Clojure users:
[http://leiningen.org/grench.html](http://leiningen.org/grench.html)

