（上文接让程序员梦寐以求的编程语言，实现编程的完美开发（上））

效率

众所周知，好的编程语言生成的代码有较快的运行速度。但是实际上，我觉得代码的运行速度不是编程语言的设计者能够控制的。高德纳很久以前就指出，运行速度只取决于一些关键的瓶颈。而在编程实践中，许多程序员都已经注意到自己很容易搞错瓶颈到底在哪里。

所以，编程时提高代码运行速度的关键是使用好的性能分析器（profiler），而不是使用其他方法，比如精心选择一种静态类型的编程语言。为了提高运行速度，并没有必要每个函数的每个参数类型都声明清楚，你只需要在瓶颈处声明清楚参数类型就可以了。所以，更重要的是你需要能够找出瓶颈到底在什么地方。

人们在使用非常高级的语言（比如Lisp）时，经常抱怨很难知道哪个部分对性能的影响比较大。可能确实如此，如果你使用一种非常抽象的语言，这也许是无法避免的。不管怎样，我认为一个好的性能分析器会解决这个问题，虽然这方面还有很长的路要走，但是未来你可以快速知道程序每个部分的时间开销。

这个问题一部分源于沟通不畅。语言设计者喜欢提高编译器的速度，认为这是对自己技术水平的考验，而最多只把性能分析器当作一个附送给使用者的赠品。但是在现实中，一个好的性能分析器对程序的帮助可能大于编译器的作用。这里又一次反映出语言设计者与用户之间发生了脱节，前者竭尽全力想要解决的问题其实方向不甚正确。

让性能分析器自动运行可能是一个好主意。它自动告诉程序员每个部分的性能，而不是非要等到程序员手动运行后才能知道。比如，当程序员编辑源码的时候，代码编辑器能够实时用红色显示瓶颈的部分。另一个方法应该是设法显示正在运行的程序的情况，这对互联网软件尤其重要，因为服务器上有很多程序同时运行，它们都需要你密切关注。自动运行的性能分析器用图形实时显示程序运行时的内存状况，甚至可以发出声音，表示出现了问题。

出现问题时，声音是很好的提示。我们在Viaweb搞了一块很大的面板，上面有各种各样的仪表盘，用来显示服务器的状况。仪表盘的指针由微型马达驱动，每当马达旋转的时候，就会发出一阵轻微的噪音。在我的工位没法看到仪表盘，但是只要我听到声音，就能立刻知道服务器出现了问题。

性能分析器甚至有可能自动找出不合理的算法。如果将来有人发现某种形式的内存访问是不合理算法的信号，我不会感到很惊讶。如果有一个小人儿可以钻进计算机看看我们的程序是怎么运行的，他可能会变成一个忙碌又悲惨的可怜虫，就像那些为政府跑腿的小人物。我总觉得自己用处理器做了很多无用功，但是一直没有找到能够看出程序是怎样浪费运算能力的好办法。

现在有一些语言先编译成字节码（byte code），然后再由解释器执行。这样做主要是为了让代码容易移植到不同的操作系统，但是这也可以变成一项很有用的功能。让字节码成为语言的正式组成部分，允许程序员在瓶颈处内嵌字节码，这可能是一个不错的主意。然后，针对这部分字节码的优化也就变得可以移植了。

正如许多最终用户已经意识到的，运行速度的概念正在发生变化。随着互联网软件的兴起，越来越多的程序主要不是受限于计算机的运算速度，而是受限于I/O的速度。加快I/O速度将是很值得做的一件事。在这方面，编程语言也能起到作用，有些措施是显而易见的，比如采用简洁、快速、格式化输出的函数，还有些措施则需要深层次的结构变化，比如采用缓存和持久化对象（persistent object）。

用户关心的是反应时间（response time），但是软件的另一种效率正在变得越来越重要，那就是每个处理器能够同时支持的用户数量。未来许多有趣的应用程序都将是运行在服务器端的互联网软件，所以每台服务器能够支持的用户数量就成了软件业者的关键问题。互联网软件的成本支出就取决于这个指标。

许多年以来，大多数面向最终用户的程序都不太关心效率。软件开发者总是假设用户桌面电脑的运算能力会不断增长，所以不用刻意提高软件的效率。帕金森定律③被证明与摩尔定律一样颠扑不破。软件不断膨胀，消耗光所有可以得到的资源。这一切将随着互联网软件的出现发生改变，因为硬件和软件现在捆绑在一起供应。对于那些提供互联网软件的公司来说，将每台服务器支持的用户数量最大化会对降低成本产生巨大影响。

③ 帕金森定律（Parkinson's Law）的一种原始表达形式是“工作总是到最后一刻才会完成”，后来引申到计算机领域就变成了“数据总是会填满所有空间”，更一般性的总结则是“对一种资源的需求总是会消耗光这种资源的所有供应”。——译者注

