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.