Actually, I was originally of the same opinion, but then I read some lecture slides from Simon PJ. He has suggested that laziness was perhaps not the best default. It is hard to reason about space leaks with laziness. Likewise for typeclasses being inferior to ML functors.
I personally disagree. I'm pretty sure laziness has made it much easier for me to try out an idea. If it works, then I'll test that I didn't space leak. The notion of it almost makes me feel dirty. ;-) :-P
> He has suggested that laziness was perhaps not the best default. It is hard to reason about space leaks with laziness.
Aha, but it's perhaps not the best default for practical reasons, and it is the best default for theoretical reasons. Does that not make ML's eagerness an example of worse is better, because the worse theoretical solution is simpler the the rubber meets the road and you just want to find out where you're leaking memory>
I don't think there was any compromise here, just a different choice of default. Both offer a great deal of control over what evaluation method to use.
Haskell, for what it's worth, compromised on:
* Formal definition - this is an often-overlooked win for SML, and the sort of thing that lots of languages could use.
* Module system - type classes complicate this problem, but the lack of a decent module system hurts Haskell when building large systems.
* Type-classes (which overlap but aren't really the same thing and are probably more important)
* Typed-effects (a.k.a purity): This is a big one to lose.
* Laziness/Strictness control
I think ML is more of a compromise than Haskell.