黑客与画家
2003年5月
(本文源自于在哈佛大学的一次客座讲座，其中融入了之前东北大学的一次演讲内容。)
当我完成计算机科学的研究生学业后，我进入了艺术学校学习绘画。许多人似乎对一位对计算机感兴趣的人同时也对绘画感兴趣感到惊讶。他们似乎认为黑客技术与绘画是截然不同的工作——黑客工作是冷漠、精确、有条不紊的，而绘画则是某种原始冲动的狂热表达。
这两种形象都是错误的。黑客技术与绘画其实有许多共同之处。事实上，在我认识的所有不同类型的人中，黑客与画家是最相似的。
黑客与画家的共同点在于他们都是创造者。与作曲家、建筑师和作家一样，黑客和画家努力的目标是创造出美好的事物。他们并不是在进行纯粹的研究，尽管如果在追求创造美好事物的过程中发现了新技术，那自然是更好的。
我一直不太喜欢“计算机科学”这个术语。我之所以不喜欢它，主要是因为根本不存在所谓的计算机科学。计算机科学是一个由历史上偶然因素拼凑起来的、联系松散的各种领域的大杂烩，就像南斯拉夫一样。在一个极端，有真正是数学家的人，但他们称自己的工作为计算机科学，以便获得DARPA的资助。在中间，有人从事类似计算机自然历史的研究——例如，研究网络中数据路由算法的行为。而在另一个极端，则是那些黑客，他们试图编写有趣的软件，对他们来说，计算机仅仅是一种表达媒介，如同混凝土之于建筑师，颜料之于画家。这就像数学家、物理学家和建筑师必须被放在同一个系里一样。
有时黑客所做的事情被称为“软件工程”，但这个术语同样具有误导性。优秀的软件设计师并不比建筑师更像工程师。建筑与工程之间的界限并不清晰，但它确实存在。它位于“做什么”和“怎么做”之间：建筑师决定做什么，工程师负责解决如何做。
“做什么”与“怎么做”不应被过于严格地区分。如果你在不懂如何做的情况下试图决定做什么，那是在自找麻烦。但黑客当然不仅仅是决定如何实现某个规格说明。在最理想的情况下，他们是在创造规格说明——尽管事实证明，最好的创造方式就是去实现它。
也许有一天，“计算机科学”会像南斯拉夫一样，被分解成其组成部分。这可能是一件好事。特别是如果这意味着我真正的家园——黑客领域——能够独立出来的话。
将所有不同类型的工作捆绑在同一个系里，可能在行政管理上很方便，但在智力上却令人困惑。这是我不喜欢“计算机科学”这个名称的另一个原因。可以说，中间的那些人从事的有点像实验科学。但两端的那些人，黑客和数学家，实际上并不是在做科学。
数学家们似乎并不为此困扰。他们愉快地开始证明定理，就像数学系的那些数学家一样，可能很快就注意不到他们工作的大楼外面写着“计算机科学”了。但对黑客来说，这个标签是个问题。如果他们做的事情被称作科学，会让他们觉得自己应该表现得科学一些。因此，大学和研究实验室里的黑客们，不去做他们真正想做的事——设计漂亮的软件——反而觉得他们应该写研究论文。
在最好的情况下，论文只是一种形式。黑客们编写出酷炫的软件，然后为其写一篇论文，论文就成了软件所代表的成就的替身。但往往这种错位会引发问题。人们很容易从构建美好的东西，转向构建那些更适合作为研究论文主题的丑陋东西。
不幸的是，美丽的事物并不总是最适合作为论文的主题。 第一，研究必须是原创的——而且正如任何写过博士论文的人所知，确保你探索的是未经开垦处女地的方法，就是圈出一块没人想要的土地。第二，研究必须是实质性的——而笨拙的系统能产生更厚实的论文，因为你可以写为了完成事情而必须克服的种种障碍。没有什么比从错误的假设开始能产生更丰硕的问题了。人工智能的大部分就是这条规则的例证；如果你假设知识可以表示为一系列谓词逻辑表达式，其参数代表抽象概念，那么你会有很多论文可以写，探讨如何使其工作。正如里基·里卡多常说，“露西，你有很多需要解释的。”
创造美好事物的方法，往往是微妙地调整已有的东西，或者以略微新颖的方式组合现有想法。这类工作在研究论文中很难传达。
那么，为什么大学和研究实验室仍以出版物来评判黑客呢？ 原因与“学术能力”被用简单化的标准化测试来衡量，或者程序员的生产力被用代码行数来衡量是一样的。这些测试易于应用，没有什么比一个有点效果且易于实施的测试更具诱惑力了。
衡量黑客真正试图做的事情——设计漂亮的软件——会困难得多。你需要有良好的设计感才能评判好的设计。而且，人们识别优秀设计的能力与他们自信能够做到这一点之间，没有任何相关性（甚至可能是负相关）。
唯一的外部检验是时间。随着时间的推移，美好的事物往往会蓬勃发展，丑陋的事物则往往被丢弃。不幸的是，所需的时间可能比人的一生还要长。塞缪尔·约翰逊说过，一个作家的声誉需要一百年才能稳定下来。你得等到作家有影响力的朋友去世，然后再等到他们所有的追随者都去世。
我认为黑客们只能接受他们的声誉中有一个很大的随机成分。这一点上，他们与其他创造者并无不同。事实上，相比之下他们还算是幸运的。时尚的影响在黑客领域远没有在绘画领域那么大。
还有比人们误解你的工作更糟糕的事情。一个更大的危险是你自己误解自己的工作。相关的领域是你寻找想法的地方。如果你身处计算机科学系，自然会有一种诱惑，比如相信黑客是理论计算机科学理论的某种应用版本。我在研究生院期间，心里一直有一种不安的感觉，觉得我应该知道更多理论，而考试结束后三周内就把那些东西全忘了，是非常失职的。
现在我意识到我错了。黑客需要理解计算理论的程度，大约相当于画家需要理解颜料化学的程度。你需要知道如何计算时间和空间复杂度，了解图灵完备性。你可能还需要记住至少状态机的概念，以防需要编写解析器或正则表达式库。事实上，画家对颜料化学需要记住的东西比这多得多。
我发现，最好的想法来源并不是那些名字里带“计算机”的领域，而是其他由创造者组成的领域。绘画一直是比计算理论更丰富的想法源泉。
例如，大学里教我说，应该在接触计算机之前，就在纸上完整地构思好一个程序。我发现自己并不是这样编程的。我发现我喜欢坐在电脑前编程，而不是对着纸。更糟的是，与其耐心地写出完整程序并确认其正确，我倾向于直接喷出惨不忍睹的代码，然后逐渐把它敲打成形。我学到的观念是，调试是一种最后的步骤，用来捕捉打字错误和疏忽。但按照我的工作方式，编程似乎就是由调试构成的。
很长一段时间里，我为此感到难过，就像我曾经为没有按照小学教的方式握铅笔而难过一样。如果我那时能看一眼其他创造者——画家或建筑师——我早就会意识到我所做的事情有一个名字：草图。据我所知，大学里教我的编程方式完全是错误的。你应该一边写程序一边构思程序，就像作家、画家和建筑师所做的那样。
意识到这一点对软件设计有着实际的影响。这意味着编程语言首先应该是可塑的。编程语言是用来思考程序的，而不是用来表达你已经想好的程序的。它应该是铅笔，而不是钢笔。如果人们确实按照大学教我的那种方式编写程序，静态类型检查会是一个好主意。但我知道的黑客中没有人是那样编写程序的。我们需要一种允许我们涂涂改改、抹抹画画的的语言，而不是那种你必须正襟危坐，腿上端着茶杯，和一位严肃的老阿姨般的编译器礼貌交谈的语言。
既然谈到静态类型，与创造者们站在一起将使我们免于另一个困扰科学领域的问题：数学崇拜。科学界的每个人都暗自认为数学家比他们更聪明。我想数学家自己也这么认为。无论如何，结果是科学家倾向于让他们的工作看起来尽可能数学化。在像物理学这样的领域，这可能没什么大碍，但你离自然科学越远，这就越成问题。
一页公式看起来就是那么令人印象深刻。（提示：想要更印象深刻，使用希腊变量。）因此，人们会极力倾向于研究那些可以形式化处理的问题，而不是那些，比如说，重要的问题。
如果黑客认同其他创造者，比如作家和画家，他们就不会受到这种诱惑。作家和画家没有数学崇拜。他们觉得自己在做完全不相干的事情。我认为黑客也是如此。
如果大学和研究实验室阻止黑客做他们想做的这类工作，也许他们的归宿是公司。不幸的是，大多数公司也不会让黑客做他们想做的事。大学和研究实验室强迫黑客成为科学家，而公司则强迫他们成为工程师。
我自己也是最近才意识到这一点。当雅虎收购Viaweb时，他们问我想做什么。我一直不太喜欢商业方面的事务，就说我只想进行黑客工作。当我到了雅虎，我发现他们所谓的黑客工作意味着实现软件，而不是设计软件。程序员被视为将产品经理的愿景（如果这算愿景的话）转化为代码的技术人员。
这似乎是大型公司的默认方案。他们这样做是因为它降低了结果的方差。只有一小部分黑客真正能够设计软件，而公司管理者很难甄别出这些人。因此，大多数公司不是把软件的未来托付给一位杰出的黑客，而是设置成由委员会设计，黑客们仅仅负责实现这个设计。
如果你想在某一天赚钱，请记住这一点，因为这是创业公司能够胜出的原因之一。大公司想要降低设计结果的偏差，因为他们想避免灾难。但当你抑制波动时，你失去的不仅是低谷，还有高峰。这对大公司来说不是问题，因为他们不是靠制造伟大的产品来取胜的。大公司通过比其它大公司不那么糟糕来赢得市场。
所以，如果你能设法与一家大到其软件由产品经理设计的公司展开设计之战，他们将永远无法跟上你的步伐。不过，这样的机会并不容易找到。与大公司进行设计之战就像与城堡内的对手进行肉搏战一样困难。例如，编写一个比Microsoft Word更好的文字处理器是相当容易的，但微软在其操作系统垄断的城堡内，可能甚至不会注意到你的存在。
设计之战的最佳战场是新兴市场，那里还没有人建立起防御工事。在那里，你可以通过大胆的设计方法，以及让同一批人既设计又实现产品来赢得巨大成功。微软自己在起步时就是这么做的，苹果和惠普也是如此。我怀疑几乎每一家成功的创业公司都是这样做的。
因此，构建优秀软件的一个途径就是创办自己的创业公司。但这有两个问题。一是，在创业公司里，除了写软件，你还要做很多其它事情。在Viaweb，如果我能有四分之一的时间用于编程，我就觉得自己很幸运了。而另外四分之三的时间要做的事情，从枯燥乏味到令人胆战心惊，应有尽有。对此我有一个衡量标准，因为我曾不得不离开董事会会议去补牙。我记得自己坐在牙医的椅子上，等着钻头，感觉就像在度假一样。
创业公司的另一个问题是，能赚钱的软件和写起来有趣的软件之间没太多交集。编写编程语言很有趣，微软的第一个产品其实就是编程语言，但现在没人愿意为编程语言付费了。如果你想赚钱，往往被迫去解决那些没人愿意免费解决的棘手问题。
所有创造者都面临这个问题。价格由供求决定，而对有趣事物的需求远不如对解决个体客户日常问题之物的需求大。在百老汇外演戏的收入不如在贸易展会上穿着大猩猩服装站在别人展位里赚钱。写小说的收入不如为垃圾处理器写广告文案。编写编程语言的收入不如想办法把某家公司的旧数据库连接到其网络服务器上。
我认为，对于软件领域这一问题的答案是几乎所有创造者都熟知的概念：白天的工作。这个说法源于音乐家，他们在晚上演出。更广泛地说，它意味着你有一份工作是为了赚钱，另一份则是出于热爱。
几乎所有的创造者在职业生涯早期都有白天的工作。画家和作家尤其如此，这是众所周知的。如果幸运的话，你可以找到一份与你真正工作密切相关的白天工作。音乐家似乎常常在唱片店工作。而从事某种编程语言或操作系统开发的程序员，或许也能找到一份使用该技术的工作。[1]
当我说答案是程序员要有白天的工作，并在业余时间开发美观的软件时，我并不是在提出一个全新的想法。这就是开源黑客的本质所在。我的意思是，开源可能是正确的模式，因为它已经得到了所有其它创造者的独立验证。
让我感到惊讶的是，竟然有雇主不愿意让程序员参与开源项目。在Viaweb，我们不愿意雇佣那些不参与开源项目的程序员。当我们面试程序员时，最关心的就是他们在业余时间编写什么样的软件。除非你热爱某件事，否则你不可能把它做到极致，而如果你热爱编程，你就不可避免地会有自己的项目。[2]
因为程序员是创造者而非科学家，所以寻找比喻的正确地方不在科学领域，而在其它类型的创造者之中。绘画能教给我们哪些关于编程的道理呢？
从绘画的例子中，我们能学到（或至少能确认）一件事是如何学习编程。学习绘画主要是通过实践。编程也是如此。大多数程序员并不是通过大学编程课程学会编程的。他们是十三岁时通过编写自己的程序学会的。即使在大学课堂上，你也主要是通过实践来学会编程的。[3]
因为画家会在身后留下作品的轨迹，你可以看到他们通过实践来学习。如果你按时间顺序看一位画家的作品，你会发现每一幅画都建立在先前作品所学到的东西之上。当一幅画中有某个部分效果非常好时，你通常能在更早的某幅画中找到它的小规模版本。
我认为大多数创造者都是这样工作的。作家和建筑师似乎也是如此。也许程序员应该更像画家一样行事，定期从头开始，而不是在某个项目上持续工作多年，试图把所有后来的想法都当作修订内容加入进去。
程序员通过实践来学习编程这一事实，是编程与科学有多不同的另一个标志。科学家不是通过做科学来学习科学，而是通过做实验和问题集来学习。科学家开始时做的工作是完美的，因为他们只是在重现别人已经为他们完成的工作。最终，他们才能做原创工作。而程序员从一开始就在做原创工作；只是质量很差。所以程序员是始于原创，逐渐变好；而科学家是始于完美，逐渐变得有原创性。
创造者学习的另一种方式是通过范例。对画家来说，博物馆就是技巧的参考资料库。几百年来，临摹大师作品一直是画家传统教育的一部分，因为临摹迫使你仔细观察一幅画是如何被完成的。
作家也这样做。本杰明·富兰克林通过概括艾迪生和斯蒂尔文章中的要点，然后尝试重现它们来学习写作。雷蒙德·钱德勒用同样的方法学习侦探小说。
同样，程序员可以通过查看好的程序来学习编程——不仅是看它们的功能，还要看源代码。开源运动较少被宣传的好处之一是它让学习编程变得更容易了。当我学习编程时，我们主要依赖书中的例子。当时唯一可用的大块代码是Unix，但即便如此，它也不是开源的。大多数阅读源代码的人都是通过约翰·莱昂斯那本书的非法影印本来读的，这本书虽然写于1977年，但直到1996年才被允许出版。
我们可以从绘画中汲取的另一个例子是画作通过逐步完善而创作的方式。画作通常以草图开始，然后逐渐填充细节。但这不仅仅是一个填充的过程。有时，最初的计划被证明是错误的。无数画作在X光检查下，显示出被移动过的肢体或被调整过的面部特征。
在这里我们可以向绘画学习。我认为编程也应该这样进行。期望程序规格在一开始就完美无缺是不现实的。如果你从一开始就承认这一点，并以允许规格随时变化的方式编写程序，结果会更好。
（大公司的结构使它们难以做到这一点，所以这里是创业公司又一处占有优势的地方。）
现在大家大概都知道过早优化的危险。我认为我们也应该同样警惕过早设计——过早决定程序应该做什么。
合适的工具可以帮助我们避免这种危险。一种好的编程语言应该像油画颜料一样，使改变主意变得容易。动态类型在这方面是个优势，因为你不需要一开始就确定具体的数据表示。但我认为灵活性的关键是让语言非常抽象。最容易修改的程序就是非常简短的程序。
这听起来像是一个悖论，但一幅伟大的画作必须超越它本来的要求。例如，当列奥纳多在国家美术馆绘制《吉内夫拉·德·本奇》肖像时，他在她头后放置了一丛杜松灌木。他仔细地画了每一片叶子。许多画家可能会想，这只是用来衬托她头部的背景物。没人会那么仔细看。
列奥纳多不这么想。他在画作某部分上花了多少功夫，完全取决于他认为会有人多么仔细地去看它，而与此无关。他就像迈克尔·乔丹。永不停歇。
永不停歇之所以能取胜，是因为在整体上，看不见的细节会变得可见。当人们走过《吉内夫拉·德·本奇》肖像时，他们的注意力常常立即被它吸引，甚至在他们看到标签上写着“列奥纳多·达·芬奇”之前就已经被吸引了。所有这些看不见的细节组合在一起，产生了惊艳的效果，就像一千个难以听见的声音齐声歌唱。
伟大的软件同样需要对美的狂热追求。如果你仔细审视优秀的软件，你会发现那些本不该有人看到的部分也很美。我不敢说我写了伟大的软件，但我知道，在代码方面，我的行为方式如果用在日常生活中，足以让我有资格接受药物治疗。看到缩进糟糕的代码，或者使用了丑陋变量名的代码，我会抓狂。
如果一个程序员只是个实现者，把规格变成代码，那么他可以像挖沟一样从头到尾一路干下去。但如果程序员是创造者，我们就必须考虑灵感的作用。
在编程和绘画中，工作都是周期性的。有时你为某个新项目兴奋不已，想每天工作十六个小时。其他时候似乎什么都提不起兴趣。
要做好工作，你必须考虑这些周期，因为它们会受到你对它们反应的影响。当你驾驶手动挡汽车上坡时，有时必须松开离合器以避免熄火。同样，退一步也能防止雄心壮志熄火。在绘画和编程中，都有一些令人望而生畏的宏大任务，也有一些让人安心的例行任务。在那些你可能会停滞不前的时刻，留一些容易的任务做是个好主意。
在编程中，这真的可以意味着把bug留起来。我喜欢调试：这是编程中唯一像人们想象中那样直截了当的环节。你面对一个完全限定好的问题，只需要解决它。你的程序本应该做x，但它却做了y。哪里出错了？你知道自己最终一定会赢。这就像刷墙一样令人放松。
绘画的例子不仅能教会我们如何管理自己的工作，还能教会我们如何合作。过去许多伟大的艺术作品是多人合作的成果，尽管博物馆墙上标签可能只写了一个名字。列奥纳多是韦罗基奥工作室的学徒，画了《基督受洗》中的一位天使。这种事是常态，而非例外。米开朗基罗坚持亲自绘制西斯廷教堂天花板上的所有人物，这被认为是他特别专注投入的表现。
据我所知，画家们在合作绘制一幅画时，从未在同一部分上同时作画。通常，大师负责绘制主要人物，而助手们则绘制其他人物和背景。但绝不会有一个人去覆盖另一个人的作品。
我认为，这也是软件协作的正确模式。但别走得太远。当一段代码被三四个人共同修改，而没有人真正拥有它时，它最终会变得像公共休息室一样，氛围凄凉、荒废，并积累一堆杂乱无章的东西。我认为，正确的合作方式是将项目划分为界限分明的模块，每个模块有明确的负责人，模块之间的接口经过精心设计，并尽可能像编程语言一样清晰明确。
如同绘画，大多数软件都是面向人类受众的。因此，程序员与画家一样，要创造出真正杰出的作品，必须具备同理心。你必须能够从用户的角度看问题。
小时候，我总被教导要站在别人的角度看问题。在实践中，这往往意味着去做别人想做的事，而不是我自己想做的。这自然让同理心背上了坏名声，于是我特意不去培养它。
天哪，我大错特错了。事实证明，站在他人的角度看问题几乎就是成功的秘诀。这不一定意味着自我牺牲。恰恰相反。理解他人如何看待事物，并不表示你会为他们的利益行事；在某些情况下——比如在战争中——你恰恰想反其道而行之。[4]
大多数创造者都是为人类受众制作东西。而要吸引受众，就必须理解他们的需求。例如，几乎所有伟大的绘画作品都是以人物为主题，因为人最关心的就是人本身。
同理心可能是优秀程序员与杰出程序员之间最重要的区别。有些程序员非常聪明，但在同理心方面几乎等于唯我论者。这样的人很难设计出伟大的软件[5]，因为他们无法从用户的角度看问题。
判断一个人同理心强弱的一个方法是，观察他们如何向没有技术背景的人解释技术问题。我们可能都认识一些人，虽然他们很聪明，但在这一点上却糟糕得可笑。如果在晚宴上有人问他们什么是编程语言，他们会说：“哦，高级语言就是编译器用来生成目标代码的输入。”高级语言？编译器？目标代码？一个不知道编程语言是什么的人，显然也不会知道这些东西是什么。
软件的一部分职责是自我解释。因此，要写出好的软件，你必须理解用户的理解是多么有限。他们会毫无准备地直接使用软件，而软件最好能符合他们的预期，因为他们不会去读手册。在这方面，我见过最好的系统是1985年的原始Macintosh。它做到了软件几乎从未做到的事：开箱即用。[6]
源代码本身也应该自我解释。如果我能让人们记住一句关于编程的话，那会是《计算机程序的构造和解释》开头的那一句：
程序应该为了让人阅读而编写，而机器执行只是附带目的。
你不仅需要对用户有同理心，还需要对读者有同理心。这对你有利，因为你也会成为其中之一。许多程序员编写了一个程序，六个月后返回查看时，却发现自己完全不知道它是如何工作的。我认识几个人在经历过这种事后就发誓不再用Perl了。[7]
缺乏同理心与智力相关联，以至于在某些地方甚至成为一种时尚。但我认为两者没有必然联系。你可以在数学和自然科学方面表现出色，而无需学习同理心，这些领域的人往往很聪明，所以这两种品质就被联系在一起。但也有许多不聪明的人也缺乏同理心。听听脱口秀节目中打电话提问的人就知道了。他们提问时总是绕来绕去，以至于主持人常常不得不为他们重新措辞问题。
那么，既然编程像绘画和写作一样，它是否也同样酷呢？毕竟，你只有一次生命。你最好把它花在做一些伟大的事情上。
不幸的是，这个问题很难回答。声望总是有时间差，就像来自遥远恒星的光。绘画现在享有盛誉，是因为五百年前人们完成了伟大的作品。在当时，没有人认为这些画作像我们今天认为的那样重要。当时的人们肯定会觉得奇怪，乌尔比诺公爵费德里科·达·蒙特费尔特罗有一天会主要因皮耶罗·德拉·弗朗西斯卡画中的那个怪鼻子而闻名。
所以，虽然我承认编程现在看起来不如绘画那么酷，但我们应该记住，绘画在其辉煌时期本身也不如现在显得酷。
我们可以相当自信地说，现在是编程的黄金时代。在大多数领域，伟大的工作都是在早期完成的。1430年至1500年间创作的绘画至今仍无与伦比。莎士比亚出现在专业戏剧诞生之时，并将这一媒介推向了极致，以至于后来的每一位剧作家都只能活在他的阴影下。阿尔布雷希特·丢勒在版画领域也做到了同样的事，简·奥斯汀则在小说的领域如此。
我们一次又一次地看到同样的模式。新媒介出现，人们对其兴奋不已，以至于在最初的几代人中就探索了它的大部分可能性。编程似乎正处于这个阶段。
在列奥纳多时代，绘画并不像他的作品所帮助实现的那样酷。编程最终能有多酷，将取决于我们能利用这种新媒介做些什么。
注释
[1] 摄影对绘画造成的最大损害，可能是它扼杀了最好的谋生方式。历史上许多伟大的画家都靠画肖像画维持生计。
[2] 我听说微软不鼓励员工为开源项目做贡献，即使是业余时间也不允许。但现在这么多优秀的程序员都在开源项目上工作，这种政策的主要效果可能只是确保他们没法雇到一流程序员了。
[3] 在大学里学到的编程知识，就像关于书籍、衣服或约会学到的知识一样，让你意识到高中时你的品味有多糟糕。
[4] 这是一个运用同理心的例子。在Viaweb，如果我们无法在两种选择中做决定，我们会问：我们的竞争对手最讨厌什么？有一次，一个竞争对手给他们的软件添加了一个基本上无用的功能，但由于这是他们为数不多而我们没有的功能之一，他们在行业媒体上大加宣传。我们可以试着解释那个功能毫无用处，但我们决定，如果我们也实现它，会让我们的竞争对手更恼火，所以那天下午我们就自己迅速拼凑了一个版本。
[5] 除了文本编辑器和编译器。程序员不需要同理心就能设计这些，因为他们自己就是典型用户。
[6] 嗯，几乎是如此。他们当时对可用RAM的估计有点超标，导致了不少不便的磁盘交换操作，但几个月内通过加购一个硬盘就可以解决。
[7] 让程序易于阅读的方法不是塞满注释。我想把阿贝尔森和苏斯曼的话再进一步。编程语言的设计应该用来表达算法，而告知计算机如何执行只是附带目的。一个好的编程语言应该比英语更适合解释软件。只有在需要提醒读者注意某种笨拙处理时，才需要注释，就像路上只在弯道特别急的地方才画箭头一样。