Bob is an incredibly smart and accomplished guy, and I imagine the students will get a lot from the course.
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'.
The more worrying thing from a pedagogical point of view is his claim that a bunch of problems that programmers outside academia regularly deal with are non-problems and don't need to be taught, because they're cruft that is on the verge of obsolescence.
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.)
This is a first year course. I think the idea is to teach students a `right way' before sullying their minds with real world `wrong ways' and more practical concerns.
That does require that the right way is right! Harper is quite intelligent, but I think his particular views on what constitutes the "right way" to do programming are decidedly minority ones, even among academic computer scientists. Some have relatively large minority support (his views on FP are common among PLs researchers), but others get more and more into small-minority territory. He essentially believes that ML does things right or close to right, while every other language is horribly broken (Haskell somewhat less broken than others, but still fatally flawed), which isn't a very common view. His views on dynamic languages, OO, automata theory, and anything else that isn't FP are also quite partisan and often not widely held.
I'm a bit uncomfortable with a partisan approach to an intro-level course, that presents the "correct" way to do things according to one particular professor's views. That sort of partisan-indoctrination-as-curriculum is something people rightfully complain about in some humanities departments. I don't think we'd do well in CS to follow their lead, with different universities teaching different partisan versions of CS 101, trying to convince their students that the "ML way" or the "Haskell way" or the "OO way" or the "Lisp way" is the one and only right way to do programming.
> sullying their minds with real world `wrong ways' and more practical concerns
Why do computers exist, and why do people study them? Because they're very useful for "practical concerns". Practical concerns should be at the heart of any study of computers and computation; it's impractical for them not to be.
I'm not sure I agree -- it's my experience that too often `practical concerns' become an excuse to teach faddish details of what is being done in the `real world' now, instead of provide any sense of the parts of the field which don't change with each new technology.
I'd rather teach a new hire who had worked through a curriculum built around SICP[1] or HtDP[2] the languages and technologies we actually use here -- even though we never write a line of scheme -- then teach a student who got a four year `Computer Science' education focused on the details of a particular programming language or technology stack how to use that very stack to accomplish lasting things...
This is a false dichotomy. I would rather a student who had gotten a coherent CS education in some random Algol-descended language who had worked on a curriculum consisting of a great big chunk of algorithms, systems work (os, compilers, networks) and architecture.
I am finding many "high-church-of-X" approaches to CS increasingly unsatisfying, whether it's rabid OO, the rabid 'functional programming solves all problems', Stephanov's 'grind away for 6-12 months putting the basics on a RIGOROUS FOUNDATION without solving a single interesting problem' book, etc...
My feeling is that many of these religious attitudes will not survive the first contact with a truly serious enemy - in other words, a system with substantial complexity that can't be expressed in an elegant way. I don't think it's a mistake that strong FP guys spend so much time hacking around on compilers, type systems, regular expressions, etc. Maybe a foray into scientific computing - but if you're biting off problems that were previously tackled by a bunch of nested loops in HPF, maybe these aren't the world's most hairy algorithms either.
To be fair, this course should be put in perspective with a range of other compulsory 100-level and 200-level courses at CMU. This is flagged - subtly, to be sure - occasionally within the blog post (language like "for this kind of programming").
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.
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.
"One beautiful feature of the language-based approach is that we start with a very familiar model of computation, the evaluation of polynomials over the reals. It’s very familiar for all students, and I think they find it very satisfying precisely because it has a direct computational flavor."
Don't know how true this is at other universities, but this doesn't sound like my experience at all. :)
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'.