设计与研究

原文：Design and Research
作者：Paul Graham　发表：2003-01
译者：Claude（baoyu-translate）

作者：Paul Graham 2003 年 1 月

（本文由 NEPLS（新英格兰编程语言研讨会）2002 年秋季会议的 keynote 演讲改写。）

来美国的人常常意外地发现：美国人喜欢用“你做什么的？“来开启一段对话。我从来不喜欢这个问题——我很少能给出一个利落的答案。但我想我终于把这个问题解决了。现在，每当有人问我做什么，我会直视他的眼睛，说：”我在设计一种 Lisp 的新方言。“我把这个答案推荐给所有不喜欢被问“做什么“的人。话题立刻就会转到别的事情上。

我并不认为自己在做编程语言的研究。我只是在设计一门，就像有人在设计一栋楼、一把椅子、或一种新字体一样。我并不试图发现什么新东西，我只想做出一门写起来好用的语言。在某些方面，这个假设让生活轻松得多。

设计和研究的区别，似乎是“新“和“好“的区别。**设计不必新，但必须好；研究不必好，但必须新。**这两条路在顶端会汇合：最好的设计借助新想法超越前人；最好的研究解决的不仅是新问题，更是真正值得解决的问题。所以归根到底我们瞄准的是同一个目的地，只是从不同方向逼近。

今天我要讲的，是这个目的地“从背面看是什么样“。当你把编程语言当成设计问题而不是研究课题来对待时，你会做出哪些不同的事？

聚焦用户

最大的差别在于你会更聚焦用户。设计的起点，是问：“这是给谁的？他们需要从中得到什么？“比如，一位好建筑师，不会一上来就拿一份设计强加给用户，而是先研究目标用户，弄清楚他们需要什么。

注意我说的是“他们需要什么“，不是“他们想要什么“。我不想给人一种印象，仿佛做设计就是做一个快餐厨子（美国快餐店点单即做的厨子），客户说什么你就做什么。这件事在艺术领域因领域而异，但我不认为有任何一个领域，最好的作品是由“完全照客户吩咐做“的人做出来的。

“客户永远是对的“这句话在这个意义上是对的：好设计的衡量标准，是它对用户而言有多管用。如果你写了一本让所有人厌倦的小说，或者做了一把坐起来奇糟无比的椅子，那你就是搞砸了——句号。说“这本小说“或“这把椅子“是按最先进的理论原则设计的，不是辩护。

但是，“做对用户管用的东西“也不等于“做用户告诉你的东西”。用户不知道全部选项是什么，且常常对自己真正想要什么判断错误。

我认为这个悖论的解是：你必须为用户而设计，但你必须设计用户所需要的，而不只是他口头说想要的。这很像当医生。你不能只是处理病人的症状。当病人告诉你他的症状时，你必须搞清楚他真正出了什么问题，然后去治那个东西。

这条“聚焦用户“的原则像是一条公理——好设计的大部分实践都能从它推导出来，大部分设计议题也都围绕着它。

用户是谁？

如果好设计必须做用户所需要的，那么——用户是谁？我说“设计必须为用户而做“，不是要暗示好设计就该瞄准某种“最低共同分母“。你可以选任何一群用户。比如你设计一件工具，可以为从初学者到专家中的任何一群人设计；对一群人是好设计，对另一群人也许就是坏设计。关键是你必须选定某一群用户——离开“目标用户“这个参照，我觉得你甚至无法谈“好设计“或“坏设计“。

如果目标用户包含设计者自己，你最有可能做出好设计。当你为不包含自己的一群人做设计时，那群人往往会被你看作“比你不那么资深“，而不是“比你更资深“。

这是个问题——因为俯视用户（哪怕带着善意）似乎不可避免地会败坏设计者。我猜美国的公租房项目里，没几栋是由“打算自己住进去“的建筑师设计的。在编程语言里你能看到同样的事。C、Lisp、Smalltalk 是为它们的设计者自己用而创造的；Cobol、Ada、Java 则是为别人用而创造的。

如果你以为自己在为蠢人设计，那大概率你做出的东西连蠢人也不该用。

为人类而设计

