By the way, does Haskell's type system have the "value restriction" that you run into in ML?
Haskell's type system is practically a language itself. It has many powerful features that aid with expression:
* sum, product and generalized algebraic data types (GADTs)
* higher-kinded types
* universally & existentially quantified types
* scoped type variables
* impredicative types
* associated types
* type families
* kind polymorphism (a new feature)
* type holes (also new)
I'm not sure what you mean by "value restriction". Haskell, like ML, is not a dependently typed programming language. For that you'll want to use something like Agda. As for why you'd want a language to not have dependent types? Well, having them introduces all kinds of considerations with regards to decidability and type inference.
http://mlton.org/ValueRestriction
It can be annoying to work around this, because there are potentially ML programs that would be type-safe and would otherwise compile if they were not hindered by the value restriction.
I got my answer, though:
Ii is interesting that in ML, the presence of mutable ref cells and parametric polymorphism requires the whole language to be dominated by a "value restriction" [1] to ensure that the type system remains sound, whereas in Haskell, because IORef's can only be created (and used) in the IO monad, no such restriction is necessary.
http://www.haskell.org/pipermail/haskell-cafe/2007-July/0292...
Haskell is worth learning because it has an expressive, strong, static type system. Most other languages do not have that property (Java's type system is static, give or take null, and strong, but not expressive, and Ruby's is strong but neither expressive nor static). The Haskell type system lets you have conversations with the compiler about what your program should do.
You can declare a state type, and have the compiler tell you if you switch on the state and forget to handle one of the possible states (or if you add a state later and forget to update all the switches).
You can tell the compiler "I think this function is a generally useful utility function that I plan to extract out of this project and use elsewhere", and it will tell you whether there's some dependency on your project that you missed.
You can specify in a function's type "this function should have access to the database"; then the compiler can tell you if you're trying to access the database somewhere you didn't expect to. (A colleague has just spent a person-year of effort refactoring a Django web app, because all the database calls were happening in the view code, and they needed to abstract them out to scale.)
Of course there are ways to do some of those things in other languages, and of course there are also downsides to the static type system. But those sorts of abilities open up new programming techniques (even in languages with poorer type systems), and have shown me ways programming can be better.