[This is the infamous section of the book Lucid the Dataflow Programming Language where I make fun of everyone working on imperative languages. It was very popular but many people hated it even though no individual is named. In a companion post I cite it as an example of a Career Limiting Move. It didn’t quite kill my career though it didn’t help. I’m sure there were a number of meetings I wasn’t invited to and program committees I was left out of because of it. Hmmm … was that really a bad thing?]

[Btw the late Ed Ashcroft was a co-author of the book but had no part in writing this section. Wise man.]

1.5 Some Suggested Solutions

Even the most enthusiastic supporter of imperative languages will admit that something is very wrong. There are, however, a number of different attitudes regarding the “software crisis” and the “parallelism problem”. Here are some of the more common points of view (slightly parodied). [slightly!]

First there is what we might call the Clint Eastwood outlook.

[This holds up well – though it was written more than 30 years ago!]

According to this “rugged Western” point of view, programming is a demanding and difficult activity, and always will be, but still “a programmer’s gotta do what a programmer’s gotta do”. According to the ‘Cowboys’ the actual problem is a shortage of real programmers who are clever enough and tough enough to get the job done. The Cowboys learned programming the hard way, through long hours ‘in the saddle’ (i.e., at the terminal) and expect everyone else to do the same. If you make mistakes, it is ‘yer own darned fault’. Cowboys generally distrust ‘book larnin’ (theory) and ‘new-fangled’ languages. They sneer at ‘greenhorns’ who complain that PL/I

[PL/I? A big complex language devised by IBM and long since moribund   More complicated than C++ and clumsy like ADA. ADA? … don’t ask.]

is too big or that C is too low level.

[Yes, C, the same C that is still popular today. Basically unchanged, like Clint himself]

To them, PL/I does not have enough features and C is not dirty enough. What they want is even more powerful tools which allow them to get even closer to the computer and make it ‘dance’.

The Cowboys certainly deserve our admiration. The best of them (the real Straight Shooters) can produce impressive software that ordinary programmers are too ‘chicken’ even to try. Nevertheless, we have to ask ourselves whether or not there are enough really tough Wranglers to go around. There almost certainly are not, and we have to resign ourselves to the fact that most software will be written by ordinary, humble Trail Hands

[I just described typical software engineers as “trail hands”. I’m sure that went down well.]

—not by the Wyatt Earps of the terminal.

Next we have what we call the “Mr. Wizard” school of thought.

[Mr Wizard was a well known TV science popularizer a few decades ago. He was the Bill Nye of his day.]

The Wizards are in many ways the opposite of the Cowboys, but they agree on one thing: programming and programming languages are inherently very complex. The problem, as the Wizards see it, is that we lack a good theoretical/mathematical understanding of these languages. The Wizards have searched through many a dusty tome of ancient lore. They have learned the Arts Magical, the Logyck Symbolyck and the Calculus of Lambda. They have conjured up the mighty names of Tarski, Church and Curry.

[Famous logicians. I actually met the first two as a grad student at Berkeley. In fact I took a seminar from Tarski.]

The ultimate dream of the Wizards is a system for formal program verification. This would allow programmers (assisted by Wizards) to produce airtight proofs that given programs are correct—no matter how appallingly bad the language or program might be. Program verification is therefore a kind of philosopher’s stone which will turn base programs into gold. As John McCarthy [inventor of LISP] (1965, p. 219) said,

The prize to be won if we can develop a reasonable mathematical theory of computation is the elimination of debugging. Instead, a programmer will present a computer-checked proof that the program has the desired properties.

The problem, of course, is that no amount of Wizards’ wand waving changes the basic nature of the von Neumann [imperative] languages. The Wizards did succeed in producing formal specifications—but these specifications also took on telephone-book proportions, full of incomprehensible lambda- calculus expressions.

[This was semantics of programming languages, a big deal in its day. As dead now as PL/I]

Similarly, proving the correctness of ‘real’ programs has also turned out to be impractical. [still is, with specialized exceptions.] The Wizards ran into trouble with the ‘dirty’ features (side effects, goto statements, aliasing) mentioned. Of course, these are exactly the features the Cowboys love the most.

[Well, the goto has almost completely disappeared.]

