Dijkstra on Haskell and Java (2001)

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.

Lack of familiarity doesn't make it fancy, and for a software engineer it shouldn't make it scary either. One of the largest parts of our job is learning unfamiliar things.

Dijkstra's advocating a Sapir–Whorf[1] of programming languages, which I long suspected to be true; but haven't been able to rigorously prove or disprove.

[1] http://en.wikipedia.org/wiki/Linguistic_relativity

>Something that succeeds as well as Java has to have some actual value

Well yes, it has some value. However, just because a lot of people like/believe something doesn't make it good/true.

It's not like corporations have some vast conspiracy in place to encourage the use of Java; it's simply that Java, for a number of reasons, is attractive to middle-management types, even though it's not the best language to make good software. That's not necessarily a criticism of Java; from many perspectives, making good software is not the primary goal.

Dijkstra's big thing was prioritizing good software over cheap software. This may not be a realistic goal, but it certainly explains why he preferred Haskell to Java.

He wrote some really good essays on why you need languages like Haskell to raise the overall quality of software floating about. The more you can shift the burden of guaranteeing correctness away from humans and towards infallible mechanical systems (like Haskell's relatively powerful type system), the more likely you are to end up with good/correct software.

I don't know if I can agree with this. I've invested a significant amount of time in learning about monads (and functors, applicatives, monoids, and more from the bestiary of commonly used category theoretic structures in Haskell) and I find them quite challenging to grasp in their full generality. While specific use-cases are readily understood, getting to the heart of what a monad "is" has taken me time, and I honestly don't believe I've properly grasped it yet.

So I think there's a spectrum of understanding and effective use when it comes to monads and other algebraic structures like these, and I'm skeptical when people say, "oh yeah, a monad is just X, it's simple." I've said that myself in the past and I was wrong, and so were most of the people I've heard say that.

To put it another way: when I hear people who know what they're talking about say it's simple, they are talking about its structure, not about understanding what it is and how it is used. In that sense it is quite simple. But as Euclid said, there's no royal road to geometry (er, or monads...).