Bookshelf Classic: Selected Writings On Computing by Edsgar W. Dijkstra
"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."
I couldn't help but smile, and while I easily agreed, I wanted to know more about his thinking. Dijkstra's full essay can be found in his book Selected Writings On Computing: A Personal Perspective. (See chapter EWD498, or go online.) Titled "How Do We Tell Truths that Might Hurt?" his criticism extended to other languages such as FORTRAN and COBOL, and even to PL/I, a language I sort of liked:
"PL/I —'the fatal disease' — belongs more to the problem set than to the solution set."
Ouch.
Dijkstra's tone was understated humor -- less to make you laugh and more to have you reevaluate some of the norms in computer science. Keep in mind that this essay was written in 1975, and with regard to BASIC, rightly savaged the then version that used line numbers and GOTOs.
But at the end of the essay, Dijkstra made one last criticism that was very applicable to our modern times: "Projects promoting programming in 'natural language' are intrinsically doomed to fail."
The New York Times recently described a nascent technology called Codex: "You can ask, in plain English, for snow falling on a black background, and it will give you code that creates a virtual snowstorm. If you ask for a blue bouncing ball, it will give you that, too."
No doubt Codex will get better and better, but that won't matter; Dijkstra would still be right. The larger problem isn't asking an AI to write code, but in properly framing the problem, working out a solution, and identifying the inevitable compromises therein.
Chapter EWD594, A Parable, illustrated this point very well. Dijkstra wrote about a railway company that, in an effort to save money, opted for toilets in only half the cars instead of every car. Easily said and just as easily done, the train yard completed its task. But soon, complaints came pouring in. While 50% of the fleet did have railcars with toilets, some trains were composed mostly of cars with toilets while other trains had barely any toilets at all.
Thus, the train yard was instructed to compose trains with an equal number of railcars with toilets and railcars without. A new problem emerged, however, as now some trains had its toilets bunched together in one half of the train.
The train yard was then directed to alternate between railcars with toilets and railcars without. But this revealed yet another problem; because the toilets were located at one end of a railcar, the distance between successive toilets in the train were, in some instances, nearly three railcar lengths apart.
To evenly distribute the distance between toilets, the railcars with toilets needed to be oriented in the same direction. But the problems didn't end here. What of the passenger in urgent need who did not know which way to go to find the nearest toilet?
You'll have to read the entire essay yourself to see how the problem was ultimately solved, and to feel the full effect of Dijkstra's humor and style.
I am not opposed to AI, but an AI that helped me write code would amplify my haste, leading me to solve one problem only to discover -- or worse, create -- another. Dijkstra advocated thinking about a problem first, establishing boundaries, and simplifying. I started out wondering about Dijkstra's thinking, and ended up learning that program correctness and reliability underscored all of his work.
Bonus:
As famous as Dijkstra was for bashing BASIC, he was better known for "Dijkstra's Algorithm" which is used to find the shortest path between two points. The video is accessible to a first year computer science major, and gives a sense of what your mapping software is doing as you drive to Grandma's house.
Comments