Classics of CS - Epsiode 1- The Empror’s Old Cloth

Recently in CACM Opinion blog appeared an entry which caught my attention. Classics of Computer Science!, Selma Tekir in her post points out 10 CS Classics written by most famous and distinguished researchers in the field of computing. In this note I would like to point out a few of the passages from the first item on the list, The Empror’s Old cloth by C.A.R. Hoare. Quick look at Sir Charles Antony Richard Hoare at Wikipedia and we will realize his genius and great career, probably the most notable one is development of QuickSort algorithm.

In his article appeared in CACM 1981 he shares with us several stories of his failures that I believe are very good lessons for everyone in this industry. From project management and overambitious goals to programming language design and failures of languages such as ALGOL, ADA and PL/1. His great emphasis on simplicity of language design, to the extend that he considers features like Exception Handling harmful while we take them as granted in many languages these days, is very clear.

I would like, for the sake of having a summary of his ideas quote a few passages of his work here.

In his implementation of a subset of ALGOL language for Elliott machines he points out several important principles that even today are neglected in many languages that to many are considered powerful and very successful. I personally agree with his view that a feature rich language is not necessarily a successful language or suitable for many applications.

The principles are as follows:

1. "The first principle was security: The principle that every syntactically incorrect program should be rejected by the compiler and that every syntactically correct program should give a result or an error message that was predictable and comprehensible in terms of the source language program itself. Thus no core dumps should ever be necessary. It was logically impossible for any source language program to cause the computer to run wild, either at compile time or at run time. A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. 
   Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.
2. The second principle in the design of the implementation was brevity of the object code produced by the compiler and compactness of run time working data. There was a clear reason for this: The size of main storage on any computer is limited and its extension involves delay and expense. A program exceeding the limit, even by one word, is impossible to run, especially since many of our customers did not intend to purchase backing stores. This principle of compactness of object code is even more valid today, when processors are trivially cheap in comparison with the amounts of main store they can address, and backing stores are comparatively even more expensive and slower by many orders of magnitude. If as a result of care taken in implementation the available hardware remains more powerful than may seem necessary for a particular application, the applications programmer can nearly always take advantage of the extra capacity to increase the quality of his program, its simplicity, its ruggedness, and its reliability. 
3. The third principle of our design was that the entry and exit conventions for procedures and functions should be as compact and efficient as for tightly coded machine-code subroutines. I reasoned that procedures are one of the most powerful features of a high level language, in that they both simplify the programming task and shorten the object code. Thus there must be no impediment to their frequent use. 
4. The fourth principle was that the compiler should use only a single pass. The compiler was structured as a collection of mutually recursive procedures, each capable of analysing and translating a major syntactic unit of the language - a statement, an expression, a declaration, and so on. It was designed and documented in ALGOL 60, and then coded into decimal machine code using an explicit stack for recursion. Without the ALGOL 60 concept of recursion, at that time highly controversial, we could not have written this compiler at all. "

For me the most important principle is security which seems to me, even today, this important principle of a programming language design is being neglected.

When discussing his failure on delivering Elliott 503 Mark II software he says:

"I was surprised that he[Andrew St. Johnston] had even heard of me. "You know what went wrong?" he shouted - he always shouted - "You let your programmers do things which you yourself do not understand.""

This reminded me a passage from Dr. Freb Brook's "The Design of Design: Essays from a Computer Scientist". He was project manager of probably the most famous product of IBM,OS/360. He describes one of their failures in previous projects as that they neglected the fact that all the beautiful and at the same time sophisticated features of their product should be understood by a single programmer and so when no single one of them, who are developing the system, could not have an overall understanding of the system and need to ask questions from different people for even simple application scenarios how can the project even reach its milestones? I will try to find the exact quote to put here and make this summary complete.

In general Hoare's view of language design seems to me a minimalistic approach, instead of finding a language that suites everyone build a language that can be extended for different purposes, and his best example for his case is PASCAL. 

"This is the strangest paradox of the whole strange project[Development of ADA]. If you want a language with no subsets, you must make it small.

You include only those features which you know to be needed for every single application of the language and which you know to be appropriate for every single hardware configuration on which the language is implemented. Then extensions can be specially designed where necessary for particular hardware devices and for particular applications. That is the great strength of PASCAL, that there are so few unnecessary features and almost no need for subsets. That is why the language is strong enough to support specialized extensions - Concurrent PASCAL for real time work, PASCAL PLUS for discrete event simulation, UCSD PASCAL for microprocessor work stations. If only we could learn the right lessons from the successes of the past, we would not need to learn from our failures"

On emphasizing his view he severely criticizes design of ADA, which was funded by US Department of Defence and was origianlly built to be reliable,simple, developed program be readable and finally language definition formal, by saying: 

"In this last resort, I appeal to you, representatives of the programming profession in the United States, and citizens concerned with the welfare and safety of your own country and of mankind: Do not allow this language in its present state to be used in applications where reliability is critical, i.e., nuclear power stations, cruise missiles, early warning systems, anti-ballistic missile defense systems. The next rocket to go astray as a result of a programming language error may not be an exploratory space rocket on a harmless trip to Venus: It may be a nuclear warhead exploding over one of our own cities. An unreliable programming language generating unreliable programs constitutes a far greater risk to our environment and to our society than unsafe cars, toxic pesticides, or accidents at nuclear power stations. Be vigilant to reduce that risk, not to increase it."

In conclusion he tells us the story of the Empror's Old Cloth which I shall leave it for the reader to read and enjoy.

As Selma describes in her blog post there are important lessons to be learned from each one of these classics, this paper gives us a sense of the greatest challenges of computing from 1960s to1980s and to my understanding to certain extends even up to this day.