I'm a TA (one of four) for the course Harper is talking about in this post. As they say on reddit, ask me anything. I do not guarantee I'll answer. I'll check back in in the morning.
Has Harper actually done any real programming of significance? I am an "industry programmer" who has a pretty strong theoretical bent (have a math degree rather than CS, have read most of Harper's papers on the type theory and semantics of module systems), but when I read his blog posts I get the feeling that when it comes to programming he doesn't really know what's up.
I dunno, I just TA for the guy. I suspect it depends on what you mean by "real programming of significance". I can tell you that Harper is really damn smart. I'd be truly surprised if he was bad at programming. But his actual experience, I don't know. He hasn't written any code for the course itself, but that's not really his role.
That's hard for me to know because, as a TA, I mostly get to see students when they're confused or frustrated, up against a deadline. The fact that almost all our students are also enrolled in spring 251 with Luis von Ahn, and therefore incredibly overworked, doesn't help.
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 brief: I prefer Haskell, but I think it has its flaws, and I understand why we're not using it as a teaching language.
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.