[cafebeen]

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.

[navait]

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.

[TheOtherHobbes]

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.