“The Emperor’s Old Clothes” By C.A.R. Hoare
Today I read the following lecture from C.A.R. Hoare: “The Emperor’s Old Clothes” - http://www.cs.ucsb.edu/~ravenben/papers/coreos/Hoa81.pdf. This is a text with more than 25 years, but so up-to-date. Below follows some excerpts copied from the document.
“…I have regarded it as the highest goal of programming
language design to enable good ideas to be elegantly expressed…”
“…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….”
“…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….”
“…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….”
“…The fourth principle was that the compiler should use only a single pass….”
“…First, we certainly want programs to be read by people and people prefer to read things once in a single pass….”
“…Finally, to structure a compiler according to the syntax of its input language makes a great contribution to ensuring its correctness….”
“…told me of their fond memories of the Elliott ALGOL System and the fondness is not due just to nostalgia, but to the efficiency, reliability, and convenience of that early simple ALGOL System…”
“…That was my second language design proposal. I am still most proud of it, because it raises essentially no problems either for the implementor, the programmer, or the reader of a program….”
“…I wrote documents which described the relevant concepts and facilities and we sent them to existing and prospective customers….”
“…I gave it less attention than the company’s new products and almost failed to notice when the deadline for its delivery passed without event. The programmers revised their implementation schedules and a new delivery date was set some three months ahead in June 1965. Needless to say, that day also passed without event. By this time, our customers were getting angry and my managers instructed me to take personal charge of the project. I asked the senior programmers once again to draw up revised schedules, which again showed that the software could be delivered within another three months. I desperately wanted to believe it but I just could not. I disregarded the schedules and began to dig more deeply into the project….”
“…Even worse, we had failed to simply count the space used by our own software which was already filling the main store of the computer, leaving no space for our customers to run their programs. Hardware address length limitations prohibited adding more main
storage….”
“…Clearly, the original specifications of the software could not be met and had to be drastically curtailed….”
“…The programmers responded magnificently to the challenge. They worked nights and days to ensure completion of all those items of software which were needed by the ALGOL compiler. To our delight, they met the scheduled delivery date; it was the first major item of working software produced by the company over a period of two years….”
“…The programmers responded magnificently to the challenge. They worked nights and days to ensure completion of all those items of software which were needed by the ALGOL compiler. To our delight, they met the scheduled delivery date; it was the first major item of working software produced by the company over a period of two years….”
“…There was no escape: The entire Elliott 503 Mark II software project had to be abandoned, and with it, over thirty man-years of programming effort, equivalent to nearly one man’s active working life, and I was responsible, both as designer and as manager, for wasting it….”
“…They had realized long ago that software to the original specification could never have been delivered, and even if it had been, they would not have known how to use its sophisticated features, and anyway many such large projects get cancelled before delivery. In retrospect, I believe our customers were fortunate that hardware limitations
had protected them from the arbitrary excesses of our software designs….”
“…’You know what went wrong?” he shouted - he always shouted - “You let your programmers do things which you yourself do not understand.’…”
“…We first listed the recent major grievances of our customers: Cancellation of products, failure to meet deadlines, excessive size of software, not justified by the usefulness of the facilities provided, excessively slow programs, failure to take account of customer feedback….”
“…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…”
“…Our main failure was overambition. “The goals which we have attempted have obviously proved to be far beyond our grasp.” There was also failure in prediction, in estimation of program size and speed, of effort required, in planning the coordination and interaction of programs, in providing an early warning that things were going wrong….”
“…We failed in giving clear and stable definitions of the responsibilities of individual
programmers and project leaders…”
“…The last section of our inquiry into the failure dealt with the criteria of quality of software. ‘In the recent struggle to deliver any software at all, the first casualty has been consideration of the quality of the software delivered. The quality of software is measured by a number of totally incompatible criteria, which must be carefully balanced in the design and implementation of every program.’ We then made a list of no less than seventeen criteria which has been published in a guest editorial in Volume 2 of the journal, Software Practice and Experience….”
“…In no case would we consider a request for a feature that would take more than three months to implement and deliver. The project leader would then have to convince me that the customers’ request was reasonable, that the design of the new feature was appropriate, and that the plans and schedules for implementation were realistic. Above all, I did not allow anything to be done which I did not myself understand. It worked!…”
“…While I was working at Elliott’s, I became very interested in techniques for formal definition of programming languages….”
“…As an alternative, I proposed that a programming language definition should be formalized as a set of axioms, describing the desired properties of programs written in the language….But I did not see how to actually do it….”
“…I was delighted by his draft design which avoided all the known defects of ALGOL 60 and included several new features, all of which could be simply and efficiently implemented, and safely and conveniently used…”
“…I gave desperate warnings against the obscurity, the complexity, and overambition 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 rush is mad indeed, because it leads into a trap from which there is no escape. 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….”
“…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….”
“…For as long as I was involved in this project, I urged that the language be simplified, if necessary by subsetting, so that the professional programmer would be able to understand it and be able to take responsibility for the correctness and cost effectiveness of his programs. I urged that the dangerous features such as defaults and ON-conditions be removed. I knew that it would be impossible to write a wholly reliable compiler for a language of this complexity and impossible to write a wholly reliable program when the correctness of each part of the program depends on checking that every other part of
the program has avoided all the traps and pitfalls of the language….”
“…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….”"…The mistakes which have been
made in the last twenty years are being repeated today on an even grander scale. I refer to a language design project which has generated documents entitled strawman, woodenman, tinman, ironman, steelman, green and finally now ADA….For none of the evidence we have so far can inspire confidence that this language has avoided any of the problems that have afflicted other complex language projects of the past….”
“…This is the strangest paradox of the whole strange project. 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.”