C.A.S Hoare 1980年图灵奖演讲
But Scientists, who ought to know,
Assure us that they must be so.
Oh! let us never, never doubt
What nobody is sure about!
轶事
- 快速排序得以实现和发表得益于Algol引入的递归
软件开发
Hoare详述了Elliot 503 Mark II软件开发失败的经历。有趣的是，这类软件工程的失败产物在当时因为硬件限制而无法交付：
“In 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.” (Hoare, 1981, p. 79)
而如今机器性能的提升某种程度上容忍了错误设计的软件的存在。事实上Hoare略带讽刺地评论道：
“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.” (Hoare, 1981, p. 82)
Hoare对该项目失败的总结如下：规约的不明晰指示实现的错误
“The hope ”… 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.” (Hoare, 1981, p. 79)
当管理者将自己都不清楚的目标分发下去的时候，不能指望程序员能依靠技巧完成任务
“At last, there breezed into my office the most senior manager of all, a general manager of our parent company, Andrew St. Johnston. I was surprised that he 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.“” (Hoare, 1981, p. 79)
毕竟编程和软件设计与工程是两码事儿
“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.” (Hoare, 1981, p. 80)
程序语言设计
首先一点，程序语言应当保证安全。这依赖于良好的语言设计，即使这会增加运行时开销或防碍用户的使用
“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.” (Hoare, 1981, p. 76)
另一个例子就是来自Algol的显式变量声明，这虽然可以算是一种冗余，但是可以防止拼写错误等情况下出现的难以检测的问题。
“I was eventually persuaded of the need to design programming notations so as to maximize the number of errors which cannot be made, or if made, can be reliably detected at compile time.” (Hoare, 1981, p. 77)
同理，在考虑Algol中Switch替代时，Hoare提出用类似条件语句的case，而不是标签与goto。
设计语言同样会面临上述软件开发中的问题，事实上就在Hoare的Elliot 503 Mark II项目失败之后，Algol野心勃勃的新版规范也步了后尘。
“When any new language design project is nearing completion, there is always a mad rush to get new features added before standardization. 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.” (Hoare, 1981, p. 81)
PL/I的失败同样来自于不切实际的目标和复杂度。
语言应该避免引入过度复杂的机制，因为程序设计语言的目标是帮助编写复杂的程序，而不是成为复杂性的一环。
“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.” (Hoare, 1981, p. 82)
如有必要，将语言设计为尽量通用和精简，然后为特定场景做扩展。
“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.” (Hoare, 1981, p. 82)
Hoare如此关注语言设计的原因可以总结如下：
“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.” (Hoare, 1981, p. 83)