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