计算机程序设计作为一种艺术

1974 年 ACM 图灵奖演讲

[以下图灵奖颁奖词由 1974 年图灵奖委员会主席 Bernard A. Galler 宣读；本演讲于 11 月 11 日在圣迭戈举行的 ACM 年会上发表。]

ACM 的 A.M. Turing Award 每年授予一位个人，以表彰他对计算共同体所作出的技术性贡献。尤其是，这些贡献应当对计算机领域的一个主要分支产生过重要影响。

“1974 年 A.M. Turing Award 授予 Stanford University 的 Donald E. Knuth 教授，以表彰他在算法分析和程序设计语言设计方面的多项重大贡献，尤其表彰他通过一系列著名著作，对‘计算机程序设计的艺术’所作出的最重要贡献。这些书中汇集的技术、算法和相关理论，已经成为课程建设的焦点，并对计算机科学形成了组织性的影响。”

这样一段正式陈述，还不足以恰当地说明 Don Knuth 在计算机科学以及整个计算机产业中所扮演的角色。依我的经验，第一位图灵奖得主 Alan J. Perlis 教授每次参加会议时，总能对正在讨论的问题提供一种洞见，使它成为随后讨论的焦点。非常相似地，Don Knuth 在他优秀的书籍和论文集中提供的词汇、例子、算法和洞见，已经开始进入计算机领域几乎每个方向的许多讨论之中。这并非轻易可得。每一位作者都知道，即使只写一卷书，也需要大量细致的组织和艰苦工作。更何况 Knuth 要规划七卷书，并如此认真、周密地着手实施他的计划；我们越发应当赞赏他必然拥有的清晰视野、耐心和精力。

值得注意的是，在他的著作出版了三卷之后，这个奖以及他获得的其他奖项就已经授予了他。我们显然已经准备好向所有人表明：我们感谢 Don Knuth 对这一学科的投入和贡献。我很高兴能担任评选 Don Knuth 获得 1974 年 ACM A.M. Turing Award 的委员会主席。

Donald E. Knuth

CACM, December 1974

1959 年，Communications of the ACM 开始出版时，ACM 编辑委员会成员在说明 ACM 期刊宗旨时说过这样一句话 [2]：

“如果计算机程序设计要成为计算机研究与开发中的一个重要组成部分，就必须实现程序设计从艺术（art）到严谨科学（science）的转变。”

这样的目标在随后几年里不断反复出现；例如，1970 年我们读到“把程序设计艺术转变为科学的最初步骤”[26]。与此同时，我们确实已经用一种极其简单的方式，把我们的学科变成了一门科学：只要决定把它称为“计算机科学”就行了。

这些说法背后隐含着一种观念：如果某个人类活动领域被归为“艺术”，那就有某种不理想之处；它必须先成为一门 Science，才真正有地位。另一方面，我已经花了 12 年多时间写一套名为 The Art of Computer Programming 的书。人们经常问我为什么选这个题名；事实上，有些人显然不相信我真的这么做了，因为我至少见过一条书目引用，把这些书称为 The Act of Computer Programming。

在这次演讲中，我会试着说明为什么我认为“Art”是合适的词。我会讨论一件事物成为艺术，而不是科学，意味着什么；我会试着考察艺术究竟是好事还是坏事；我还会试着说明，对这个主题采取恰当的看法，会帮助我们所有人改进当前工作的质量。

我第一次被问到书名的来由，是在 1966 年左右，也就是上一次 ACM 全国会议在南加州举行的时候。当时这些书还没有出版，我记得自己在会议酒店和一位朋友共进午餐。他知道我那时已经多么自负，于是问我是不是打算把书命名为 An Introduction to Don Knuth。我回答说，恰恰相反，我是按他的名字命名这些书。他的名字是：Art Evans。（The Art of Computer Programming，本人。）