There is a third group, however, which views the antics of the Cowboys and Wizards with self-righteous disdain. The members of this group are wild-eyed fanatics, the Preachers of the gospel of structured programming.

The Preachers subscribe to a computer science version of the doctrine of Original Sin. They believe that human beings are born with an inherent tendency to be careless and make mistakes (the sin of Sloth), and to undertake tasks that are beyond the meagre powers of their mortal minds (the sin of Pride). The wages of sin are, of course, bugs. If bugs (and software problems in general) are to be avoided, programmers must abandon their evil ways and adopt the way of the righteous. Programmers are exhorted to adopt some rigorous discipline (methodology) of programming whose rituals will prevent the software from being possessed by evil spirits.

[Nobody talks about “structured programming” any more because everybody practices it. But other cults have arisen.]

The disciples of structured programming have indeed achieved important successes in the fight against bad software. Nevertheless the evil that lurks within the hearts of men and women has proved harder to vanquish than was expected. Abstention plays an important role in the Preachers’ teachings—abstention from features like goto statements and pointer variables, those forbidden apples that tempt programmers into wickedness. Programmers, however, have great difficulty in avoiding these forbidden fruits, as we have already noticed. The Preachers dream of a pure and holy language from which all wicked features shall be banished. In practice, though, the designers of these ‘structured-programming’ languages are always in the end forced to compromise their principles in the name of efficiency. The faithful are therefore faced with a terrible but unavoidable dilemma: they can choose to be virtuous and write programs that are correct but inefficient, or they can choose to be wicked and produce programs that are efficient but bug ridden. “Why,” the Preachers must ask themselves, “does the Devil have all the fast programs?”

There is, however, a fourth and more optimistic point of view which shares the Preacher’s low opinion of unaided human capabilities but which offers a more down-to-earth solution. We are referring to the “we have the technology” school of thought.

The Boffins agree that human weakness is the root cause of the software crisis, and that therefore mere humans cannot produce software naked and unarmed.

[ “Boffin” is British slang for a techy – remember, the book was written and published in the UK. Radar, for example, was invented by Boffins.]

The armament the Boffins offer, however, is physical and mechanical, not moral and spiritual. Their goal is to supply the programmer with a complete selection of powerful programming tools: structured editors, diagnostic compilers, clever type checkers, and sophisticated debugging systems. Their aim is to produce a kind of Bionic Programmer, a technologically enhanced Superhero who can battle the bugs on equal terms.

[The Bionic Man was a US TV character who was a cyber enhanced man with telescope eyes, steel legs etc. Sort of like Robocop or Ironman.]

There is no denying, of course, that the ingenious devices found on the ‘programmer’s work- bench’ can be extremely useful. The problem is that they can amplify programmers’ weaknesses as well as their strengths. The gadgets in the Million Dollar Programmer’s

[the program about the bionic man was called The Million Dollar Man. That was when a million dollars was a lot of money.]

utility belt [some mixed metaphors here] can just as easily allow their user to produce colossal bug-infested programs and then allow him to waste stupendous quantities of resources in debugging. Could the superprograms produced by the new generation of Superprogrammers breed a new race of terrifying superbugs? Will programmers need even more powerful tools as a result? Will these tools generate even more terrifying bugs? There could be no end to the process!

[There isn’t. I have two friends in the industry each maintaining legacy programs millions of lines long]

The ambitions of what we call the “DIY” or “Mr. Fixit” school are by contrast far more modest. According to this point of view, the software crisis is the result of serious flaws in the imperative languages. These flaws are not, however, the result of weaknesses inherent in the whole von Neumann approach; but rather the product of design error. All that is needed is a little tinkering, a few new parts here and there, the removal of a few troublesome features, and all will be well.

[Python 3.8 introduces the “walrus” operator. That should set things straight.]

Now it is certainly true that the imperative languages can be improved, and often fairly simple changes can bring great benefits. The problem is that one change leads to another—and an improvement in one area can have disastrous consequences in another. We have already seen that tinkering with ALGOL and FORTRAN has not always been successful.

[ALGOL? A predecessor of PL/I. FORTRAN is still FORTRAN, though now it looks like C]

This is especially true when an attempt is made to bolt on features for ‘concurrency’ or even ‘dataflow’.