However, a reasonable proportion of students seem interested, and a handful are overtly enthusiastic about the course. If I had to guess I'd say it won't be an order-of-magnitude improvement over 212, but it will be significant one, if only because it will reach more students earlier in their undergraduate careers. However, only time will tell.
As for 212's reputation, you and I must run in different circles; I know plenty of FP enthusiasts who got their first taste in 212. I suspect a strong selection bias is at work here.
In long:
Haskell has much better concrete syntax, better library and tool support, a more active community, and is subjectively nicer to program in.
Haskell is lazy, SML eager. Haskell catches a lot of flack about this from SML fans. I think the typical arguments against laziness (makes it hard to reason about space usage; just a special-case of eagerness) are not false but overblown (it's harder but not that hard once you get used to it; and yes, you can simulate laziness in an eager language using thunks etc, but that's a Turing tarpit argument). However, in the end I'm not sure laziness is worth it.
Haskell is pure and SML is not. I don't mind the impurity of SML (or any other language), but I think Haskell's purity has some nice side-benefits for a high-level FP language (eg. allows more compiler optimizations). I'm also grateful to it for being the main reason Haskell has support for monads, which I think are a powerful unifying idea well worth their weight even if you don't need them to encapsulate I/O & side-effects.
The big difference is, of course, their module systems. Everything Harper says about Haskell in this regard (https://existentialtype.wordpress.com/2011/04/16/modules-mat...) is true, but I don't think it's as big of an issue as he makes out. Typeclasses give you 90% of what you want, in a much more concise package. I've perhaps wanted ML-style modules & functors once or twice when writing Haskell, and I wish I had typeclasses all the time when writing SML. I could say more on this topic, but this response is already overlong.
That being said the tone of triumphalism and the suggestion that a whole bunch of tough problems in CS (parallelism, program verification of real systems) are about to be solved by the majesty of strongly-typed functional languages is awfully familiar from the way Bob was talking about 15-20 years ago.
We certainly have seen many interesting research papers, type systems and compilers since then, but I'm not sure whether much progress has been made on anything more visible to the much-maligned 'working programmer'.
He had better be right, or he'll be helping to produce a cohort of students who don't know a lot of stuff they might find themselves needing to know! (Of course, I realize that Harper doesn't control the entire CMU curriculum, so it's quite possible that despite his views, CMU students will end up studying the "not worth studying" versions of parallelism/architecture/etc. problems and solutions in other courses.)
Bob and his cronies aren't even _close_ to "controlling the entire CMU curriculuum" and I doubt that they would try to eliminate the study of architecture, other languages, etc. - they are ideologues, not morons. And when you look at the summary of the actual course in question there's an awful lot of very reasonable middle-of-the-road content that you would likely want to expose a well-rounded CS student to.
They spend a lot of time on lectures with titles like "recursion" and less time on "worshipping the graven idol of SML". :-)
Still, I too am worried that such a partisan course is placed so centrally in the sequence. The PL researchers at CMU have shown form at various times in aggressively pushing their point of view in grad core courses and ugrad compulsory courses.
Don't know how true this is at other universities, but this doesn't sound like my experience at all. :)
