Lambda the Ultimate

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.

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.

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.

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

If you put up a PayPal link, I'll make a donation.

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,

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.

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.

...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. :-)

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.

• Number-parameterized types
• Strongly typed heterogeneous collections
• Implicit configurations -- or, type classes reflect the values of types
• Typeful symbolic differentiation of compiled functions

• transactional memory in Haskell
• The Under-Appreciated Unfold
• Faking It: Simulating Dependent Types in Haskell
• Fun with Functional Dependencies

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.

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.

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

• Conservative = Formal specifications
• MLTon = whole program analysis
• Function guards = makes induction easier to follow

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.

...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. :-)

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 = 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).

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.

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

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 good. Just wish I'd read this before amazon dispatched it. Sounds like it could be a waste of £32 :(

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


Rich.

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.

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?

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.

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.

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... ;-) )

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.

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 :)