C. A. R. Hoare

Charles Antony Richard Hoare (Tony Hoare or C.A.R. Hoare, born January 11, 1934) is a British computer scientist, and winner of the 1980 Turing Award. He is best known for his fundamental contributions to the definition and design of programming languages, and for the development of Quicksort, the world's most widely used sorting algorithm.

• [About Algol 60] Here is a language so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors.
  • Hints on Programming Language Design, December 1973.

• Programming languages on the whole are very much more complicated than they used to be: object orientation, inheritance, and other features are still not really being thought through from the point of view of a coherent and scientifically well-based discipline or a theory of correctness. My original postulate, which I have been pursuing as a scientist all my life, is that one uses the criteria of correctness as a means of converging on a decent programming language design—one which doesn’t set traps for its users, and ones in which the different components of the program correspond clearly to different components of its specification, so you can reason compositionally about it. [...] The tools, including the compiler, have to be based on some theory of what it means to write a correct program.
  • Oral history interview by Philip L. Frana, 17 July 2002, Cambridge, England; Charles Babbage Institute, University of Minnesota.

• "The real value of tests is not that they detect bugs in the code, but that they detect inadequacies in the methods, concentration, and skills of those who design and produce the code."
  • How Did Software Get So Reliable Without Proof? Lecture Notes in Computer Science vol 1051 1996 pp. 1-17 : FME '96: Industrial Benefit and Advances in Formal Methods, Third International Symposium of Formal Methods Europe, Co-Sponsored by IFIP WG 14.3, Oxford, UK, March 18-22, 1996, Proceedings.

• "The most important property of a program is whether it accomplishes the intentions of its user."
  • An Axiomatic Basis for Computer Programming, vol 12 n. 10, Communications of the ACM, October 1969.

1980 Turing Award Lecture[1]; Communications of the ACM 24 (2), (February 1981): pp. 75-83.

• 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.

• [About Fortran] On October 11, 1963, my suggestion was to pass on a request of our customers to relax the ALGOL 60 rule of compulsory declaration of variable names and adopt some reasonable default convention such as that of FORTRAN. […] The story of the Mariner space rocket to Venus, lost because of the lack of compulsory declarations in FORTRAN, was not to be published until later.

• [About Algol 60] Due credit must be paid to the genius of the designers of ALGOL 60 who included recursion in their language and enabled me to describe my invention [Quicksort] so elegantly to the world.

• [About Algol 60 subset implementation] [E]very 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.

• [About Algol W] It was not only a worthy successor of ALGOL 60, it was even a worthy predecessor of PASCAL […] I was astonished when the working group, consisting of all the best known international experts of programming languages, resolved to lay aside the commissioned draft on which we had all been working and swallow a line with such an unattractive bait.

• [About Algol 68] The best we could do was to send with it a minority report, stating our considered view that, "… as a tool for the reliable creation of sophisticated programs, the language was a failure."

• [About PL/I] 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.

• [About Pascal] 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.

• [About 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. [...] It is not too late! I believe that by careful pruning of the ADA language, it is still possible to select a very powerful subset that would be reliable and efficient in implementation and safe and economic in use.

• I have learned more from my failures than can ever be revealed in the cold print of a scientific article. [...] [Failures] are much more fun to hear about afterwards; they are not so funny at the time.

• I have regarded it as the highest goal of programming language design to enable good ideas to be elegantly expressed.

• One fine morning, when the emperor felt hot and bored, he extricated himself carefully from under the mountain of clothes and is now living happily as a swineherd in another story. The tailor is canonized as the patron saint of all consultants, because in spite of the enormous fees he extracted, he was never able to convince his clients of his dawning realization that their clothes have no Emperor.

• Premature optimization is the root of all evil.
  • Quote due to Donald Knuth, "Structured Programming with Goto Statements", Computing Surveys 6:4 (December 1974), pp. 261–301, §1. Knuth refers to it as "Hoare's Dictum" 15 years later in "The Errors of TeX", Software—Practice & Experience 19:7 (July 1989), pp. 607–685. However, the attribution to Hoare is doubtful.[2]

Wikipedia has an article about:

C. A. R. Hoare