## Practical OCaml

Practical OCaml. Joshua Smith.

Apress has recently published a "mainstream" book (in English!) on OCaml. Here is an interview with the author, on a Ruby blog, of all places. I haven't seen the book yet, but will certainly buy it. If it's as good as Practical Common Lisp and generates as much buzz, this will be a very nice thing.

## Comment viewing options

### It'll be out... eventually?

I ordered it two weeks ago when Amazon claimed to have it in stock. The shipping date for the book has now changed twice (from the 16th to the 23rd, and then to the 30th), so there's a chance it'll arrive in time for some Halloween reading (or perhaps I'll get another trick instead of my treat). It would have been nice to see it offered as a "beta book" like the Pragmatic Programmers do with their new works.

Meh... so long as it gets here sometime in the near future I'm looking forward to it.

Edit/update: For those of you who can't wait (or just prefer it as an eBook), the book is available as a PDF from the APRESS site linked to in the article.

### Do you really think that

Do you really think that slipping your referrer code into that Amazon link is appropriate?

I've removed that referrer code, thanks for pointing that out.

### Hmm.

Maybe not. It seems pretty harmless, though--if you clicked on it, and bought the book, then you wouldn't pay any more. The only difference would be that Amazon would give me a sliver of money for the (admittedly tiny) effort of doing the search for you.

Since it bothers you, though, I won't do it again; the money's not worth it.

Although, the interview had a link to the book, and the sliver of money Amazon gives out would go to help pay for (some) of the time I spend in setting up and conducting the interview. It's not like I get a lot of money from it (almost US $10 this month), but it's something. On the other hand, I'd still do the interview if there were no money to be had in it, so I guess I shouldn't complain too much. ### confusion? Community blogs like LtU are a bit different from personal blogs. I don't think anyone's questioning your right to include referrer links on your own personal blog. That wasn't the case here, and it wasn't your referrer link (assuming 'pate' and 'francis' are not the same person). As for the harmlessness, one issue is that we don't want people competing to post their referrer links. It would blur the nice crisp line between spam and useful comments, reduce the signal/noise ratio, and complicate administration. ### Community Let me just add that some of us, especially Anton, are spending a lot of time and resources keeping LtU running, for many years. If LtU is used an income source, even on a small scale, at least some of the income should go toward covering these costs (i.e., hosting etc.) ### Agreed If you put up a PayPal link, I'll make a donation. ### understood Actually, I understood that the complaint was about francis, I was adding a second complaint; that he was raking off the top of my time/work as well as LtU's. Sorry I wasn't more clear. Thanks for building and maintaining such a great resource. Keep up the good work on the site, ### Oops that he was raking off the top of my time/work as well as LtU's. That does make sense--I didn't read the interview, but just went straight to looking for the book, so I didn't realize you had your own link in there. ### Competing links As for the harmlessness, one issue is that we don't want people competing to post their referrer links. Good point; I didn't think of that. ### How about Practical Haskell? Just about the time I'm finally putting some time into learning/understanding Haskell! Seriously... it seems to me that the buzz around the functional languages such as Miranda, OCaml, ML, etc. is weakening as interest moves to Haskell, which was designed to consolidate work in the FP community. As a result Haskell is becoming the new "alternative" language. Fortunately there is a new Haskell book due out early next year that looks promising: Graham Hutton's Programming in Haskell. I'm also contemplating the textbook Introduction to Functional Programming Using Haskell 2nd ed. by Bird, but it is rather pricey. For now there is really a wealth of online content on Haskell. ### I Wouldn't Go Quite As Far... ...but it does seem to me that there are two major functional languages: O'Caml and Haskell. O'Caml seems to draw those looking for a pragmatic alternative to C, C++, Java... while Haskell draws those interested in extreme purity and an excellent foundation for further research into functional language design. Then there are folks like Oleg Kiselyov, who are fluent in both and have a long history of proving that you can do things that are "impossible" in both. :-) ### Details? Then there are folks like Oleg Kiselyov, who are fluent in both and have a long history of proving that you can do things that are "impossible" in both. Could you please give some more info on what you mean with "impossible" things? I am coming from Lisp and I was wondering what wonderful tricks you can do with Haskell (or O'Caml for that matter). I used both, but not for serious projects. I am currently trying to get more into serious Haskell usage (just to be able really to compare) and (coming from Lisp) I find myself spending a lot of time getting the compiler to actually interpret the code like I meant it, e.g. using "$" to avoid parens, which doesn't work for all cases, so you have to go back and switch to parens again, etc. Also I got quite used to nice structural editing of Lisp code.

Still, I am taking this seriously, so I'd appreciate any hints to "cool stuff" you can do with Haskell.

### Mind expanding stuff...

Well, first stop is his home page, then his Haskell page, and the types page. Here are some of my favorite items... ...and some other non-Kiselyov things of interest...

Sorry, I should have linked to Oleg's site instead of leaving you hanging. Oleg is also active here; here is the list of his posts. A good example of the "doing the impossible" claim can be found here.

Well, I did ask about that in the prelude interview with the editor, Matt Wade. His response, "We are actively looking at other functional languages and considering them for publication. . . . I would love to look over any proposals for function programming books. If you'd like to pitch an idea to us, send an email to editorial@apress.com."

### not in stock?

I checked all the Barnes and Nobles near Manhattan for the book, apparently this book was not even on order. I ordered through Amazon but the estimated delivery date is Oct. 30th, I do hope that date doesn't slip. I should note that APress is also coming out with two F# books next year (F# is a .NET version of OCaml).

### The other OCaml book

I am also writing a book on F#, based on my book
OCaml for Scientists
which was published at the beginning of last year and received great reviews.

### practical common-lisp knock-off?

i'm wondering how much of a knock-off this is of peter seibel's practical common lisp. looking at the table of contents for practical ocaml there is overlap with the practical sections such as the the simple database, the spam filter, and the shoutcast server.

is there a site for this book like the common-lisp book (http://www.gigamonkeys.com/book)?

### Just received mine, first impressions

I just got my copy from amazon today (I ordered back in August). I was quite excited given that I wasn't expecting it for another week. I also was a bit concerned about this being a knock-off of Practical Lisp (which I very much enjoyed). Having the same projects as in Practical Lisp (streaming shoutcast server, URI library for example) might be interesting simply to see how two different languages approach the same problem.

I'm fairly happy with what I'm reading having gotten already through the first three chapters. There are some concerns I have with the book already but I'm so thrilled with an English language book on O'Caml that I'm willing to give a little grace for the first few chapters.

### Bought it yesterday

I bought it at my local Borders yesterday. So far (I've gotten through the first few chapters), it seems pretty well-written, for its target--it's aimed at people who know programming, but not (necessarily) any FP languages.

It doesn't leave me too impressed with OCaml, though. I've used SML and Haskell before, and, so far, OCaml looks similar to SML, but with messier syntax. I've skipped ahead to the chapter on OCaml's object system; I'll have to see if that makes the language worthwhile for me.

Does anybody have a pointer to a good comparison between OCaml and SML? I dug around a bit, but the only one I could find was more of a ticklist on syntactic differences; I'd be interested in something explaining why I'd use one instead of the other.

### OCaml vs. SML

Off the top of my head, some reasons to use OCaml:

• More users = larger libraries and support
• Support for object oriented programming
• Metaprogramming facilities = CamlP4 and MetaOCaml
Some reasons to use SML:

• Conservative = Formal specifications
• MLTon = whole program analysis
• Function guards = makes induction easier to follow
I'm assuming that the comparison chart you refer to is Andreas' SML vs OCaml? Another item I've been working on, but haven't got very far is a translation of SICP which has chap#1 complete for OCaml and Alice ML (which is 99.9% SML in the actual translation) - though most of that chapter is a fairly mechanical translation between the two.

More users = larger libraries and support

Really! And here I'd been assuming that SML had more users, just because I know people (face-to-face) who've used it, and nobody who's used OCaml. (On reflection, my sample is a little skewed: I work in Cambridge (MA), so lots of my coworkers went to Harvard, and used Norman Ramsey's draft text based on SML. And the same goes for the professor I had when I took programming languages.)

I guess the other thing that misled me is the fact that OCaml has one implementation and SML has several. That doesn't necessarily mean much, though.

I'm assuming that the comparison chart you refer to is Andreas' SML vs OCaml?

Yes, that's right. A useful reference for someone moving from one to the other, but it deliberately (and reasonably) doesn't cover the stuff I'd need to answer the "which one?" question.

### My Summary of O'Caml...

...can be found here, in case that's helpful to you.

O'Caml feels, to me, like an even more pragmatic dialect of ML than any of the SML implementations. For me, a lot of that, I think, stems from having the toploop/bytecode compiler/native compiler all work together, vs. doing my development in, e.g. SML/NJ but having to use MLton for competitive runtime oomph. OMake also helps it seem "real" to me. But I guess that just reinforces the ecosystem point that's already been made here. In any case, I'm one of the local O'Caml zealots, so please feel free to wend any questions you may have my way. :-)

### Good to know

My Summary of O'Caml...

...can be found here, in case that's helpful to you.

Yes, that was useful, thanks.

It looks like one big decision point in whether to use OCaml is going to be camlp4. Also ocamllex and ocamlyacc (I know SML has ml-yacc, but it doesn't work on mosml, which is what I have on my Zaurus). All of these are covered in Practical OCaml, so clearly I have some reading to do.

### Metaprogramming facilities

Metaprogramming facilities = CamlP4 and MetaOCaml

MetaML is the original, and it's written for SML/NJ. According to http://www.metaocaml.org/, "MetaOCaml is a compiled dialect of MetaML."

Still, the point about more users applies here too: MetaOCaml seems to be seeing ongoing development, unlike MetaML.

Another minor difference between SML and OCaml is that SML allows explicitly specifying precedence of infix operators, whereas OCaml has a funky implicit system based on the characters which an operator starts with.

BTW, regarding OCaml's "messy syntax", it has an optional revised syntax, which is an improvement in most respects (although rather semicolon-happy).

### Revised syntax

BTW, regarding OCaml's "messy syntax", it has an optional revised syntax, which is an improvement in most respects (although rather semicolon-happy).

Nice, thanks.

### Amazon reviews

I was thinking about buying the book, but the current (only 2) reviews on Amazon aren't very kind with it. Can someone who has already read more of the book comment if it's worth or not?

### A Platypus

I just received my copy the other day, and between the Coq'Art book, reading about E concurrency (and posting here ;-) ), I've only had time to skim it, but I must say, I think I understand why the reviews trash it.

I think the problem is that it is neither fish nor fowl:

For example, it seems to assume the reader is a total FP newbie, but doesn't really flesh the concepts enough to really help a newbie understand.

Similarly, it is primer on the language, but is pretty darned cursory on the basics of the language, and couple items (like labelled parameters) that I can't quite remember from the last time I looked at OCaml failed to refresh my memory in any useful way.

Where I still hold out hope for it is as a "cookbook" of ideas about leveraging particular libraries to accomplish things. My past runs at OCaml have never quite gelled with me enough to inspire me to actually write a non-trivial project in it, so maybe this will inspire me. (Hope springs eternal... ;-))

When I get a chance to look at the book more thoroughly, I'll report back if there is anything to add.

### I got this impression

I got this impression by reading the sample chapter (on types, I think) that the book touched too lightly on the issues about the core language. My hope was that the "practical" chapters were longer, and really useful. I actually don't need a tutorial on OCaml, but a guide to good libraries would be great.

As an aside, there are not only one, but two books on F# coming next year, one by Don Syme (creator of F#) himself. Seems great.

### let practical_ocaml = Random.book ()

Well, I'm only about halfway through it, but so far I've been pretty disappointed (though it seems to be getting a bit better later in the book). Some of the problems that I've noted:

For one thing (and it's the first thing I noticed -- never a good thing in publishing) typography is flat out awful. Code listings are haphazard in appearance, with occasional bold and added glyphs appearing for no good reason. Plus, there are inconsistencies in the typesetting. E.g. when showing toplevel sessions, sometimes the # prompt following an action is shown in the text, other times it is not. There is no apparent reason for this. Yes, I harp on typography a lot, but when you're dealing with the printed word, it's very important. Here, it makes the code look astonishingly ugly, almost painful to read.

One huge problem is that the presentation is wildly haphazard (much like this post, no doubt). Related concepts are separated by unrelated asides. Concepts are grouped (or not grouped) together oddly -- his section on primitive types is just a mess. One thing that really threw me was that he introduces chars by saying that they are ASCII values that can be defined by "'\' (e.g. '\001')", but doesn't mention the standard way of working with printable chars (e.g. 'A' rather than '\065', though you finally see this on the next page), and he doesn't mention the hex version either (e.g. '\x41').

Some items are given only a superficial introduction (e.g. variants -- a very important part of OCaml), and then used fairly heavily two chapters later without so much as a pointer back to their introduction for people skimming the book. Another issue is the way polymorphic types are handled. For one thing, the author never tells you how to specify one. He pretty much leaves it up to the reader to infer the single quote followed by lower-case identifier format, though they might think you have to always use 'a, which can be confusing. And if I remember right, he makes it seem that they are only allowed to be used with variants.

Superficial code quality is sketchy. E.g. he uses "Hashtbl.fold (fun x y z -> blah)" rather than the more informative "Hashtbl.fold (fun key value base -> blah)", or even "Hashtbl.fold (fun k v b -> blah)" which at least cue the user as to what the code does. As it is, it more or less requires the reader to have a copy of the standard library documentation handy.

A number of errors appear throughout the text. Some are silly, possibly typos, e.g. saying that a piece of code uses the fold function when it actually uses map. Some are just head scratchers: He claims strings can be indexed like arrays with the standard indexing syntax. This is not so. Arrays are indexed with parens, strings with brackets; He also claims OCaml supports the int64 datatype only if the platform does as well. This is untrue. It always has the int64 type. And his description of nativeint is just lousy.

Like I said, the whole thing has a very haphazard, "Oh yeah! One more thing I just remembered..." feel to it. It appears that next to no thought went into presentation order and flow. More often than not, concepts are used before they are introduced, and sometimes quite poorly. For example, when talking about the toplevel's error messages, he provides an example that uses a variant that he had never shown in any of the previous examples. He goes on to say that this would produce the error "this expression has type distance but is used here with type int," which it would, if we had defined the type distance. As that type doesn't show up for another 23 pages, any reader who actually types the code into the toplevel will actually get the error "Unbound constructor Foot". Confusing trusting readers is bad juju. It all just makes me wonder what the editors were thinking.

I'm sorry to say, but the best introduction for learning OCaml is still Jason Hickey's free PDF and the free old O'Reilly book (along with a mailing list or two to bring you up to the latest version of OCaml). Note: I haven't looked at Harrop's book yet, as it just strikes me as far too expensive. Sorry Jon...

### Ouch. That doesn't sound

Ouch. That doesn't sound good. Just wish I'd read this before amazon dispatched it. Sounds like it could be a waste of Â£32 :(

### Technical reviewer

I was the technical reviewer on this book. You might like to see my take on the production here.

Rich.

### Completely agree

I'm sad to say, I completely agree. I've only read the first few chapters and was planning not to comment until I'd gotten a bit deeper, but after reading what others have said (here and elsewhere) I don't see much point in waiting.

This book is a big disappointment. As already noted, it has some severe stylistic problems and the writing is uninspiring, to say the least. But by far the worst problem is that the author's knowledge of his subject is simply insufficient. This shows up all over the place, but I'll highlight two examples that I think exemplify the issue.

In Chapter 3 Smith introduces data types. The entire presentation is confused, poorly motivated and incorrect in places. But then it goes completely into the weeds. He has introduced a distance type:
type distance = Meter of int | Foot of int | Mile of int;;
Then goes on to say:

Variants can also be used to describe recursive data types. For example, you could add a polymorphic distance variant to the distance data type by creating the definition like so:
type 'a distance = Meter of int | Foot of int | Mile of int | Distance of 'a distance;;
...
Adding this definition to the type doesn't provide much, but...

"Doesn't provide much" indeed... Ignoring for the moment that this is a bizarre addition to the distance type and that absolutely no motivation is offered, there is absolutely no indication of where the cryptic 'a comes from, what it is, or why it might be necessary (or desirable). Worst of all, there is no indication that Smith realizes that introducing a type variable here is unnecessary and is in fact a rather odd thing to do.

The next section, "More About Math", begins:

OCaml is designed to be provable, and there is at least one publicly available automated theorem solver in OCaml for OCaml programs.

There is then a brief parenthetical note mentioning the existence of Coq, and the section goes on, with no transition whatsoever, to explain that mathematical operations in OCaml are not overloaded to work with integers and floating point numbers. No connection with theorem proving is offered, and as far as I can tell, neither Coq nor theorem proving is ever mentioned again.

Hopefully these illustrate the nature of the flaws that pervade this book. Generally speaking, terminology is confusing, inconsistent and non-standard and the explanation is shallow and sometimes incorrect. I'll keep going through the book and I expect to learn a few things, and will be happy if I'm able to revise my opinion later, but for now, I would certainly not recommend it.

### why not a wiki or something?

Seems like there are enough folks who understand O'Caml (otherwise the reviews on this page wouldn't have happened as they did) that starting an O'Caml wiki with a very pointed purpose of making a good training and reference corpus could work.

I'm not sure why everybody is looking first for a book so much. I mean, I understand the many ways in which books are better, but step one might be to get the information together such that it doesn't suck, and step two could then be publishing that information on paper?

### OCaml Wiki

Merjis run this OCaml Wiki aimed at procedural or OO programmers but it wasn't very good last time I looked.

I'd like to rant a little about your comment "why have books when we can have wikis" because I'm the author of the other book on OCaml. A wiki is not a substitute for a well-written, carefully thought-out, proof-read and typeset book. I put months of effort into my OCaml book and had it proof read by Xavier Leroy, Don Syme and others. In contrast, wikis are not planned, not proof read and are mostly written by the people with the most spare time.

I haven't seen the book yet, but it's really sad if the book is as problematic as this thread indicates. I had high hopes for the "Practical X" line of books. I thought it might become an O'reilly-like brand for books about non-mainstream languages. I was already looking forward to seeing "Practical Earlang" announced...

I think it would be helpful if the Ocaml community and the PL community at large try to move beyond criticism, in this case, and try to work with the author and Apress in a constructive way, to produce a better version of the book, to be published as a second edition (or posted to the book's website).

I am nost sure Apress will want to cooperate with such an effort, but I really don't see why they wouldn't. So I suggest Ocaml mavens try to get in touch with them (or post here that they are willing to help, and wait for Apress to approach them).

It is in our interest to promote books of this kind, and this might be a chance to move things in the right direction.

P.S. Lest it be misunderstood, I am not arguing against criticizing the book, if it deserves it, simply saying that we should also try to provide constructive help.

They might refuse such help on the grounds that it would be tantamount to admitting that the first edition isn't good enough. But maybe somebody can be more subtle: contact them about doing Practical Erlang, do it right, and then suggest Practical OCaml can be improved.

Alternatively, someone interested in writing an OCaml book could go to O'Reilly and use Practical OCaml as an argument that there's a market for a good book on OCaml.

### Publishing for Dollars

They might refuse such help on the grounds that it would be tantamount to admitting that the first edition isn't good enough.

I think this is less of a barrier than you might think.

A publishing house is first and foremost a business: they want to make money on their books more than they want to think their books are wonderful. (Authors are in charge of the latter... ;-) )

Any book is a compromise between the time and money cost to produce it and the amount of revenue it can generate. If there was some low cost way that they could improve the book so that it would make more money, I'm sure they would be interested.

Convincing them that you HAVE such a way may be more difficult...

Ironically, the best way to ensure that there will one day be a new and improved second edition is for lots of people to buy the first edition even though it sucks: this tells the publisher that there is a market they can sell a SECOND copy to if they upgrade the content.

(Actually if you think about this, the book industry isn't that different from the software industry... ;-) )

### O'Reilly

I talked to O'Reilly about this about a year ago and they weren't interested. Of course things might have changed since the Apress book was published.

Our OCaml tutorial wiki has a list of online and offline resources (I'm just about to add Jon's book which I notice was missing). And some enterprising people are translating the wiki into Japanese and French.

Rich.

### Self-publishing

Convincing O'Reilly or Apress to publish a good book isn't necessary. Googling for "print on demand" turns up plenty of material. The second edition of "Programming in Lua" was recently released this way.

You, too, can be an author :)

### Rather Disappointing

This book doesn't need a good edit and a second printing. This book needs to be abandoned to the public domain and written again from scratch.

The concept here is wonderful. And those like me--frustrated with current mainstream programming languages, poking at functional programming for a year or two, having written a few lines of Haskell--we may even get something useful from this book, if only the inspiration to give OCaml another go.

The thing that most frustrated me about _The Haskell School of Expression_, which seemed to me the most practical and interesting of all of the Haskell books I could lay my hands on, was that it in the end it did not directly address what I do for a living: web servers, parsers for obscure and bizzare binary formats, relations with RDBMSes, manifestations of business illogic....

Well, it did in a way, in that it was pretty obvious to me that the power of these systems could improve and shorten a lot of the stuff I write. But in this industry of course, coders looking for a better thing (as opposed to managers looking for a better thing) are always worried that they're watching Martha Stewart show you the perfect laundry room. It looks fantastic--it's the BEA Weblogic of laundry rooms--but you know that in her entire life she's probably spent hardly a minute in a laundry room that wasn't built inside a TV studio. That offers a lot of hope but small consolation to the housewife who spends many hours a week in hers.

Without cueing a big discussion about the Dreyfus model (which I'll save for the blog I don't write), the main issue with most of what I attack on this front is that I can't figure out how to transform the reactive animations module in the book into that beautiful, correct and concise web server or parser for binary files that I need to write this week.

So this was my hope for _Practical OCaml_. It had a web server in it. I write these, I'm bored by them, presumably it could show me a better way to do this.

But this book...well! It rambles here and there. It gives you code examples with no explanation of how they work, much less what's good or bad about them compared to what you've been doing before. If you'd not already had a glimmer about how certain ways of recursion could let you deal with iteration far more elegantly than a while loop and six variables, you'd probably think the author was smoking crack. (If you want to find out how FP is better, this is not the book for you.) And then just as suddenly it moves on to arguments from authority--seemingly aimed at a junior PHP programmer--as if any competent pro couldn't figure out the cost of a regular expression parser, or hadn't encountered a million situations where regexs were painful and wasn't looking for something better.

But by far the worst thing about this book is that the code Just Isn't Beautiful. The typesetting plays a part in this: it doesn't help when your indentation changes randomly, the 'in' of a 'let ... in' sometimes is at the end of a line, sometimes at the beginning, and you'll often find that a line at the same lexical level is suddenly loses an indent column or two from its siblings before it. But even the code itself doesn't appeal. Far too often it appears less elegant and more verbose than the Ruby code I'd write to do the same thing, even after I get through the obscure variable names and odd formatting. Reading _The Little Schemer_ has made me incredibly frustated with the control structures of popular languages; this book makes me think that they're not so bad after all.

(Oh, and don't even *talk* me about page 297. "Christian Gangsta"? How about leaving it blank except for, "There could have been something useful in this space"?)

In the end, the book will probably be somewhat useful to me. I suspect--well, really, just hope--that it's going to to fill a certain role in moving me from "I can see something very cool in that," to, "why on earth would you program in a language that didn't let you do this?" But it's going to be books like _The Little Schemer_ and _The Haskell School of Expression_ that I know that there's a better world out there (though they couldn't quite bring me to it for my day-to-day work), and _Practical OCaml_ is going to be, if anything, as much of a hurdle to overcome as a boost up on the way to doing my everyday programming in a better way.