从这个故事我们可以看出，“art”这个词不止一种含义。事实上，这个词最妙的地方之一，就是它被用于许多不同意义，而每一种意义都很适合用来谈计算机程序设计。准备这次演讲时，我去图书馆查找人们历年来如何谈论“art”这个词；在书库里度过几天非常迷人的时光之后，我得出结论：“art”一定是英语中最有趣的词之一。

古代的 Arts

如果回到拉丁语词根，我们会发现 ars, artis 的意思是“技能”。也许值得注意的是，对应的希腊词是 τέχνη，也就是 “technology” 和 “technique” 的词根。

今天，当有人说起“art”时，你可能首先想到绘画、雕塑这样的“美术”；但在二十世纪以前，这个词通常以一种很不一样的意义使用。由于“art”的这种较古老意义仍然保存在许多习语中，尤其是在我们把 art 与 science 相对照时，所以我想花接下来的几分钟，谈谈古典意义上的 art。

在中世纪，最早的大学是为了教授所谓的七门“自由艺术”（liberal arts）而建立的，即语法、修辞、逻辑、算术、几何、音乐和天文学。注意，这同今天文理学院的课程设置很不一样，而且最初七门自由艺术中至少有三门是计算机科学的重要组成部分。在那时，“art”指的是由人的智力设计出来的东西，相对于源于自然或本能的活动；“liberal” arts 是被解放的、自由的艺术，相对于耕作之类的手工艺术（manual arts）（参见 [6]）。在中世纪，“art”这个词单独使用时通常指逻辑 [4]，而逻辑通常指三段论的研究。

Science 与 Art

“science”这个词似乎有许多年都和“art”大致同义；例如，人们也谈到七门自由科学，它们和七门自由艺术是同一组学科 [1]。十三世纪的 Duns Scotus 把逻辑称为“科学中的科学，艺术中的艺术”（参见 [12], p. 34f）。随着文明和学问的发展，这两个词逐渐取得越来越独立的意义：“science”用于表示知识，“art”用于表示知识的应用。因此，天文学这门 science 是航海这门 art 的基础。这种情形几乎完全类似于我们今天区分“science”和“engineering”的方式。

十九世纪有许多作者谈论 art 与 science 的关系，我认为最好的讨论来自 John Stuart Mill。他在 1843 年说过以下这些话 [28]：

要为一门 art 奠定基础，常常需要若干门 science。人类事务如此复杂，以至于要做成一件事，往往必须知道许多事物的性质和属性……一般而言，Art 由 Science 的真理构成，只是这些真理按照最便于实践的顺序排列，而不是按照最便于思考的顺序排列。Science 对其真理进行归类和安排，是为了使我们能一眼尽可能多地把握宇宙的一般秩序。Art……则从 science 领域中彼此最遥远的部分，把那些与产生实际生活所要求的每一种效果所需的各种不同而异质的条件有关的真理汇集起来。

当我查阅这些关于“art”含义的资料时，我发现至少两个世纪以来，作者们一直在呼吁从 art 向 science 转变。例如，1784 年一本矿物学教科书的序言写道 [17]：“在 1780 年以前，矿物学虽然被许多人作为一门 Art 相当好地理解，却几乎不能被视为一门 Science。”

按照大多数字典，“science”指以一般“定律”的形式经过逻辑安排和系统化的知识。科学的好处在于，它让我们不必在每一个个案中都从头思考；我们可以把思维转向更高层次的概念。正如 John Ruskin 在 1853 年所写 [32]：“科学的工作，是用事实取代表象，用证明取代印象。”

在我看来，如果我研究过的这些作者今天还在写作，他们会同意如下描述：Science 是我们理解得足够透彻、以至于可以教给计算机的知识；而如果我们还没有完全理解某事，处理它就是一门 art。由于算法或计算机程序的概念为我们检验某个给定主题上的知识深度提供了极其有用的标准，从 art 走向 science 的过程，意味着我们学会如何使某件事自动化。