但即便你在为最资深的用户做设计，你仍然在为人做设计。研究里就不一样。在数学里，你选抽象不是因为它们对人类容易理解；你选的是让证明更短的那一种。在科学里我觉得普遍如此——科学思想本来就不是冲着“人体工学“去的。

到了艺术那一边，事情完全不同。设计的全部都是关于人。人体是个奇怪的东西，但你设计椅子时，你正是在为这个东西做设计——绕不开它。所有艺术都得迎合人的兴趣和局限。比如绘画——其他条件相同的话，画里有人的画总比没人的更有意思。文艺复兴的伟大画作几乎全是人，并不只是历史的偶然——如果它们当年没那样画，“绘画“作为一种媒介就不会拥有今天这种声望。

不管你喜不喜欢，编程语言也是给人用的。我猜人脑就跟人体一样，疙疙瘩瘩、各有怪癖。有些想法人脑容易抓住，有些则不。比如说，我们处理细节的能力似乎非常有限——正是这个事实让“编程语言“这件事一开始就成立的：如果我们能直接处理细节，我们干脆用机器语言写程序就行了。

还要记住：语言主要不是成品程序的形式，而是程序得在其中被开发出来的东西。任何搞艺术的人都会告诉你，这两种情境你可能想用不同的“媒介“。比如大理石——对已成形的想法是一种漂亮、耐用的媒介，但对正在产生的想法则是一种死板得让人绝望的媒介。

一段程序，就像一份证明，是一棵树修剪过的版本——这棵树在过去到处长出了跑偏的枝桠。所以，对一门语言的考验不只是“成品程序在它里面看上去多干净“，而是“通向成品的那条路有多干净“。一种能让成品程序优雅的设计选择，未必让设计过程也优雅。比如，我写过几个“定义宏的宏“——里面塞满嵌套反引号——现在看起来像是几粒小宝石；但当年写出来花了我好几个小时最丑陋的“试错“，老实说我到现在都不完全确定它们是对的。

我们经常表现得像是“对一门语言的考验就是成品程序在它里面好不好看“。当你看到同一段程序用两门语言写出来、一种短得多时，这种考验显得特别有说服力。但当你从艺术那一头来逼近这个问题时，你就不那么容易依赖这种测试了。你不希望最后得到的是一门像大理石那样的编程语言。

举个例子，开发软件时拥有一个“交互式顶层“——Lisp 里所谓的 read-eval-print loop（REPL，读-求值-打印循环）——是巨大的胜利。一旦你有了这个，它对语言设计就有真实的影响。比如，对于一门“使用变量前必须先声明“的语言而言，REPL 工作起来就很别扭。当你只是在顶层敲表达式时，你想做的是把 x 设为某个值，然后开始对 x 做事——你不想先声明 x 的类型。这两个前提你都可以质疑，但如果“一门语言要好用就必须有 REPL“，而“强制类型声明又和 REPL 不兼容“，那么任何强制类型声明的语言都不可能好用。

贴近用户

实践中，要做出好设计，你必须贴近——并保持贴近——你的用户。你必须把自己的想法不断地在真实用户身上做校准——尤其是早期。简·奥斯汀的小说之所以好，原因之一是她把它们大声读给家人听。这就是为什么她从不沉湎于自我陶醉的“艺术化“风景描写、也不卖弄空洞的哲学。（哲学是有的，但它织进了故事，而不是像贴标签一样贴在故事上。）你随便翻开一本“文学性“小说，想象自己把它当成你写的东西大声念给朋友听——你会非常切肤地感到，这种文字对读者是何等的强加。

在软件世界里，这个想法叫做“Worse is Better“（“更糟即更好”——Richard Gabriel 1989 年提出的软件设计哲学）。其实“Worse is Better“这个概念里混合了好几个想法——这正是为什么人们到今天还在争论“更糟到底是不是真的更好“。但混合里的一个核心想法是：“如果你在做新东西，你应当尽快把一个原型摆到用户面前。”

它的反面我们可以叫“圣母玛利亚式“长传战术（美式橄榄球比赛末刻孤注一掷的达阵长传）——不是先快出原型再逐步打磨，而是试图在一记长长的达阵传球里一次性造出完整、成品的产品。据我所知，这是一份灾难配方。互联网泡沫期间数不清的创业公司就是这样把自己干掉的。我没听说过哪一例成功的。