在一些应用程序中，处理器的运算能力是瓶颈，那么最重要的优化对象就是软件的运行速度。但是，一般情况下内存才是瓶颈，你能够同时支持的用户数量取决于用户数据所消耗的内存。编程语言在这方面也能发挥作用，对线程的良好支持将使得所有用户共享同一个内存堆（heap）。持久化对象和语言内核级别的延迟加载（lazy loading）支持也有助于减少内存需求。

时间

一种编程语言要想变得流行，最后一关就是要经受住时间的考验。没人想用一种会被淘汰的语言编程，这方面已经有很多前车之鉴了。所以，大多数黑客往往会等上几年，看看某一种新语言的势头，然后才真正考虑使用它。

新事物的发明者通常对这个发现很震惊，他们没想到人们居然这样对待发明创造。但是，让别人相信一种新事物是需要时间的。我有一个朋友，他的客户第一次提出某种需求时，他很少理会。因为他知道人们有时候会想要自己并不真正需要的东西。为了避免浪费时间，只有当客户第三次或第四次提出同样的需求时，他才认真对待。这个时候客户可能已经很不高兴了，但是这至少保证他们提出的需求应该就是他们真正需要的东西。

大多数人接触新事物时都学会了使用类似的过滤机制。甚至有时要听到别人提起十遍以上他们才会留意。这样做完全是合理的，因为大多数的热门新商品事后被证明都是浪费时间的噱头，没多久就消失得无影无踪。虚拟现实建模语言VRML刚诞生时曾经轰动一时，但是我决定等到一两年后再去学习它，结果一两年后已经没有学习的必要了，因为市场已经把它遗忘了。

所以，发明新事物的人必须有耐心，要常年累月不断地做市场推广，直到人们开始接受这种发明。我们就耗费了好几年才使得客户明白Viaweb不需要下载安装就能使用。不过，好消息是，简单重复同一个信息就能解决这个问题。你只需要不停地重复同一句话，最终人们将会开始倾听。人们真正注意到你的时候，不是第一眼看到你站在那里，而是发现过了这么久你居然还在那里。

新事物的发展改进一般也需要很长时间。大多数技术在诞生后都逐渐发生了巨大的变化，编程语言更是如此。诞生头几年，一小批早期使用者比其他因素更能促进技术发展。早期使用者都是行家，要求也很高，能够很快找出你的技术中存在的缺点。而且，如果你的用户只有很少几个人，你就能够与他们所有人保持密切接触。只要不断改进你的系统，即使给用户造成了损失，早期使用者也会对你宽容大度的。

新技术被市场接纳的方式有两种，一种是自然成长式，另一种是大爆炸式。自然成长式的一个例子就是在车库里白手起家、自力更生的创业者。几个好朋友埋头工作，在外界毫不知晓的情况下开发出某种新技术。他们把它推向市场，没有任何宣传，最初的用户寥寥无几（但是热心程度无与伦比）。创业者持续改进新技术，与此同时，通过口碑效应，用户数量不断增长。在创业者不经意间，他们已经壮大起来了。

大爆炸式的例子是有风险资本支持、在市场上大张旗鼓宣传的创业公司。他们急急忙忙地开发一个产品，推向市场的时候大肆曝光，立刻就获得了一大批使用者（至少他们希望如此）。

一般来说，车库里的创业者会妒忌大爆炸式的创业公司。后者的主导人物个个光彩照人、自信非凡，深受风险资本商的追捧。他们什么都买得起，在公关公司配合产品推出的宣传活动中，他们自己也附带成为了明星人物。自然成长式的创业者坐在自家车库里，觉得自己又穷又可怜。但是我想他们不必难过。最终来看，自然成长式会比大爆炸式产生更好的技术，能为创始人带来更多的财富。如果你研究一下目前的主流技术，就会发现大部分都是源于自然成长式。

这种模式不仅存在于商业公司，还存在于科研活动中。Multics操作系统和Ada语言是大爆炸式项目，现在都已经销声匿迹了，而它们的继承者Unix和C语言则是自然成长式项目。

再设计

著名散文家E.B.怀特说过，“最好的文字来自不停的修改”。所有优秀作家都知道这一点，它对软件开发也适用。设计一样东西，最重要的一点就是要经常“再设计”，编程尤其如此，再多的修改都不过分。

为了写出优秀软件，你必须同时具备两种互相冲突的信念。一方面，你要像初生牛犊一样，对自己的能力信心万丈；另一方面，你又要像历经沧桑的老人一样，对自己的能力抱着怀疑态度。在你的大脑中，有一个声音说“千难万险只等闲”，还有一个声音却说“早岁哪知世事艰”。

这里的难点在于你要意识到，实际上这两种信念并不矛盾。你的乐观主义和怀疑倾向分别针对两个不同的对象。你必须对解决难题的可能性保持乐观，同时对当前解法的合理性保持怀疑。