人工智能已经取得了重要进展，然而在可预见的未来，计算机能做的事情与普通人能做的事情之间仍然存在巨大差距。人们在说话、聆听、创造，甚至在程序设计时获得的神秘洞见，仍然超出科学的能力范围；我们所做的几乎一切仍然是一门 art。

从这个角度看，把计算机程序设计变成一门 science 当然是可取的；而且自从我在演讲开头引用那些话以来的 15 年里，我们的确已经走了很长一段路。十五年前，人们对计算机程序设计的理解还很糟，几乎没有人想到要证明程序正确；我们只是反复摆弄程序，直到我们“知道”它能工作。那时我们甚至不知道如何以任何严格方式表达“一个程序是正确的”这个概念。只是到了最近几年，我们才开始了解程序被书写和理解所依赖的抽象（abstraction）过程；这些关于程序设计的新知识正在实践中带来巨大收益，即使很少有程序真的以完全严格的方式被证明正确，因为我们已经开始理解程序结构（program structure）的原则。关键在于，当我们今天编写程序时，我们知道，如果真的愿意，原则上可以构造它们正确性（correctness）的形式证明（formal proof），因为我们已经理解这种证明如何表述。这种科学基础正在产生比从前更可靠得多的程序；在从前，直觉是正确性的唯一基础。

“自动程序设计”（automatic programming）领域是当今人工智能研究的主要方向之一。它的支持者很乐意做一次题为“计算机程序设计作为一件遗物”的演讲（意思是程序设计已经仅仅成为过去时代的遗迹），因为他们的目标是创造机器：只给出问题规格说明（problem specification），它们就能写出比我们更好的程序。就个人而言，我不认为这样的目标会被完全达到；但我确实认为他们的研究极其重要，因为我们关于程序设计学到的一切，都有助于提升我们自己的艺术性（artistry）。在这个意义上，我们应当不断努力，把每一种 art 都转变为 science：在这个过程中，我们推进了 art。

Science 与 Art 并存

我们的讨论表明，计算机程序设计到现在既是一门 science，也是一门 art，而且这两个方面很好地互相补充。显然，考察这类问题的大多数作者都会得出同样结论：无论他们的主题是什么，它既是一门 science，也是一门 art（参见 [25]）。我找到一本 1893 年写的基础摄影书，其中说“摄影影像的显影既是一门 art，也是一门 science”[13]。事实上，我第一次拿起字典研究“art”和“science”这两个词时，恰好瞥见编者序言，开头就说：“编纂词典既是一门 science，也是一门 art。”Funk & Wagnall 词典的编者 [27] 观察到，对词语资料进行艰苦的积累和分类具有科学性质，而措辞精当的定义则要求能以简洁和精确写作：“没有 art 的 science 很可能无效；没有 science 的 art 必然不准确。”

准备这次演讲时，我翻查了 Stanford 图书馆的卡片目录，想看看其他人如何在书名中使用“art”和“science”这两个词。结果相当有趣。

例如，我找到了两本题为 The Art of Playing the Piano 的书 [5]、[15]，以及另外一些题为 The Science of Pianoforte Technique [10]、The Science of Pianoforte Practice [30] 的书。还有一本书叫 The Art of Piano Playing: A Scientific Approach [22]。

然后，我找到一本可爱的小书，题为 The Gentle Art of Mathematics [31]；这让我有点难过，因为我无法诚实地把计算机程序设计称为一门“温柔的艺术”。几年前我就知道一本名为 The Art of Computation 的书，它于 1879 年在旧金山出版，作者名叫 C. Frusher Howard [14]。这是一本关于实用商业算术的书，到 1890 年已经以不同版本售出 40 多万册。读到序言时我觉得很有趣，因为它显示 Howard 的哲学和他使用这个题名的意图与我的相当不同；他写道：“关于数的 Science 的知识并不十分重要；在 Reckoning 这门 Art 中的技能则绝对不可或缺。”

有几本书在题名中同时提到 science 和 art，尤其是 Maharishi Mahesh Yogi 的 The Science of Being and Art of Living [24]。还有一本书叫 The Art of Scientific Discovery [11]，分析科学上一些伟大发现是如何产生的。

