Algorithm 版 (精华区)

发信人: ssos (存在与虚无·守拙), 信区: Algorithm
标  题: 1974:图灵奖辞(4)
发信站: 哈工大紫丁香 (2003年02月22日10:10:58 星期六), 站内信件

===========
品味和风格
===========
现在，编程风格终于走到前台，我希望你们大多数看过Kernighan和Plauger的优秀小书<<

程序设计风格基础>> (Elements of Programming Style)[16] 。在此之际，我们所有人都

要记住，没有“最好”的风格，这很重要；每个人都有自己的偏好，把人强行压到不自然

的模子里是错误的。我们经常听到这个名言，“我对艺术一无所知，但我知道自己喜欢什

么”。重要的是你真的喜欢你采用的风格；它应该是你所倾睐的表达自己的最佳方式。


Edsger Dijkstra在他的“编程艺术短论”(Short Introduction to the Art of Program

ming)[8] 的前言中强调了这一点：

我的目的是宣扬在编程中良好的品味和风格的重要性，(但是) 所列举的风格的特例，只是

用来举例说明,就一般而言，能从“风格”中得到什么益处。在这方面，我感到和音乐学院

的教师类似：他不教学生对某个特定的交响乐如何作曲，他必须帮助学生找到他们自己的

风格，并且必须解释给他们，这种风格将意味着什么。(正是基于这种类比，让我谈论关于

“编程的艺术” 。)

现在，我们必须问自己，什么是好的风格，什么是坏的风格。在判定别人工作的时候，我

们不应该太教条。19世纪早期，哲学家Jeremy Bentham这样说[3，Bk.3,Ch.1]：

高雅和品位的鉴定者们自认为是人类的恩人，可是他们真正只是他们的乐趣的阻碍者。。

。。没有口味。。。好的。。。。(难翻译)

当我们用自己的偏见去“改革” 别人的品位时，我们可能不经意间否定了他的某些完全合

法的乐趣。这就是为什么我并不谴责很多程序员们的所为，即使我自己绝不喜欢那样做。

重要的是，他们正在创造他们感到美丽的东西。

在我刚刚引用的段落里，Bentham的确给予我们某些优于其它的美学原则的建议，即结果的

“效用”。我们有自由来设定自己的美的标准，但当我们认为美的东西别人也认为是有用

的时候，才会特别棒。我必须承认我真的喜欢编写计算机程序；而且我特别喜欢写一些在

某种意义上最有益的程序。

当然，在很多种意义上，一段程序可以是“好” 的。首先，有个能正确运行的程序是特别

好的。第二，当需要修改时，有个不难改编的程序往往是很不错的。对懂得适当语言的人

来说，如果这个程序易于阅读也易于理解的话，这两个目标就算实现了。

程序产品好的另一重要方面是，它要和用户友好地交互，特别是在输入数据中恢复人为错

误的时候。编写有意义的错误信息，或者设计不易出错的灵活的输入格式，是一种真正的

艺术。程序质量的另外一个重要方面是使用计算机资源的效率。我很遗憾地说，现在很多

人在谴责程序效率，告诉我们说这是个很坏的个人口味。这件事的原始是我们现在正经历

着对过去的reaction，那时候，效率是作为“好”的唯一reputable的标准。过去的程序员

往往过度关注效率，因而制造了不必要的复杂代码。没有必要的复杂导致净效率的降低，

因为程序难以调试和维护。

真正的问题是程序员在错误的地点，错误的时间，花费了太多的时间担心效率问题。早熟

的优化是编程中所有罪恶的根源(或者至少是大多数) 。

我们不该小事聪明大事糊涂，我们也不该总是以运行时间和空间节省了或浪费了多少百分

数来考虑效率问题。当我们买车的时候，我们很多人几乎没有意识到价格上50美元或100美

元的差别。然而，我们可能专程到某个特定的商店，为了仅用25美分买一件值50美分的东

西。我的要点是，讲效率要分时间和地点；效率扮演的恰当角色，在我的关于结构化编程

