Adit Cookbook Pages

How Do We Tell Truths That Hurt?

Edsger W.Dijkstra wrote the following on 18 June 1975. Cobol and IBM are no longer the powers they were although new contenders have arrived to take their place.

Sometimes we discover unpleasant truths. Whenever we do so, we are in difficulties: suppressing them is scientifically dishonest, so we must tell them, but telling them, however, will fire back on us. If the truths are sufficiently impalatable, our audience is psychically incapable of accepting them and we will be written off as totally unrealistic, hopelessly idealistic, dangerously revolutionary, foolishly gullible or what have you. (Besides that, telling such truths is a sure way of making oneself unpopular in many circles, and, as such, it is an act that, in general, is not without personal risks. Vide Galileo Galilei.....)

Computing Science seems to suffer severely from this conflict. On the whole, it remains silent and tries to escape this conflict by shifting its attention. (For instance: with respect to COBOL you can really do only one of two things: fight the disease or pretend that it does not exist. Most Computer Science Departments have opted for the latter easy way out.) But, Brethren, I ask you: is this honest? Is not our prolonged silence fretting away Computing Science's intellectual integrity? Are we decent by remaining silent? If not, how do we speak up?

To give you some idea of the scope of the problem I have listed a number of such truths. (Nearly all computing scientists I know well will agree without hesitation to nearly all of them. Yet we allow the world to behave as if we did not know them....)

• · Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.
• · The easiest machine applications are the technical/scientific computations.
• · The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.
• · 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.
• · PL/I --"the fatal disease"-- belongs more to the problem set than to the solution set.
• · 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.
• · The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
• · APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums.
• · The problems of business administration in general and data base management in particular are much too difficult for people that think in IBMerese, compounded with sloppy English.
• · About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead.
• · Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
• · Many companies that have made themselves dependent on IBM-equipment (and in doing so have sold their soul to the devil) will collapse under the sheer weight of the unmastered complexity of their data processing systems.
• · Simplicity is prerequisite for reliability. [Handwritten annotation]
• · We can found no scientific discipline, nor a hearty profession on the technical mistakes of the Department of Defence and, mainly, one computer manufacturer.
• · The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity.
• · By claiming that they can contribute to software engineering, the soft scientists make themselves even more ridiculous. (Not less dangerous, alas!) In spite of its name, software engineering requires (cruelly) hard science for its support.
• · In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included.
• · Projects promoting programming in "natural language" are intrinsically doomed to fail.

prof.dr.Edsger W.Dijkstra
Burroughs Research Fellow

PS. If the conjecture "You would rather that I had not disturbed you by sending you this." is correct, you may add it to the list of uncomfortable truths.

I would be kinder to the modern, object oriented Basics and save my worries about the mental mutilation of student programmers for those who study those endless “How TO” books that tell you How but never Why.

I would add the horror of spreadsheets to the list. In the hands of some they become programming tools but the programs are written without structure or defence against error. The resulting undocumented messes are then passed on to others to compound every error, omission and assumption. I have never come across one that was reliable yet their users believe in the “results” implicitly - “...it must be right, it has come off the computer!”

Will “Natural Language” solve it all for software engineers? I wish I had read the comment on the topic above in 1975 but there again I was very confident and eager to break new ground when I tried it first.

The project was based upon a marketing database and got off to a good start. The relatively limited range of measures and time periods in the database applied a natural limitation to the range of things to be requested and so I felt comfortable building a parser to act as a link between English sentences typed in via a keyboard and the SQL commands I generated as  the basis of a prototype system. If I say it myself, it worked fine. My colleagues were able to type in data requests and enjoyed finding nouns and verbs that I had not yet built into the “engine” to try and catch the system out. I even constructed a “natural language” output that redefined the users data request in unambiguous English. The idea of this was to provide a check on what the user had requested – particularly where certain parts of the data request had to be inferred. Ultimately, the project failed to pass the “real user” test. One cause of failure was that the project predated the wide availability of PC based word processors and spreadsheets and my target users had very poor keyboard skills. The second problem was that the users found it just about impossible to describe what they wanted – let alone key a meaningful data request into a computer terminal.

The problem was that English was not a natural language for these people when describing this data. The solution to this particular problem came from one of the marketing men – yes we can learn from other disciplines you know – even marketing! He constructed a little booklet that had pictures of the possible report formats, column headings, rows, subtotals and so on. All anyone had to do was ‘mix and match’ from the ‘Basic Off-line Operations Key’ and they had a ‘recipe’ of half a dozen digits or so that even those with five thumbs could type into a keyboard. Bingo! We had found and implemented the symbolic natural language for this database.