关于“art”这个词的古典意义，就说到这里。实际上，当我选择自己书的题名时，我主要想到的并不是这个意义上的 art，而是它今天的联想含义。在我的检索中出现的最有趣的书，可能是 Robert E. Mueller 近期的一部作品，题为 The Science of Art [29]。在我提到的所有书中，Mueller 这本最接近表达我今天演讲想作为中心主题的东西，也就是我们今天所理解的真正艺术性。他观察到：“人们曾经认为，艺术家的想象视角会置科学家于死地。而科学的逻辑似乎也会毁掉所有可能的艺术幻想。”他接着探讨了 science 与 art 的综合实际上会带来的好处。

科学式方法通常可用这些词来描述：逻辑的、系统的、非个人的、冷静的、理性的；而艺术式方法则可用这些词来描述：审美的、创造性的、人文的、焦虑的、非理性的。在我看来，这两种看似矛盾的方法，对计算机程序设计都有很大价值。

Emma Lehmer 在 1956 年写道，她发现编码“既是一门严格的 science，也是一门迷人的 art”[23]。H.S.M. Coxeter 在 1957 年说，他有时觉得自己“更像艺术家而不是科学家”[7]。这正是 C.P. Snow 开始警告受教育者中“两种文化”日益两极化的时候 [34]、[35]。他指出，如果我们要取得真正进步，就需要结合科学价值和艺术价值。

艺术作品

当我坐在听众席里听一场长演讲时，我的注意力通常在这个时刻开始减弱。所以我想知道，你们是不是也有点厌倦我关于“science”和“art”的长篇论述了？不过我真的希望你们仍然能仔细听完剩下的部分，因为接下来是我感受最深的部分。

当我说计算机程序设计是一门 art 时，我主要是把它看作一种艺术形式，是在审美意义上说的。作为教育者和作者，我工作的主要目标是帮助人们学会如何写出美的程序。正因为如此，我最近得知 [32] 我的书居然出现在 Cornell University 的 Fine Arts Library 时，特别高兴。（不过，这三卷书显然整整齐齐地摆在书架上，并没有被使用，所以恐怕图书馆员按字面理解我的题名，也许是弄错了。）

我的感觉是，当我们准备一个程序时，它可以像作诗或作曲一样；正如 Andrei Ershov 所说 [9]，程序设计可以同时给我们智力上的满足和情感上的满足，因为掌握复杂性并建立一套一致规则系统，本身就是一项真正的成就。

此外，当我们阅读别人的程序时，我们可以认出其中有些是真正的艺术作品。我仍然记得，1958 年读到 Stan Poley 的 SOAP II 汇编程序清单时，那种强烈的兴奋感；你们也许觉得我疯了，而且自那以后风格当然已经大大改变，但当时能看到一个系统程序可以如此优雅，对我意义重大，尤其是与我同一时期研究的其他清单中那些笨重编码相比。即使在汇编语言（assembly language）中也能写出美的程序，这种可能性正是最初让我迷上程序设计的原因。

有些程序优雅，有些精致，有些闪耀。我的主张是：我们可以写出宏伟的程序、高贵的程序、真正壮丽的程序！

品味与风格

程序设计风格（programming style）的观念终于开始走到前台；我希望你们大多数人都读过 Kernighan 和 Plauger 那本出色的小书 Elements of Programming Style [16]。在这方面，最重要的是我们所有人都要记住，并不存在一种“最佳”风格；每个人都有自己的偏好，试图把人们强行塞进一种不自然的模子是错误的。我们常常听到一句话：“我不懂艺术，但我知道自己喜欢什么。”重要的是，你真的喜欢自己正在使用的风格；它应当是你偏好用来表达自己的最佳方式。

Edsger Dijkstra 在他的 Short Introduction to the Art of Programming [8] 的序言中强调了这一点：

