In the end, after having covered the whole book, I became frustrated with the language and jumped ship (to Haskell with a quick stopover at OCaml). My main reason was fragmentation: SML/NJ, MLton, etc. all have somewhat different "standard" libraries, which means that in many cases you can't use libraries written for one compiler with another. I ended up having to choose which compiler and set of libraries I wanted per project in order to optimize the availability of libraries for that particular project, which is a frustrating experience. I'd rather learn the idiosyncrasies of one compiler than two.
Before jumping to Haskell, I dabbled in OCaml. I did not implement anything serious with it; rather, I went back and reimplemented a couple of the small toys I'd done in SML using OCaml. I decided that if I had to choose between one of these and the other, I'd probably end up going with OCaml: since there's only one major implementation, you won't run into the frustrating experience of trying to merge two disjoint but frustratingly similar ecosystems. To my sensibilities, however, OCaml is a bit uglier syntactically than SML. In the end, I just never clicked with OCaml, and decided that Haskell would scratch my itch better (and it has).
Having said all that, I don't mean this to imply that you shouldn't read this book! Reading Harper's book on SML made it much easier to pick up OCaml and Haskell, and I definitely consider it an excellent use of my time. SML is a really nice language and a good introduction to Hindley-Milner, but the SML ecosystem is something of a jungle and you'll probably get frustrated if you stay too long. The biggest thing going for SML vs OCaml, in my opinion, is that the syntax is just plain nicer.
I would say these similar outcomes are a repudiation of the idea that multiple implementations of the same language is a good thing, but that hasn't hurt C's popularity. More likely, it has something to do with their roots in programming language research. Maybe ML and Scheme are too good for their own good, and other academics can't resist using them as a basis for their own pet ideas. Perhaps a truly successful (read, "widely-adopted") programming language has to be flawed just enough to discourage anyone from trying to improve on it. Worse is better strikes again?
It seems strange that Haskell seems to be a special case to this, but even there you see language extensions that ghc supports but Hugs et al do not. It's just that, for most people, ghc just wins outright. SML/NJ vs MLton is a harder question to decide given the freakish performance that MLton can achieve.
I'm curious what industry you're in that you're able to make significant use of Haskell?
I'm curious what industry you're in that you're able to make significant use of Haskell?
Objects, classes, polymorphic variants, and labels are all missing from SML, but none of them are a big deal. SML has slightly nicer records, in that you don't need to declare a record type, and can (and often are) used in a way similar to labeled arguments in OCaml. Unfortunately, structures cannot contain functors, and functors cannot return functors. Since I switched, first class modules have been added to OCaml, but I never used them in OCaml so I don't know how useful they would be.
One benefit of SML I have found is that function applications (including operator applications) are clearly separated from other types of expressions in the precedence parsing, so it is easier to remember the precedence rules in SML than it is in OCaml.
So, all of that is less than compelling, but I mention it because if you are comfortable with OCaml, you will likely be comfortable with SML. The reason I switched is because of MLton, which is pretty outstanding at optimization. You can write in whichever style works for you, because all the stylistic changes you would use with other compilers or interpreters for performance reasons don't really have any effect. There is basically no runtime barrier for using any kind of abstraction. This doesn't tend to show in the types of microbenchmarks that people often use for comparing languages (for simple programs, OCaml and MLton have pretty similar performance), but it's very nice for larger programs.
EDIT: Matt Might's summary on SML and OCaml is also quite good http://matt.might.net/articles/best-programming-languages/
As far as OCaml OO goes, I rarely use it (with one exception: objects implementing the "visitor pattern" for traversing the AST of a C program [1]) so its existence doesn't affect me. Perhaps I'd view the resulting language complexity as a negative if I had to maintain OCaml code that was OO heavy.
[1]: http://www.eecs.berkeley.edu/~necula/cil/api/Cil.cilVisitor....
Even without the purity question there are other things to consider. ML is evaluated strictly, for example. I don't know much Haskell but I don't believe it has any direct counterpart to ML's functors, either. There are probably many other differences. Haskell is definitely more popular and is still a niche language, so the reason you don't hear much about ML's benefits is probably just because it has so few users.
"...we are placing a strong emphasis on verification and proof as tools for the practicing programmer, chief among these being the infamous hellhounds of Computer Science, induction and recursion."
andrejbauer wants to know why Prof Harper is using SML instead of Haskell. There is a slight technical difficulty about proofs in a lazy language but "Well, in Haskell you’d have to use coinduction rather than induction, since the recursive definitions of datatypes are understood as final coalgebras."
That seems to make the point that ML is easier due to synergies with learning to create inductive proofs in maths lessons.
Two are two particular issues: laziness and the type system. Laziness is both complicated in practice and makes reasoning about the evaluation semantics more challenging. It can also lead to unexpected behavior for those unaccustomed to it (which will be nearly everybody). Furthermore, the type system is much more complex which makes it a bad model for learning about implicit typing and type inference.
However, for some programs, having a type-system that is fussy about side-effects imposes a significant effort burden for a meager correctness payoff. (For other programs, this bean counting is a huge win.) Also, I find it tricky to reason about the performance of lazy programs.
OCaml (and presumably SML) hit a practical sweet-spot in the statically-typed functional programming world.