Some advice on teaching FP

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.

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.

Oddly enough, I'll be TAing an identical class this summer. Any quick tips or advice? (I'll probably also send you a message later as well). Thanks.

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...

[1] http://mitpress.mit.edu/sicp/

[2] http://www.htdp.org/

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.