我的目的是传达程序设计中良好品味和风格的重要性，[但是] 这里提出的具体风格要素，只是为了说明一般而言可以从“风格”中获得什么好处。在这一点上，我觉得自己类似于音乐学院的作曲教师：他并不教学生如何创作某一首特定交响曲；他必须帮助学生找到自己的风格，并向他们说明这意味着什么。（正是这个类比使我谈到“The Art of Programming”。）

现在我们必须问自己，什么是好风格，什么是坏风格？在评价别人的工作时，我们不应当过分僵硬。十九世纪早期哲学家 Jeremy Bentham 是这样说的 [3], Bk. 3, Ch. 1：

优雅和品味的评判者自以为是人类的恩人，而他们实际上只是别人快乐的打断者……没有哪种品味值得冠以“好”的称号，除非它是对某些活动的品味，而这些活动在它们实际产生的快乐之外，还结合了某种偶然的或未来的效用；也没有哪种品味值得被描述为“坏”，除非它是对某种具有有害倾向的活动的品味。

当我们用自己的偏见去“改造”别人的品味时，我们可能在无意识中剥夺了他某种完全正当的快乐。这就是为什么我并不谴责程序员做的许多事情，尽管我自己绝不会享受那样做。重要的是，他们在创造某种他们自己觉得美的东西。

在我刚才引用的段落中，Bentham 确实给了我们一些关于审美原则的建议：有些审美原则优于另一些，标准就是结果的“效用”。在建立个人美感标准时，我们有一定自由；但如果我们认为美的东西也被其他人认为有用，那就特别好。我必须承认，我真的很喜欢写计算机程序；而且在某种意义上，我尤其喜欢写那些能带来最大好处的程序。

当然，程序可以在许多意义上是“好的”。首先，一个程序能正确工作尤其是好事。其次，当适应需求出现时，一个不难修改的程序通常也是好程序。如果程序对于懂得相应语言的人来说易读、易懂，这两个目标就都能实现。

生产用程序好的另一种重要方式，是它能优雅地与用户交互，尤其是在从输入数据中的人为错误中恢复时。编写有意义的错误消息，或者设计不易出错的灵活输入格式，确实是一门艺术。

程序质量的另一个重要方面，是实际使用计算机资源的效率。我遗憾地说，如今许多人正在谴责程序效率（program efficiency），告诉我们这是一种坏品味。原因在于，我们现在正经历一种反作用：在过去，效率曾经是唯一被认可的优良标准，过去的程序员往往过分专注于效率，以至于写出不必要地复杂的代码；这种不必要复杂性的结果，是由于调试和维护困难，净效率反而下降。

真正的问题在于，程序员花了太多时间在错误的地点、错误的时机担心效率；过早优化（premature optimization）是程序设计中万恶之源（至少是大多数恶的根源）。

我们不应当因小失大，也不应当总是用总运行时间或空间中百分之几的得失来思考效率。买车时，我们许多人几乎不会在意价格相差 50 或 100 美元；但为了把一件 50 美分的东西以 25 美分买下，我们却可能专门跑到某一家商店去。我的观点是，效率有其时间和位置；我已经在关于结构化程序设计（structured programming）的论文中讨论了它的恰当角色，那篇论文刊登在当前这一期 Computing Surveys [21]。

更少设施，更多乐趣

关于审美满足，我注意到一件颇为奇特的事情：当我们用有限工具完成某事时，我们的快乐会显著增强。例如，我个人最满意、最自豪的程序，是我曾经为一台原始小型机写过的编译器；那台机器只有 4096 个字的内存，每个字 16 位。在如此严格的限制下完成某件事，会让人觉得自己像真正的名家高手。

类似现象出现在许多其他语境中。例如，人们似乎常常会爱上自己的 Volkswagen，却很少爱上自己的 Lincoln Continental（后者大概运行得好得多）。我学习程序设计时，一种流行的消遣是尽可能用只装得下一张穿孔卡（punched card）的程序做最多事情。我想，正是同一种现象，使 APL 爱好者津津乐道于他们的“单行程序”（one-liner）。如今我们教授程序设计时，有一个奇怪事实：学生通常要到上过一门允许他们在小型机上获得“亲手操作”经验的课程之后，才会真正被计算机科学吸引。至少一开始，使用那些配备精巧操作系统和语言的大型机器，并不会真正激发对程序设计的热爱。

