Beginner's guide to OCaml beginner's guides
blog.nullspace.io
blog.nullspace.io
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.
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?
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)
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.
[1] https://blogs.janestreet.com/better-namespaces-through-modul...
One aspect that I think could be explored deeper is how to architecture complex applications with the language. How the module system can be used to build abstractions and protocols for not-trivial systems? For example how one could build a database with it, or even an operating system? I'm in the process of learning OCaml and what is really difficult for me is to understand what are the most idiomatic and efficient ways of modelling application domains. Although there are many open-source projects one can learn from (like JaneStreet's libraries, Nymote sub-projects, etc), the concepts and practices they use are sometimes hard to understand just reading the source.
If it helps, we have a series of blog posts about some of the recent library releases on the Mirage blog [1], some of which go into the design of those libraries. Perhaps they'd be useful?
Another good example of a very good software design reading I've fuond is the OCamlgraph's paper[1], which demonstrates the strength of the ML's module system in a not trivial situation.
Bought the ebook, and ended up just reading it as a means to see what changed since the Caml Light days and differences to F#.
Cheapest place to buy in the UK is the Book Depository.
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).
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.
Is dead-tree RWO worthwhile or is it going to become obsolete quickly? I like (prefer) reading on paper, but I've been having a hard time over the past few years justifying the purchase of books that are destined for the recycle bin within a year.
So, there's no way to say for sure, but I think there's a reasonable chance it sticks around.
I love Haskell. Love it to death.
I see RWO as a justification of OCaml's language choices from the perspective of system deployment. It gives you a good start on the knowledge you'd need to push an OCaml system into serious production.
I do not see how to get the same knowledge for Haskell. Particularly the runtime is a black box to me. This might be acceptable for your use cases, but for me, this is the primary risk of Haskell.
re: community, It's probably true that Haskell so far is more prominent than OCaml right now, I would be careful to avoid making the mistake of assuming that this means people actually know how to deploy this for serious, scale production systems. Because it is not obvious that this is true. Besides, while the OCaml community is not as noisy, they are certainly still around.
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.
I think it's important to point out that Haskell is actually functionally pure (in that there are no side effects in the language), whereas ML does have references baked into the language, so you can revert back to writing Pascal-looking inner loops in Caml, for example.
Some might take "Haskell doesn't have side effects" to mean that you can't talk to servers or read the filesystem.
I've always seen Haskell as a kind of ML off-shot, but perhaps the similarity is more in the syntax than in the substance?
Try e.g. github http://redmonk.com/sogrady/2014/06/13/language-rankings-6-14...
Huh, I don't have a pi, but judging (blindly) by:
http://www.haskell.org/haskellwiki/Raspberry_Pi
That should be "You can run the Ocaml toplevel on the Pi"?
That's because on this site the m-word is banned. Which is very, very good move in my opinion, but anyway: the "Railway oriented programming" is an article about monads and begins with a definition of Maybe/Option, it's just not explicitly named as such. It's also a very good tutorial, maybe even one of the best I read. I strongly recommend it, too.
- 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.
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.
Here is a list I found useful to learn more about monads (they aren't necessarily all the ones that I had to read to understand them, there was another page that I can't find right now): http://pauillac.inria.fr/~xleroy/mpri/2-4/monads.2up.pdf http://blog.enfranchisedmind.com/2007/08/a-monad-tutorial-fo... http://ambassadortothecomputers.blogspot.ro/2009/02/equeue-c... http://blog.0branch.com/posts/2012-03-26-01-implementing-fun... http://blog.0branch.com/posts/2012-03-26-02-from-functor.htm...
There are excellent explanations of monads for JavaScript, F#, Clojure and Erlang, to name a few. Pick one of them, for the language you're most familiar with. Avoid any syntactic sugar in the beginning. Avoid reading about Maybe/Option monad - it's too boring. Start with hand-crafted List monad, then go to State and/or Promise/Deferred monads, and then ignore State, Either, Writer and many more monads, which are either boring or only relevant in pure languages. Then start sugaring the syntax, `for` in Scala and "computational expressions" in F# are good for this, also LiveScript back-calls are passable. If you're into Lisps, then of course you have macros and it's a good exercise to write you own macros (of course, every Lisp out-there has many implementations already available to look at, if you're stuck).
At this point you know enough to get back to Haskell and/or to look at monad transformers and Cont monad. You can also read about monadic laws and actually have an idea what they are about.
It worked for me. I think the key to my method was to avoid reading about boring and/or not directly applicable things while constantly playing in a REPL with the interesting ones. I find it unbearable to learn theory of things I can't imagine being used. Once I use the "thing" a couple of times it changes and I can absorb theory pretty quickly.
http://research.microsoft.com/en-us/um/people/simonpj/papers...
The TLDR: Haskell uses lazy evaluation, meaning expressions are evaluated in an umpredictable order. If expression evaluation had side effects, programs would become unmanageable, so in Haskell, al computations must be pure. Monads are a neat trick where you use a specially crafted abstract (opaque) interface that lets you model side-effecting computations, specifying what order things should run in.
Of course, initially the biggest reason for using monads so prominently is the IO but the monad interface is much more general and an also be used for other things (List, Maybe, etc)
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?
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.
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 :-)
I'm at the moment trying to run F# on Linux...