You know, this almost reminds me of the ML vs. Haskell debate. I remember fondly, hearing the 15-312 kids talk about how ML is right and everything else is wrong. The CMU PL dept was kind of adorable that way.
One of the classic examples is Haskell's typeclasses. Haskell's typeclasses are kinda kludgy because there's no way to provide more than one instance of a typeclass. ML's functors are way better.
But as it turns out, most of the time, we just need one instance. It's much simpler to invoke, and much easier to understand. If you need more than one instance, then use newtype.
In the end, we wouldn't be where we are in PL without the crazy folks at CMU and Bell labs. So I feel no small amount of sadness that ML didn't win. I concede the notion that ML may have made better design choices. But what matters more to me is that elements of FP get into the mainstream. Here, Haskell has done a better job of showing what is good with FP.
You have to concede it's a bit funny that you're pointing to Haskell as an example of the 'worse-is-better' approach that leads to viral adoption of dirty solutions over the endless pursuit of perfection.
If anything you could turn it around and say that ML's approach to control and data effects exemplifies worse-is-better on the purity spectrum. It took a long time for Haskell to solve these problems a la Haskell 98. It's only recently that Haskell has "caught on" relative to ML.
It depends on what perspective you take I guess. From one view, ML is the worse language, but from other views it would be Haskell. Suppose you require a fully formal specification which has been verified in a mechanized way. You have that for Standard ML in Twelf and Haskell has nothing sort of that.
If you look at the concept of being a purely functional language however, it is the opposite with Standard ML being the "worse" animal.
Module system: Then SML got it right and Haskell got it Wrong.
Laziness/Strictness: This is a duality. There are advantages and disadvantages to both approaches so there is no worse/right choice IMO. If you look at the recent stuff on polarity in proof theory it becomes clear that when you latch onto a specific evaluation order, you make some things simple and other things hard.
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>