如何应用这个原则来增加程序员工作的乐趣，并不是显而易见的。如果经理突然宣布新机器的内存只有旧机器的一半，程序员当然会抱怨。我也不认为任何人，即使是最投入的“程序设计艺术家”，会被期待欢迎这样的前景，因为没有人喜欢无谓地失去设施。另一个例子也许有助于澄清这种情况：电影制作者在 1920 年代强烈抵制有声电影的引入，因为他们完全有理由为自己无需声音也能传达话语的方式感到自豪。类似地，真正的程序设计艺术家很可能会反感更强大设备的引入；今天的大容量存储设备往往破坏了我们旧式磁带排序方法中的许多美感。但是今天的电影制作者并不想回到无声电影，不是因为他们懒，而是因为他们知道，用改进后的技术同样完全可以拍出美的电影。他们艺术的形式变了，但其中仍然有大量空间留给艺术性。

他们是如何培养技能的？多年来，最优秀的电影制作者通常似乎是在相对原始的环境中学会其艺术的，常常是在电影工业有限的其他国家。近年来，我们在程序设计方面学到的最重要东西，似乎也来自那些无法使用非常大型计算机的人。这个故事给我的寓意是，我们应当在自己的教育中利用有限资源这个观念。偶尔编写一些“玩具”程序，对我们所有人都有益；在这些程序中设置人为限制，迫使我们把能力推到极限。我们不应当一直生活在奢侈环境中，因为那会使我们变得迟钝。全力处理小问题的艺术，会磨利我们面对真正问题时的才能；这种经验也会帮助我们在较少受限的设备上完成工作时获得更多快乐。

同样地，我们也不应当回避“为艺术而艺术”；不应当因为程序只是为了好玩而感到内疚。我曾经从编写一个单语句 ALGOL 程序中获得极大乐趣：它以一种非常不寻常的方式调用 innerproduct 过程，使其计算第 m 个素数，而不是内积 [19]。几年前，Stanford 的学生曾经热衷于寻找最短的 FORTRAN 自打印程序（self-printing program），也就是程序的输出与它自己的源文本完全相同。同一个问题也在许多其他语言中被考察。我并不认为他们花时间做这件事是浪费；我前面引用过的 Jeremy Bentham 也不会否认这种消遣的“效用”[3], Bk. 3, Ch. 1。他写道：“恰恰相反，没有什么东西的效用更加无可争辩。如果不是把效用归于快乐的来源，那么还应当归于什么呢？”

提供美的工具

现代艺术的另一个特征，是它强调创造性。如今许多艺术家似乎并不在乎创造美的东西；重要的只是观念的新颖。我并不是建议计算机程序设计应当在这个意义上像现代艺术，但这确实引出一个我认为重要的观察。有时我们被分配到一项几乎无望地枯燥的程序设计任务，完全没有任何创造性出口；在这种时候，一个人很可能来对我说：“所以程序设计是美的？你慷慨陈词，说我应当以创造优雅迷人的程序为乐，这当然很好；可我到底该怎样把这一团乱麻变成一件艺术作品？”

确实，并不是所有程序设计任务都会有趣。想想“受困的家庭主妇”，她每天都要擦同一张桌子：并不是每种情境都有创造性或艺术性的空间。但即使在这类情况下，仍然有一种办法可以大幅改善局面：如果我们有美的东西可以使用，做例行工作仍然会令人愉快。例如，如果餐桌设计优美、由优质硬木制成，一个人日复一日地擦拭餐桌，也会真的觉得愉快。