软件世界以外的人也许没意识到，“Worse is Better“在艺术领域里到处都是。比如绘画——这个想法早在文艺复兴时期就被发现了。今天几乎每一位绘画老师都会告诉你：要画准一张图，正确的方法不是慢慢沿着物体的轮廓一笔一笔走——因为误差会累积，最后你会发现线接不上。正确的方法是先快速画几条放在大致正确位置的线，然后逐步打磨这张初稿。

在大多数领域，原型按传统是用不同材料做的。要在金属上刻的字体，最初用毛笔在纸上画。要用青铜浇铸的雕像，先用蜡塑模型。要绣在挂毯上的图案，先用墨在纸上画。要用石头建的房子，先用木头做小比例的试模。

油画颜料在十五世纪开始流行时令人激动的地方在于：你居然可以直接从原型做出成品。你想画一份初稿就画，但不必被它绑住——你可以一边完成画作，一边把所有细节定下来，甚至做出重大改动。

软件里你也可以这么做。原型不必只是模型——你可以把它打磨成成品。我觉得你能这么做就总是该这么做。这让你能利用沿途产生的新洞见。但比这更重要的，也许是它对士气的好处。

士气至关重要

设计里士气是关键。我很惊讶人们没更多地谈这件事。我最早的一位绘画老师告诉我：画东西时如果你觉得无聊，画出来的就会显得无聊。比如说，你要画一栋楼，你决定一块砖一块砖地画。可以。但如果你画到一半就开始无聊、把砖头机械地画出来、不再观察每一块砖，那这幅画看起来会比“只是大致暗示一下砖“还要差。

通过逐步打磨原型来构建东西，对士气有好处——因为它让你保持投入。在软件里，我的规则是：永远保持有一份能跑的代码。如果你正在写的东西一小时后能测试到，那“立即兑现“的奖励就在前方激励着你。艺术里同理，尤其是在油画里——大多数画家从一张模糊的草图开始，逐步打磨。如果你这么工作，原则上你永远不必带着一件“看起来未完成“的东西收工。画家中甚至有句话：“一幅画从不会被完成，你只是停止动它了。“对任何写过软件的人，这个想法都不会陌生。

士气也是为什么“为不资深的用户做设计“会很难的另一个理由——你很难对自己不喜欢的东西保持兴趣。要做出好东西，你心里得想的是“哇这真棒“，而不是“什么破烂货——那些蠢货会爱死它的“。

设计意味着为人类做东西。但不只是用户是人——设计者也是人。

好设计需要一个独裁者

注意一直以来我都在说“那个设计者“。设计要好，通常必须置于一个人的掌控之下。然而研究项目却似乎可以由几个人协作。在我看来，这是研究和设计之间最有意思的区别之一。

艺术里也有一些著名的合作案例，但其中多数看上去更像“分子结合“，而不是”核聚变“。歌剧里常见一个人写 libretto（歌剧脚本）、另一个人写音乐。文艺复兴时期，意大利绘画的背景风景常常由从北欧雇来的行脚工匠来画。但这些不是真正的合作——它们更像 Robert Frost（美国诗人罗伯特·弗罗斯特）那句”篱笆好，邻居才好“的例子。你可以把好设计的若干件成品拼在一起，但在每一件单独的作品里，必须有一个人说了算。

我不是说好设计要求“一个人想到所有事“——没有什么比“一个你信赖判断力的人给的建议“更值钱了。但说完之后，“该怎么做“的决定必须落到一个人身上。

为什么研究可以协作而设计不行？这是一个有意思的问题。我不知道答案。或许，如果设计与研究最终汇合，那么最好的研究也是好的设计——那就同样不能协作做。许多最有名的科学家似乎都是独自工作的。但我了解的不足以判断这是不是一种规律。也许只是因为：许多有名科学家活跃的时代，“协作“还远不那么常见。

不论科学的情况如何，在艺术里，真正的协作似乎少到几乎不存在。“委员会式设计“是“坏设计“的同义词。为什么？有没有办法绕过这条限制？

我倾向于认为没有——好设计需要一个独裁者。一个理由是好设计必须浑然一体。设计不只是为人，而是为单个的人。如果一份设计代表的是一个能装进一个人脑袋的想法，那这个想法也才能装进用户的脑袋。