Entrapping Minnows in the Jar with PL/1

In 1972, Edsger Dijkstra's Turing Award Lecture was published in Communications of the ACM. This lecture, The Humble Programmer, is now available on-line at the Dijkstra Archive, and still greatly worth reading. Dijkstra writes about the need for hierarchical artefacts and for systematic and modest programming languages; about the power of BNF; and about how, when registering for marriage, Amsterdam City Council prohibited him from declaring his profession as "programmer".

He writes too about Fortran, Algol, and PL/1; and here we have the source of the notorious comparison between PL/1 and fatal disease:

Finally, although the subject is not a pleasant one, I must mention PL/1, a programming language for which the defining documentation is of a frightening size and complexity. Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit. I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language — our basic tool, mind you! — already escapes our intellectual control. And if I have to describe the influence PL/1 can have on its users, the closest metaphor that comes to my mind is that of a drug. I remember from a symposium on higher level programming language a lecture given in defense of PL/1 by a man who described himself as one of its devoted users. But within a one-hour lecture in praise of PL/1. he managed to ask for the addition of about fifty new "features", little supposing that the main source of his problems could very well be that it contained already far too many "features". The speaker displayed all the depressing symptoms of addiction, reduced as he was to the state of mental stagnation in which he could only ask for more, more, more... When FORTRAN has been called an infantile disorder, full PL/1, with its growth characteristics of a dangerous tumor, could turn out to be a fatal disease.

Contemporary computing is not like that at all, of course. Nowadays, it's buzzwords we addict to, as practice lolls distendedly abloat with pluggable application-layer strategic enterprise integration, synergistic and refactored, agent-oriented, multi-tiered. I wish to engage synergistically with e-business analysts to craft a synergistic combination of meta-models and a multi-tier overlay topology, communicating and inter-operating in seamless and synergistic ways (this would be more fun in bed), refining my priorities and prioritising my refinements. Thus shall I define a unique distribution solution: total, holistic, and logistic; adaptive, reactive, and proactive. It will distribute this rubbish direct to the nearest skip.

By the way, my trousers became seamless recently and the pockets started to drop out. I had to take them to the local dry-cleaner's for repair. Since seamlessness is bad, why is seamless inter-operation good? Why does no-one ever talk of tactical enterprise integration? And can anyone show me a formal definition of "pluggable"? I accidentally dropped a digestive biccie into my cappuccino this morning; when I tried to fish it out between my fingers, it softened, bent, and dissipated into sludge. Now these buzzwords feel like biscuits drifting through the coffee of my brain, ablating into sludge-trails in their wake.

But back in 1972, it was not buzzword bloat but language bloat one was warned against. And hence my title. Googling last week for Dijkstra's exact words, I found a paper by Richard C. Holt called Teaching the Fatal Disease (or) Introductory Computer Programming Using PL/I. Everyone knows you can catch a monkey by filling a jar with rice, honey, or whatever other food monkeys adore. The monkey reaches in to the jar, grabs the bait and makes a fist, then the fist is too big for the mouth of the jar, but the monkey is too greedy to open its fist and free its hand. Well, minnows act the same way when programming in PL/I:

You catch minnows by placing a jar with a big hole on the outside and a little hole on the inside (like a funnel) into a stream. Swimming happily along, a minnow cogitates the advantages of jar-insidedness versus the more traditional jar-outsidedness he is used to. He learns a small part of PL/I, discovers it is better than, say, Cobol, and swims easily into the jar by converting his first program to PL/I.

Any committee on PL/I will probably spend a significant portion of its time calculating the mean and standard deviation of the individual member's favourite locations for semi-colons, and will probably not produce a reasonable recommendation on PL/I (which would not be enforced anyway).

Why? Because, it seems, PL/I considerably advanced the dissemination of semi-colons by requiring them in intriguing new places, such as after END. So you can tell where END ends. Anyway, Holt's message, like Dijkstra's, is this. There is virtue in simplicity.