因此，我想把结束语献给系统程序员和机器设计者，是他们生产出其余人必须使用的系统。请给我们那些使用起来令人愉快的工具，尤其是用于日常任务的工具；不要给我们一些不得不与之搏斗的东西。请给我们那些鼓励我们写出更好程序的工具，也就是通过增强我们这样做时的快乐来鼓励我们。

我很难说服大学一年级新生相信程序设计是美的，因为我首先不得不告诉他们如何打出“slash slash JoB equals so-and-so”。即使作业控制语言（job control language）也可以被设计得令人愉快，而不只是严格地满足功能。

计算机硬件设计者可以让机器使用起来愉快得多，例如提供满足简单数学定律的浮点算术（floating-point arithmetic）。大多数机器目前提供的设施，使严格误差分析（error analysis）这项工作变得无望地困难；但设计得当的运算，会鼓励数值分析人员（numerical analyst）提供具有有保证的精度（certified accuracy）的更好子程序（参见 [20], p. 204）。

我们也来考虑软件设计者能做什么。保持系统用户士气的最好方法之一，是提供他可以与之交互的例程。我们不应当把系统做得过于自动化，以至于动作总是在幕后发生；我们应当给程序员-用户（programmer-user）一个机会，把他的创造力引向有用的渠道。所有程序员有一个共同点：他们喜欢和机器一起工作；所以让我们让他们留在回路中。有些任务最好由机器完成，另一些则最好由人的洞见完成；一个设计得当的系统会找到恰当平衡。（多年来我一直试图避免误导性的自动化，参见 [18]。）

程序度量工具（program measurement tools）就是一个很好的例子。多年来，程序员并不知道真实的计算成本如何分布在他们的程序中。经验表明，几乎每个人对自己程序中真正瓶颈所在都有错误想法；当程序员从未获得按代码行划分的成本明细时，效率改进尝试如此经常地误入歧途，也就不足为奇了。他的工作有点像一对新婚夫妇试图规划平衡预算，却不知道食物、住所、衣物等各项分别要花多少钱。我们一直给程序员的，只是一个优化编译器（optimizing compiler）；它神秘地对自己翻译的程序做些事情，却从不解释它做了什么。幸运的是，我们现在终于看到了一些系统的出现，它们承认用户具有一定智力；它们自动为程序提供检测设施（instrumentation），并就真实成本提供适当反馈。这些实验系统取得了巨大成功，因为它们带来了可度量的改进，尤其因为它们使用起来很有趣；所以我相信，使用这类系统成为标准操作过程，只是时间问题。我在 Computing Surveys [21] 中的论文进一步讨论了这一点，并提出了一些其他想法，说明适当的交互式例程（interactive routine）可以用哪些方式增强用户程序员的满足感。

语言设计者也有义务提供鼓励良好风格的语言，因为我们都知道，风格会受到表达它所使用语言的强烈影响。当前人们对结构化程序设计的兴趣高涨，已经揭示出我们现有语言中没有一种真正适合处理程序结构和数据结构；理想语言应当是什么样，也并不清楚。因此，我期待未来几年在语言设计方面出现许多细致的实验。

总结

总结一下：我们已经看到，计算机程序设计是一门 art，因为它把积累起来的知识应用到世界之中，因为它需要技能和巧思，尤其因为它产生美的对象。一个在潜意识中把自己看作艺术家的程序员，会享受自己所做的事情，并且会把它做得更好。因此，当人们在计算机会议上谈论 state of the Art 时，我们可以为此感到高兴。

References

