At my university, pragmatic programming courses were part of the math department. If students want to learn to program, perhaps they should take programming courses rather than CS courses, instead of compromising the education of full-time CS students. The courses do have to be available though, and not all universities provide them unfortunately.

My alma mater is having this fight between the CS departments and engineering/physics/etc. The CS department switched the first two courses of the intro sequence from C/Java to Scala, moving C to later in the curriculum. Instead of C/Java/C++ in the first three semesters, it's now Scala/Scala/C++.

The department only has 7 professors and is struggling to even offer enough intro classes for their own majors, much less for students in other majors who only need a single CS credit. The engineering department is upset because they want their students to learn C. Physics wants them to know something else, the business department wants them exposed to a tiny bit of Java and so on.

When I started in 2008, there were about 30 freshman taking CS1. Now it's >150 last I heard. They really had no choice but to (diplomatically) tell the other departments to go pound sand. They can't compromise their own majors in favor of those from another department.

My guess is they aren't the only CS department facing this problem.

To followup with a note from the article: "A very practical reason for preferring functional programming in a freshman course is that most students already have a certain familiarity with imperative programming. Facing them with the novelty of functional programming immediately drives home the message that there is more to programming than they thought."

It's no surprise that this attitude can discourage students without programming experience... A parallel intro track seems like a nice solution that has worked in a number of schools.

That actually did bother me in the letter.

He states:

-Most students taking CS courses are already familiar with an imperative laguage.

-we are all shaped by the tools we train ourselves to use, and in this respect programming languages have a devious influence: they shape our thinking habits.

This would imply that most CS students already come pre-ruined. At that point then, does it matter what language is picked?

Another alternative would be to start functional languages with data structures and algorithm courses(Generally taken sophomore year, and one of the first CS specific classes taken), and use that to fix broken habits. idk if the professors though want to take time to teach a new language if students already know one.

This is the same guy who said

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

and

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."

and

"FORTRAN, 'the infantile disorder', by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use."

Basically he's a mathematician who codes, and who wants code to be math.

Unfortunately in the real world code is also politics, business, history, sociology, and psychology. The math part is important, but it's not the whole story.

He's often funny, in a dry way, but it's useful to understand that he's actually not very insightful about the psychology of effective programming.

He praises mathematical intuition, and he wants to develop it, but he doesn't seem to have considered the possibility that simply throwing Haskell at people, or asking them to work through formal methods, may not be the best way to do that.

There's almost no useful research I know of that examines what mathematical intuition is, and even less about whether it's teachable. So Haskell and formal methods may help some people some of the time. But it's not in any way a given that they're the best of all possible teaching methods.

He also misses an entire class of UI/UX bugs where the code works exactly as it's designed to, and is provably formally correct, but an application is useless because the UI is incomprehensible and/or misleading and/or actively distracting to the task at hand.

Ironically, it's exactly that interface between fuzzy human expectations and implicit modelling tendencies and the rigidity of code that causes the most issues for practical projects.

This doesn't just apply to applications - it also applies to languages, operating systems, and development environments, some of which add unnecessary cognitive loads which make programmer mistakes more likely.

His solution - formal rigour - only works if you can formulate a problem precisely in the first place.

The set of problems where it's possible to do that doesn't come close to covering all the problem spaces touched by computing.

I've always dreamed of building a programmable calculator that runs a lightweight Python (or Haskell) interpreter to replace all that obsolete TI crap that most schools use. I would have loved that kind of thing as a kid.