The Emperor’s Old Clothes
The Emperor’s Old Clothes C.A.R. Hoare, 1981
Today we’ll be looking at Tony Hoare’s ACM Turing Award lecture from 1980, as published in the CACM in 1981. It’s another piece that had a big influence on my professional career with its emphasis on the pursuit of simplicity, the need to tame complexity and ambition, and the dangers of committee-based design. These lessons are given around a main theme of programming language design. Sections of the paper were often quoted around the offices in the early days of SpringSource. Two quotes in particular stick in my mind:
There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult… It requires a willingness to accept objectives which are limited by physical, logical, and technological constraints, and to accept a compromise when conflicting objectives cannot be met. No committee will ever do this until it is too late.
And when discussing a language design and standardization project doomed to technical failure:
At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality which cannot be purchased in this way – and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.
The lecture tells some wonderful stories about Tony Hoare’s exploits in the design, implementation, and standardization of ALGOL, the technical committee for PL/1, and advice given to the designers of Ada. Along the way, you’ll also learn about the invention of the QuickSort algorithm, the case statement, and the axiomatic approach to computer programming.
Tony Hoare on Programming Language Design
Here I will cherry-pick some of Tony Hoare’s advice and wisdom on programming language design:
I have regarded it as the highest goal of programming language design to enable good ideas to be elegantly expressed.
We saw yesterday that there is essential complexity in software development. This has implications for language design:
Programmers are always surrounded by complexity; we cannot avoid it. Our applications are complex because we are ambitious to use our computers in ever more sophisticated ways. Programming is complex because of the large number of conflicting objectives for each of our programming projects. If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather than part of its solution.
Some uncommon wisdom in understanding that less can be more:
…The group’s first main task was to design a subset of the language which would remove some of its less successful features. Even in those days and even with such a simple language, we recognized that a subset could be an improvement on the original.
On the benefits of safety-first design and static type checking:
I was eventually persuaded of the need to design programming notations so as to maximise the number of errors which cannot be made, or if made, can be reliably detected at compile time.
Hoare describes implementing a subset of ALGOL 60 (beginning in 1961), and adopting the principle of security – every syntactically incorrect program should be rejected by the compiler, and every syntactically correct program should give a result or error message that was predictable and comprehensible in terms of the source language program itself. Following this principle led to the implementation of bounds-checking on arrays at runtime… (how much subsequent grief could we have saved if this lesson had been taken to heart by the wider community!)
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.
The perils of over-ambition
I’ll leave you with one last quote, and encourage you to read Hoare’s original lecture (link at the top) for more – I’m sure you’ll find it time well spent.
Our main failure was overambition… What was amazing was that a large team of highly intelligent programmers could labor so hard and so long on such an unpromising project. You know, you shouldn’t trust us intelligent programmers. We can think up such good arguments for convincing ourselves and each other of the utterly absurd. Especially don’t believe us when we promise to repeat an earlier success, only bigger and better next time.