Bailey, Nathan. The Universal Etymological English Dictionary. T. Cox, London, 1727. See “Art,” “Liberal,” and “Science.”
Bauer, Walter F., Juncosa, Mario L., and Perlis, Alan J. ACM publication policies and plans. J. ACM 6 (Apr. 1959), 121-122.
Bentham, Jeremy. The Rationale of Reward. Trans. from Theorie des peines et des recompenses, 1811, by Richard Smith, J. & H. L. Hunt, London, 1825.
The Century Dictionary and Cyclopedia 1. The Century Co., New York, 1889.
Clementi, Muzio. The Art of Playing the Piano. Trans. from L’art de jouer le pianoforte by Max Vogrich. Schirmer, New York, 1898.
Colvin, Sidney. “Art.” Encyclopaedia Britannica, eds 9, 11, 12, 13, 1875-1926.
Coxeter, H. S. M. Convocation address, Proc. 4th Canadian Math. Congress, 1957, pp. 8-10.
Dijkstra, Edsger W. EWD316: A Short Introduction to the Art of Programming. T. H. Eindhoven, The Netherlands, Aug. 1971.
Ershov, A. P. Aesthetics and the human factor in programming. Comm. ACM 15 (July 1972), 501-505.
Fielden, Thomas. The Science of Pianoforte Technique. Macmillan, London, 1927.
Gore, George. The Art of Scientific Discovery. Longmans, Green, London, 1878.
Hamilton, William. Lectures on Logic 1. Win. Blackwood, Edinburgh, 1874.
Hodges, John A. Elementary Photography: The “Amateur Photographer” Library 7. London, 1893. Sixth ed, revised and enlarged, 1907, p. 58.
Howard, C. Frusher. Howard’s Art of Computation and golden rule for equation of payments for schools, business colleges and self-culture …. C.F. Howard, San Francisco, 1879.
Hummel, J.N. The Art of Playing the Piano Forte. Boosey, London, 1827.
Kernighan B.W., and Plauger, P.J. The Elements of Programming Style. McGraw-Hill, New York, 1974.
Kirwan, Richard. Elements of Mineralogy. Elmsly, London, 1784.
Knuth, Donald E. Minimizing drum latency time. J. ACM 8 (Apr. 1961), 119-150.
Knuth, Donald E., and Merner, J.N. ALGOL 60 confidential. Comm. ACM 4 (June 1961), 268-272.
Knuth, Donald E. Seminumerical Algorithms: The Art of Computer Programming 2. Addison-Wesley, Reading, Mass., 1969.
Knuth, Donald E. Structured programming with go to statements. Computing Surveys 6 (Dec. 1974), pages in makeup.
Kochevitsky, George. The Art of Piano Playing: A Scientific Approach. Summy-Birchard, Evanston, II1., 1967.
Lehmer, Emma. Number theory on the SWAC. Proc. Syrup. Applied Math. 6, Amer. Math. Soc. (1956), 103-108.
Mahesh Yogi, Maharishi. The Science of Being and Art of Living. Allen & Unwin, London, 1963.
Malevinsky, Moses L. The Science of Playwriting. Brentano’s, New York, 1925.
Manna, Zohar, and Pnueli, Amir. Formalization of properties of functional programs. J. ACM 17 (July 1970), 555-569.
Marckwardt, Albert H, Preface to Funk and Wagnall’s Standard College Dictionary. Harcourt, Brace & World, New York, 1963, vii.
Mill, John Stuart. A System Of Logic, Ratiocinative and Inductive. London, 1843. The quotations are from the introduction, §2, and from Book 6, Chap. 11 (12 in later editions), §5.
Mueller, Robert E. The Science of Art. John Day, New York, 1967.
Parsons, Albert Ross. The Science of Pianoforte Practice. Schirmer, New York, 1886.
Pedoe, Daniel. The Gentle Art of Mathematics. English U. Press, London, 1953.
Ruskin, John. The Stones of Venice 3. London, 1853.
Salton, G.A. Personal communication, June 21, 1974.
Snow, C.P. The two cultures. The New Statesman and Nation 52 (Oct. 6, 1956), 413-414.
Snow, C.P. The Two Cultures: and a Second Look. Cambridge University Press, 1964. Copyright 1974, Association for Computing Machinery, Inc. General permission to republish, but not for profit, all or part of this material is granted provided that ACM’s copyright notice is given and that reference is made to the publication, to its date of issue, and to the fact that reprinting privileges were granted by permission of the Association for Computing Machinery.