的论文中已经做了论述，发表在最近一期<<计算调查>>(Computing Surveys)中[21]。

======================
少一点设备：多一些享受
======================
我发现关于美学上的满足，一件相当奇特的事是，若我们用很局限的工具完成了某件事的

，我们的快乐会大大加强。例如，我自己最欣喜自豪的程序是一个编译器，那是我为一台

内存只有4096个字长，每字16个比特的原始微型机编写的。在如此苛刻的限制下完成某件

事情能让人感觉象一个真正的艺术鉴赏家。

在许多其它情形下也会产生类似的现象。例如，人们似乎常常会爱上他们的大众车(Volks

wagen) ，但很少对他们的林肯车(Lincoln Continental) 那样倾心(后者似乎跑起来更好

些)。当我学习编程的时候，流行的消遣是让仅占一页打孔卡的程序做尽可能多的事情。我

想是同样的现象让APL迷们津津乐道他们的”只用一行程序的人”(one-liners) 。在我们

当今教编程时，一个令人好奇的事实是，我们很难抓住学生学计算机科学的心，除非他学

过一门课能使他们“亲手” 实践小型机。使用我们的大型计算机，连同它们五花八门的操

作系统和语言，看来并不能真正激发对编程的热爱，至少一开始不能。

如何应用这个原则来增加程序员对自己工作的喜爱，并不是显而易见的。如果经理突然宣

布新机器将只有旧机器内存的一半，程序员们肯定要报怨。我不认为有什么人，即使是最

敬业的“编程艺术家”，能欢迎这样的情景，因为没人愿意无谓地缺少了设备。另一个例

子能有助于澄清这个情况：电影业人19世纪20年代强烈抵触有声电影的引入，因为他们自

豪于自己能不用声音而传递语言。类似地，一个真正的编程艺术家会很气愤于引进更强大

的设备；当今的大规模存储设备将把我们旧式的磁带排序法的美感破坏殆尽。但现在的电

影业人并不想回到无声电影时代，不是因为他们懒，而是因为他们知道很有可能用改进的

技术制作出更美的影片来。他们艺术的形式已经改变了，但艺术创造力仍大有空间。

他们如何增长自己的技能？历年来最优秀的摄影人似乎是在相对原始的环境中学会了他们

的艺术，通常在电影业不发达的其它国家。近年来，我们一直学习的编程中最重要的东西

发端于那些没条件使用大型计算机的人。该故事的启示是，在我看来，是我们应该利用自

己教育的有限资源。我们都会从偶而做些“玩具” 程序中受益，因为当有人为限制的时候

，我们不得不挑战自我能力的极限。我们不应该时刻处于豪华之中，因为那样使我们趋于

懒惰。全力以赴地解决小问题，这种艺术将会磨砺我们解决问题的能力。并且这种经历帮

助我们从用较少局限的设备而完成的成就中，获得更大的快乐。

沿着相似的脉络，我们不应该因为“为艺术而艺术” 而自惭形秽；我们也不应该羞愧于仅

仅为了自娱自乐而编写程序。我曾经写了一个只有一条语句的ALGOL程序，它调用了一个内

积过程。由于调用是如此反常规，以至于过程计算了第m个质数，而不是内积[19] 。多年

前斯坦福的学生们兴奋地发现了一个最短的FORTRAN程序，可以打印出程序自身。就是说程

序的输出和程序的源代码相同。我们为很多语言考虑了这个问题。我不认为他们干这个是

浪费时间；Jeremy Bentham也不这样认为(我前面的引用中提及过他) ，他否定了这种消遣

的“功效”[3,Bk.3,Ch.1]。“相反”，他写道，“什么都不为。功效是更加无可置疑的。

如果这不是快乐的源泉，那么我们究竟能够把它归结为功效的何种特性呢？(There is no

thing, the utility of which is more incontestable. To what shall the character

 of utility be ascribed, if not to that which is a source of pleasure?)”


  
--

   
<<社会契约论>>是一本好书,应当多读几遍
风味的肘子味道不错,我还想再吃它      

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.230.220]