（上文接让程序员梦寐以求的编程措辞，实现编程的完美开拓（上））
效率众所周知，好的编程措辞天生的代码有较快的运行速率。但是实际上，我以为代码的运行速率不是编程措辞的设计者能够掌握的。高德纳良久以前就指出，运行速率只取决于一些关键的瓶颈。而在编程实践中，许多程序员都已经把稳到自己很随意马虎搞错瓶颈到底在哪里。
以是，编程时提高代码运行速率的关键是利用好的性能剖析器（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 著