做出优秀成果的人，在做的过程中常常觉得自己做得不够好。其他人看到他们的成果觉得棒极了，而创造者本人看到的都是自己作品的缺陷。这种视角的差异并非偶然，因为只有对现状不满，才会造就杰出的成果。

如果你能平衡好希望和担忧，它们就会推动项目前进，就像自行车在保持平衡中前进一样。在创新活动的第一阶段，你不知疲倦地猛攻某个难题，自信一定能够解决它。到了第二阶段，你在清晨的寒风中看到自己已经完成的部分，清楚地意识到存在各种各样的缺陷。此时，只要你对自己的怀疑没有超过你对自己的信心，就能够坦然接受这个半成品，心想不管多难我还是可以把剩下的部分做完。

让这两股相反的力量保持平衡是很难的。初出茅庐的年轻黑客都很乐观，自以为做出了伟大的产品，从不反思和改进。上了年纪的黑客又太不自信，甚至故意回避一些挑战性很强的项目。

任何措施，只要能让“再设计”周而复始地进行下去，就都是可取的。文章可以修改到你满意为止，但是软件的修改通常来说可以无休止地进行下去。文章的读者不可能抱怨修改后新增加的内容让他们前后的思想产生了不协调，但是软件的使用者就会抱怨修改后的版本有不兼容问题。

用户是一把双刃剑。他们推动语言的发展，但也使得你不敢对语言进行大规模改造。所以，一开始的时候要精心选择用户，避免使用者过快增长。发展用户就像一种优化过程，明智的做法就是放慢速度。一般情况下，用户比较少意味着你任何时候都可以加大修改的力度。这时，对语言规格做出改变就像撕绷带，当你感到痛苦的一瞬间，痛苦就已经成为了回忆。如果用户数量庞大，修改语言带来的痛苦就将持续很长时间。

大家都知道，让一个委员会负责设计语言是非常糟糕的主意。委员会只会做出恶劣的设计。但是我觉得，委员会最大的问题在于他们妨碍了“再设计”。在委员会的主持下，修改一种语言是非常麻烦的事，没有人愿意自讨苦吃。而且，即使大多数成员不喜欢某种做法，委员会最后的决定往往还是维持现状。

就算委员会只有两个人，还是会妨碍“再设计”，典型例子就是软件内部的各个接口由不同的人负责。这时除非两个人都同意改变接口，否则接口就无法改变。因此现实中，尽管软件功能越来越强大，内部接口却往往一成不变，成为整个系统中拖后腿的部分。

一种可能的解决方法是，将软件内部的接口设计成垂直接口而不是水平接口。这意味着软件内部的模块是一个个垂直堆积起来的抽象层，层与层之间的接口完全由其中的一层控制。如果较高的一层使用了较低的一层定义的语言，那么接口就由较低的一层控制；如果较低的一层从属于较高的一层，那么接口就由较高的一层控制。

梦寐以求的编程语言

让我们试着描述黑客心目中梦寐以求的语言来为以上内容做个小结。这种语言干净简练，具有最高层次的抽象和互动性，而且很容易装备，可以只用很少的代码就解决常见的问题。不管是什么程序，你真正要写的代码几乎都与你自己的特定设置有关，其他具有普遍性的问题都有现成的函数库可以调用。

这种语言的句法短到令人生疑。你输入的命令中，没有任何一个字母是多余的，甚至用到Shift键的机会也很少。

这种语言的抽象程度很高，使得你可以快速写出一个程序的原型。然后，等到你开始优化的时候，它还提供一个真正出色的性能分析器，告诉你应该重点关注什么地方。你能让多重循环快得难以置信，并且在需要的地方还能直接嵌入字节码。

这种语言有大量优秀的范例可供学习，而且非常符合直觉，你只需花几分钟阅读范例就能领会应该如何使用此种语言。你偶尔才需要查阅操作手册，它本身很薄，里面关于限定条件和例外情况的警告寥寥无几。

这种语言的内核很小，但很强大。各个函数库高度独立，而且和内核一样经过精心设计，它们都能很好地协同工作。语言的每个部分就像精密照相机的各种零件一样完美契合，不需要为了兼容性问题放弃或者保留某些功能。所有函数库的源码都很容易得到。这种语言能够很轻松地与操作系统和用其他语言开发的应用程序对话。

这种语言以层的方式构建。较高的抽象层透明地构建在较低的抽象层之上。如果需要的话，你可以直接使用较低的抽象层。

除了一些绝对必要隐藏的东西，这种语言的所有细节对使用者都是透明的。它提供的抽象能力只是为了方便你的开发，而不是为了强迫你按照它的方式行事。事实上，它鼓励你参与它的设计，给你提供与语言创造者平等的权力。你能够对它的任何部分加以改变，甚至包括它的语法。它尽可能让你自己定义的部分与它本身定义的部分处于同等地位。这种梦幻般的编程语言不仅开放源码，更开放自身的设计。

本文节选自《黑客与画家：硅谷创业之父Paul Graham文集》[美]Paul Graham 著