In 1980, Tony Hoare (recipient of the Turing award) delivered a lecture titled The Emperor’s Old Clothes. Tony discusses some of his successes and failures, and what he has learned from them. His conclusions ring true – the importance of simplicity, documentation, etc.
Some notes are included below of things that stand out, but just read the original lecture – it is well worth 30 minutes of your time.
Notes:
- I would like to talk informally about myself, my personal experiences, my hopes and fears, my modest successes, and my rather less modest failures.
- I have regarded it as the highest goal of programming language design to enable good ideas to be elegantly expressed.
- Priciples:
- Security.
- 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.
- brevity of object code produced
- efficient entry and exit conventions for functions
- the compiler should use only a single pass
- It retrospect, I believe our customers were fortunate that hardware limitations had protected them from the arbitrary excesses of our software designs. In the present day, users of microprocessors benefit from a similar protection – but not for much longer.
- that deficiencies in original program specifications could be made up by the skill of a technical writing department . . , was misguided; the design of a program and the design of its specification must be undertaken in parallel by the same person, and they must interact with each other. A lack of clarity in specification is one of the surest signs of a deficiency in the program it describes, and the two faults must be removed simultaneously before the project is embarked upon." I wish I had followed this advice in 1963; I wish we all would follow it today.
- Our main failure was over-ambition. “The goals which we have attempted have obviously proved to be far beyond our grasp.”
- 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.
- Above all, I did not allow anything to be done which I did not my self understand. It worked!
- I gave desperate warnings against the obscurity, the complexity, and over-ambition of the new design, but my warnings went unheeded. I conclude that 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 demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature. It also 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 d o this until it is too late.
- Far from wishing to simplify the language, the working group actually asked the authors to include even more complex features like overloading of operators and concurrency.
- A feature which is omitted can always be added later, when its design and its implications are well understood. A feature which is included before it is fully understood can never be removed later.
- This report was later suppressed by IFIP, an act which reminds me of the lines of Hilaire Belloc,
- But scientists, who ought to know
- Assure us that it must be so
- Oh, let us never, never doubt
- What nobody is sure about.
- 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.
- 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 that 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.
- To have our best advice ignored is the common fate of all who take on the role of consultant, ever since Cassandra pointed out the dangers of bringing a wooden horse within the walls of Troy.