黑客与画家 | Hacker and Painter


Hacker and Painter
黑客与画家

May 2003

(This essay is derived from a guest lecture at Harvard, which incorporated an earlier talk at Northeastern.)

When I finished grad school in computer science I went to art school to study painting. A lot of people seemed surprised that someone interested in computers would also be interested in painting. They seemed to think that hacking and painting were very different kinds of work-- that hacking was cold, precise, and methodical, and that painting was the frenzied expression of some primal urge.
我读完计算机本科以后,去艺术学校学习绘画。许多人感到奇怪,喜欢计算机的人也会喜欢美术吗?他们大概认为编程序和画画是两种完全不同的工作,编程需要冷静,精密,和正确的方法,而画画是表达某种狂热的情感。

Both of these images are wrong. Hacking and painting have a lot in common. In fact, of all the different types of people I've known, hackers and painters are among the most alike.
这种印象是不对的,编程和画画有很多共同之处,实际上,在我认识的不同类型的人中间,画家和黑客是最相似的。

What hackers and painters have in common is that they're both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They're not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.
画家和黑客的相似之处在于:他们都是创造者,就好像作曲家,建筑师,以及作家一样。黑客和画家类似,他们的目的是创造某种美好的事物。尽管在创造的过程中,也许会发现新技术,但他们的根本目的并不是研究技术。

I've never liked the term "computer science." The main reason I don't like it is that there's no such thing. Computer science is a grab bag of tenuously related areas thrown together by an accident of history, like Yugoslavia. At one end you have people who are really mathematicians, but call what they're doing computer science so they can get DARPA grants. In the middle you have people working on something like the natural history of computers-- studying the behavior of algorithms for routing data through networks, for example. And then at the other extreme you have the hackers, who are trying to write interesting software, and for whom computers are just a medium of expression, as concrete is for architects or paint for painters. It's as if mathematicians, physicists, and architects all had to be in the same department.
我从来都不喜欢”计算机科学”这个词,因为这种东西根本就不存在。这门学科的内容,不过是由于历史原因偶然凑合到一起的大杂烩,就好像南斯拉夫国的形成一样。一头是数学家们,他们摆弄计算机是为了得到国防部的资金赞助,中间部分,一伙人在研究仿佛是计算机自然史之类的东西--比如网络上数据流算法的行为特征等等。在另一个极端上,是黑客们,他们编写有趣的软件。对他们来说,计算机是表达的工具,如同水泥之于建筑师,颜料之于画家。这三种人凑在一块的群体,就好像是数学家,物理学家和建筑师被分到一个专业里。

Sometimes what the hackers do is called "software engineering," but this term is just as misleading. Good software designers are no more engineers than architects are. The border between architecture and engineering is not sharply defined, but it's there. It falls between what and how: architects decide what to do, and engineers figure out how to do it.
有时候黑客们干的事被称为”软件工程”,这个词也是一种误会。比起建筑师来,软件设计师离工程师的距离更远。建筑师和工程师的分界并不十分精确,但却是实实在在存在的。其分界在于做什么和如何做:建筑师决定做什么,工程师考虑如何做出来。

What and how should not be kept too separate. You're asking for trouble if you try to decide what to do without understanding how to do it. But hacking can certainly be more than just deciding how to implement some spec. At its best, it's creating the spec-- though it turns out the best way to do that is to implement it.
这两件事情也不能分得太开,如果你不懂得如何做,那么你设计的时候就会陷入难局。但是编程当然不是仅仅决定如何实现某种特性那么简单,在最好的情况下,编程实际上就是设计软件的特性--往往最好的设计方式就是实现它。

Perhaps one day "computer science" will, like Yugoslavia, get broken up into its component parts. That might be a good thing. Especially if it meant independence for my native land, hacking.
说不定哪一天,”计算机科学”会分裂成几个专业,就好像南斯拉夫最终分裂成几个国家那样。这也许是件好事。尤其是这意味着我所擅长的编程,会变成独立的专业。

Bundling all these different types of work together in one department may be convenient administratively, but it's confusing intellectually. That's the other reason I don't like the name "computer science." Arguably the people in the middle are doing something like an experimental science. But the people at either end, the hackers and the mathematicians, are not actually doing science.
这些不同类型的工作绑到一个专业里,当然有利于行政管理,但是却会引起智力上的困惑。这也是我不喜欢这个名词的另一个原因。处于中间部分的那伙人所干的,和经验科学差不多,但是另外两头的人,数学家和黑客,可不太象是在干真正的科学。

The mathematicians don't seem bothered by this. They happily set to work proving theorems like the other mathematicians over in the math department, and probably soon stop noticing that the building they work in says ``computer science'' on the outside. But for the hackers this label is a problem. If what they're doing is called science, it makes them feel they ought to be acting scientific. So instead of doing what they really want to do, which is to design beautiful software, hackers in universities and research labs feel they ought to be writing research papers.
数学家好像并不为这个问题发愁,他们就象数学系的同行一样,很高兴地做着理论研究,不久就忘了办公大楼的牌子写的是”计算机科学系”。但是对黑客们来说,这个牌子就很成问题。既然他们干的事被称作科学,他们就会感到好歹要象那么回事,于是大学和研究所的黑客们觉得应该写论文,而不是写优美的程序。但是不幸得很, 后者才是他们真正应该干的。

In the best case, the papers are just a formality. Hackers write cool software, and then write a paper about it, and the paper becomes a proxy for the achievement represented by the software. But often this mismatch causes problems. It's easy to drift away from building beautiful things toward building ugly things that make more suitable subjects for research papers.
论文充其量不过是一个手续。黑客写出很棒的程序,然后再做一篇论文,论文表示软件上的成绩。但是两者之间的不协调引起了问题:好的软件比起糟糕的软件来,更加不适合做论文的题材。

Unfortunately, beautiful things don't always make the best subjects for papers. Number one, research must be original-- and as anyone who has written a PhD dissertation knows, the way to be sure that you're exploring virgin territory is to to stake out a piece of ground that no one wants. Number two, research must be substantial-- and awkward systems yield meatier papers, because you can write about the obstacles you have to overcome in order to get things done. Nothing yields meaty problems like starting with the wrong assumptions. Most of AI is an example of this rule; if you assume that knowledge can be represented as a list of predicate logic expressions whose arguments represent abstract concepts, you'll have a lot of papers to write about how to make this work. As Ricky Ricardo used to say, "Lucy, you got a lot of explaining to do."
好的软件不适合作论文的题材。首先,论文要有独创性的,写过博士论文的都知道,要想保证你开垦的那片地是处女地,就等于说是你划出一片别人都不想要的地来。第二,论文必须言之有物。糟糕的软件使论文材料充足,你有很多事实可以描述你是如何克服那些困难的。糟糕的假设总是会产生大量问题。大部分AI研究就是好例子。比如,你假定,以抽象概念为参量的逻辑表达式列表可以用来表示知识,那你要论证的内容可就多了。就像Ricky Ricardo说的,Lucy,这下可够你解释了。

The way to create something beautiful is often to make subtle tweaks to something that already exists, or to combine existing ideas in a slightly new way. This kind of work is hard to convey in a research paper.
创造美好事物的过程,常常是对已有事物的细微调整,或者是把已有概念用新方式组合起来。这种事情,恐怕不太好做研究论文吧。

So why do universities and research labs continue to judge hackers by publications? For the same reason that "scholastic aptitude" gets measured by simple-minded standardized tests, or the productivity of programmers gets measured in lines of code. These tests are easy to apply, and there is nothing so tempting as an easy test that kind of works.
那么为什么大学和研究所还要用论文来衡量黑客呢? 同样的, 为什么要用标准化考试来衡量学术才能呢?为什么要用代码行数来衡量程序员的工作量呢?这些考试的好处是容易实施,而且有一点效果, 因此才会引诱我们继续采用这些措施。

Measuring what hackers are actually trying to do, designing beautiful software, would be much more difficult. You need a goodsense of design?to judge good design. And there is no correlation, except possibly a?negative?one, between people's ability to recognize good design and their confidence that they can.
真正的黑客能够写出优雅的代码, 但是识别这种黑客的方法,真的很不容易找到。要有好的嗅觉才可能识别出真正优秀的设计。是否真的有这种嗅觉,和是否自信有这种嗅觉,这两者之间没什么关联,即使有,也是负面的。

The only external test is time. Over time, beautiful things tend to thrive, and ugly things tend to get discarded. Unfortunately, the amounts of time involved can be longer than human lifetimes. Samuel Johnson said it took a hundred years for a writer's reputation to converge. You have to wait for the writer's influential friends to die, and then for all their followers to die.
真正的考验是时间。经过时间的考验,好的东西会发展壮大,坏的东西会丢弃。不幸的是,需要的时间往往太长, 以至超过人的寿命。Samuel Johnson说,需要一百年的时间,才能形成一个作家的真正声誉。你得等到这个作家有影响的朋友都死了,他的追随者也都死了才行。

I think hackers just have to resign themselves to having a large random component in their reputations. In this they are no different from other makers. In fact, they're lucky by comparison. The influence of fashion is not nearly so great in hacking as it is in painting.
我想黑客不得不接受名声上的不确定性,这一点上, 他们和其他创造者没什么不同。实际上比较起来还要幸运一些。在编程领域,一时的流行风气虽然也有影响,但没有绘画领域那么大。

There are worse things than having people misunderstand your work. A worse danger is that you will yourself misunderstand your work. Related fields are where you go looking for ideas. If you find yourself in the computer science department, there is a natural temptation to believe, for example, that hacking is the applied version of what theoretical computer science is the theory of. All the time I was in graduate school I had an uncomfortable feeling in the back of my mind that I ought to know more theory, and that it was very remiss of me to have forgotten all that stuff within three weeks of the final exam.
还有比别人的误解更糟的事情。更糟的危险是你可能自己误解自己。你通常在相关领域寻找灵感。如果你在计算机系,很自然地会以为,编程的本质就是实现计算机理论。我读本科的时候有一种令我很不舒服的感觉,我觉得自己应当多学一点计算机理论,可是期末考试完了不到三个礼拜,我就把那些东西全忘光了。这让我觉得自己不够尽责。

Now I realize I was mistaken. Hackers need to understand the theory of computation about as much as painters need to understand paint chemistry. You need to know how to calculate time and space complexity and about Turing completeness. You might also want to remember at least the concept of a state machine, in case you have to write a parser or a regular expression library. Painters in fact have to remember a good deal more about paint chemistry than that.
现在我认识到我那时的想法都是错误的。黑客对计算机理论的了解程度,只要达到画家对颜料化学所了解的程度就够了。你应当知道怎样计算时间和空间复杂度,知道图灵机模型。也许应当知道状态机,至少知道这个概念,如果要写语法解析或者正则表达式库的时候会用得到。画家对颜料的学问上,要记的东西比这还要多一些呢。

I've found that the best sources of ideas are not the other fields that have the word "computer" in their names, but the other fields inhabited by makers. Painting has been a much richer source of ideas than the theory of computation.
对我来说,灵感的源泉不是来自于那些挂着计算机招牌的地方,而是那些聚集着创造者的地方。我从绘画方面得到的灵感比我从计算机理论上得到的,要多得多。

For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
打个比方。我上学的时候,学生在上机之前,要把整个程序先用纸笔写出来。可是我觉得这不是我写程序的方式。我喜欢坐在计算机前面写程序,根本不用纸笔。我并不先在纸上写出程序并检验其正确性,我喜欢先敲一段代码,当然好多毛病,然后慢慢敲打成型。我受到的教育告诉我,调试应当是检查输入错误的最后一关,而按照我的方式,程序基本上就是调试出来的。

For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.
好长一段时间我都感到很沮丧,念小学的时候,我捉铅笔的方式和老师教的不一样,那时我也感到同此刻一样的沮丧。如果我那会知道别的创造者-比如画家和建筑师-的做法的话,我就早该知道这种方法的名字,那就是:打草稿。我可以告诉你,他们在大学时教我的方法是错的。你应当是一边写程序一边来确定程序的走向, 这和画家, 作家以及建筑师的做法完全一样。

Realizing this has real implications for software design. It means that a programming language should, above all, be malleable. A programming language is for?thinking?of programs, not for expressing programs you've already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that's not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.
这里蕴涵着软件设计的真义, 认识到这一点, 就意味着程序语言应当首先要具有延展性。语言要有助于在编程中思考, 而不是仅仅表达思考的结果。它应该象铅笔, 而不是象钢笔。如果程序员真的象大学里教的那样写程序, 那么静态类型语言就是不错的选择。但是我所知道的黑客都不是那样子编程序的。我们需要这样一种语言, 我们用它来随意涂抹。而使用静态类型语言编程序的感觉, 就好象手放在膝盖上, 小心翼翼握着茶杯, 正襟危坐着和一个严肃的老太太谈话。

While we're on the subject of static typing, identifying with the makers will save us from another problem that afflicts the sciences: math envy. Everyone in the sciences secretly believes that mathematicians are smarter than they are. I think mathematicians also believe this. At any rate, the result is that scientists tend to make their work look as mathematical as possible. In a field like physics this probably doesn't do much harm, but the further you get from the natural sciences, the more of a problem it becomes.
谈论静态类型, 以及创造者这种话题, 我们除去了另外一个困扰的科学的问题: 数学嫉妒。科学界的每个人暗地里都认为数学家比自己聪明。我想数学家们自己大概也这么认为。反正科学家们总是把自己的作品弄得象数学论文一样。这对物理学倒还没什么大害, 但是你要是在自然科学上走得越远, 就越发现这个问题的严重性。

A page of formulas just looks so impressive. (Tip: for extra impressiveness, use Greek variables.) And so there is a great temptation to work on problems you can treat formally, rather than problems that are, say, important.
印上一整页的公式, 看上去很让人敬畏的样子, 用上希腊字母就更加不得了。这种倾向可能诱惑你去研究那些可以公式化的问题, 结果是忽略了真正重要的东西。

If hackers identified with other makers, like writers and painters, they wouldn't feel tempted to do this. Writers and painters don't suffer from math envy. They feel as if they're doing something completely unrelated. So are hackers, I think.
如果黑客认同创作者的身份, 像是画家和作家一样, 他们就不会受此诱惑。作家和画家才不理会数学呢, 根本就是不相干的事情。我认为, 黑客也应当这样看。

If universities and research labs keep hackers from doing the kind of work they want to do, perhaps the place for them is in companies. Unfortunately, most companies won't let hackers do what they want either. Universities and research labs force hackers to be scientists, and companies force them to be engineers.
如果大学和研究所不让黑客做自己想做的事情, 他们还可以去公司, 可惜, 公司和大学的做法是一丘之貉。大学和研究所要求黑客当科学家, 而公司要求黑客当工程师。

I only discovered this myself quite recently. When Yahoo bought Viaweb, they asked me what I wanted to do. I had never liked the business side very much, and said that I just wanted to hack. When I got to Yahoo, I found that what hacking meant to them was implementing software, not designing it. Programmers were seen as technicians who translated the visions (if that is the word) of product managers into code.
我也是最近才发现这问题的。Yahoo买了Viaweb之后, 他们问我的意向, 我一向就不喜欢商业公司, 我就说我还是想编程序。进了Yahoo以后, 我发现在他们那里, 编程序的意思就是代码实现, 和设计没关系。程序员就是代码工人, 他们把产品经理的愿望, 以代码形式记录下来。

This seems to be the default plan in big companies. They do it because it decreases the standard deviation of the outcome. Only a small percentage of hackers can actually design software, and it's hard for the people running a company to pick these out. So instead of entrusting the future of the software to one brilliant hacker, most companies set things up so that it is designed by committee, and the hackers merely implement the design.
看起来这是大公司的一贯的做法。这样做的目的是减低工作的偏差。只有少数程序员真正懂得设计软件, 而且这些有才能的人很不容易一下子识别出来。所以与其把软件的未来寄托在少数聪明人身上, 不如把软件设计让一个委员会来作, 程序员只管编码实现。

If you want to make money at some point, remember this, because this is one of the reasons startups win. Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low. This is not a problem for big companies, because they don't win by making great products. Big companies win by sucking less than other big companies.
如果你想赚钱, 那么记住我的话, 因为我讲的, 正是小公司取胜的机会。大公司采取保险的做法, 意图规避风险。但是试图限制这种工作效果上的震荡的时候, 固然避免了最坏的可能,但也失去了最好的。这对大公司当然不是问题, 大公司取胜的原因不是因为发明了伟大的产品, 而是因为犯的错误比其他大公司少而已。

So if you can figure out a way to get in a design war with a company big enough that its software is designed by product managers, they'll never be able to keep up with you. These opportunities are not easy to find, though. It's hard to engage a big company in a design war, just as it's hard to engage an opponent inside a castle in hand to hand combat. It would be pretty easy to write a better word processor than Microsoft Word, for example, but Microsoft, within the castle of their operating system monopoly, probably wouldn't even notice if you did.
如果你有办法和一个大公司竞争某种产品, 这个公司的产品是产品经理们设计的, 那么, 他们永远赶不上你。不过这样的机会很不容易找到。你很难和大公司卷入软件竞争, 就好比你很难和对手在城堡里徒手搏斗一样。写一个比微软的word还要好的字处理器是可能的, 但是在操作系统这个微软独占的堡垒里, 他们对你根本就不屑一顾。

The place to fight design wars is in new markets, where no one has yet managed to establish any fortifications. That's where you can win big by taking the bold approach to design, and having the same people both design and implement the product. Microsoft themselves did this at the start. So did Apple. And Hewlett-Packard. I suspect almost every successful startup has.
软件竞争只能在全新的市场中展开, 因为在那里还没有谁建立起防御工事。你有可能采取大胆的策略, 集合那些既做设计又做编码的人, 来赢得竞争。微软最初就是这样做的, 苹果,HP也莫不如此。我想任何成功的创业公司都是走的这条路。

So one way to build great software is to start your own startup. There are two problems with this, though. One is that in a startup you have to do so much besides write software. At Viaweb I considered myself lucky if I got to hack a quarter of the time. And the things I had to do the other three quarters of the time ranged from tedious to terrifying. I have a benchmark for this, because I once had to leave a board meeting to have some cavities filled. I remember sitting back in the dentist's chair, waiting for the drill, and feeling like I was on vacation.
所以, 创造伟大软件的一个办法就是创业开公司。不过这里面还有两个问题。第一, 开公司以后, 除了编程序, 你需要做好多其他事情。在Viaweb的时候, 我真的希望自己能挤出四分之一的时间编程就好了。实际上我四分之三的时间都是在做很讨厌甚至很麻烦的事情。对此我深有体会, 有一次当我开完董事会去补牙, 坐在诊所的椅子上, 我觉得简直抵得上度假了。

The other problem with startups is that there is not much overlap between the kind of software that makes money and the kind that's interesting to write. Programming languages are interesting to write, and Microsoft's first product was one, in fact, but no one will pay for programming languages now. If you want to make money, you tend to be forced to work on problems that are too nasty for anyone to solve for free.
还有另一个问题。写有趣的软件, 和写赚钱的软件, 经常是没多少共同之处。设计语言是很有趣的工作, 微软的第一个产品就是。但是现在没人会花钱买语言。要想赚钱就得写那种很麻烦的, 没人会免费干的软件。

All makers face this problem. Prices are determined by supply and demand, and there is just not as much demand for things that are fun to work on as there is for things that solve the mundane problems of individual customers. Acting in off-Broadway plays just doesn't pay as well as wearing a gorilla suit in someone's booth at a trade show. Writing novels doesn't pay as well as writing ad copy for garbage disposals. And hacking programming languages doesn't pay as well as figuring out how to connect some company's legacy database to their Web server.
所有的创造者都会面临这个问题。价格是供求关系决定的, 对有趣软件的需求总是比较少,而解决一般用户的平凡问题的需求, 总是多一些。在高速公路边上演出, 观众一定少, 在庙会搭个台子演出, 观众一定多。写长篇小说的收入, 比不上写广告词的收入, 虽然那些广告最后的归宿是垃圾箱。设计一种语言的回报一定不多, 而搞定某些公司的老掉牙的数据库和web server的连接问题, 回报会丰厚得多。

I think the answer to this problem, in the case of software, is a concept known to nearly all makers: the day job. This phrase began with musicians, who perform at night. More generally, it means that you have one kind of work you do for money, and another for love.
我认为这个难题的答案, 是创造者们应当找一个养家糊口的”日常工作”。这个名词最初是惯于晚上演出的音乐家们使用的。它的意思是: 你做一个工作是为了赚钱, 另一个工作是因为你喜欢。

Nearly all makers have day jobs early in their careers. Painters and writers notoriously do. If you're lucky you can get a day job that's closely related to your real work. Musicians often seem to work in record stores. A hacker working on some programming language or operating system might likewise be able to get a day job using it. [1]
几乎所有的创造者在他们职业生涯的早期, 都有日常工作。其中最为人所知的就是画家和作家。如果能赚钱的日常工作刚好是你所喜爱的工作, 那你就太幸运了。音乐家就经常在唱片店工作。正在用某种语言或者操作系统的黑客, 也应当找个相近的系统管理或维护的工作。[1]

When I say that the answer is for hackers to have day jobs, and work on beautiful software on the side, I'm not proposing this as a new idea. This is what open-source hacking is all about. What I'm saying is that open-source is probably the right model, because it has been independently confirmed by all the other makers.
黑客应当找个日常工作糊口, 业余时间做自己喜爱的程序。我的这个说法并不是独出心裁。所有的开源社区的黑客都是这样做的。我要说的是, 开源社区的模型也许是正确的模型, 因为这种模型被其他创造者分别独立地验证过。

It seems surprising to me that any employer would be reluctant to let hackers work on open-source projects. At Viaweb, we would have been reluctant to hire anyone who didn't. When we interviewed programmers, the main thing we cared about was what kind of software they wrote in their spare time. You can't do anything really well unless you love it, and if you love to hack you'll inevitably be working on projects of your own. [2]
一般的雇主都不太愿意雇员参与开源项目, 这让我有一点惊奇。在Viaweb则相反, 我们不愿意雇佣没有做过开源项目的人。面试程序员的时候, 我们考虑的一个首要问题就是, 他们业余时间写什么软件。你要不是真的热爱这个工作, 就不可能干的出色。如果你热爱编程, 就必然会有自己热爱的业余项目。[2]

Because hackers are makers rather than scientists, the right place to look for metaphors is not in the sciences, but among other kinds of makers. What else can painting teach us about hacking?
黑客是创造者, 不太象是科学家。黑客寻找灵感的地方, 不应当是科学领域, 而是其他创造者工作的领域。那么, 我们从绘画上, 能够得到什么启示呢?

One thing we can learn, or at least confirm, from the example of painting is how to learn to hack. You learn to paint mostly by doing it. Ditto for hacking. Most hackers don't learn to hack by taking college courses in programming. They learn to hack by writing programs of their own at age thirteen. Even in college classes, you learn to hack mostly by hacking. [3]
第一件可以从绘画领域学习的, 或者说可以验证的, 就是怎样学习编程。绘画都是在实践中学会的, 编程亦然。大部分黑客都不是因为念大学计算机课才走上编程之路的。他们13岁年纪就开始学着写程序。即使是上了大学计算机课, 你真正学会编程, 大多也是通过自己实际写程序。[3]

Because painters leave a trail of work behind them, you can watch them learn by doing. If you look at the work of a painter in chronological order, you'll find that each painting builds on things that have been learned in previous ones. When there's something in a painting that works very well, you can usually find version 1 of it in a smaller form in some earlier painting.
画家通常会留下一系列作品, 你可以从中观察到他们在实践中学习的过程。如果你按年代顺序观察一个画家的作品, 你会发现后一个作品在前一个作品基础上的提高。如果一幅画中的某样东西特别出色, 你多半会在更早的作品中发现其发展成熟的轨迹。

I think most makers work this way. Writers and architects seem to as well. Maybe it would be good for hackers to act more like painters, and regularly start over from scratch, instead of continuing to work for years on one project, and trying to incorporate all their later ideas as revisions.
我认为大多数创造者都是这样工作的。作家和建筑设计师也不例外。对于黑客而言, 我觉得这样的做法大概比较好: 从一个大概的草稿开始起步, 不断尝试采纳新的想法, 做修订版,而不是连续几年埋头做一个题目。

The fact that hackers learn to hack by doing it is another sign of how different hacking is from the sciences. Scientists don't learn science by doing it, but by doing labs and problem sets. Scientists start out doing work that's perfect, in the sense that they're just trying to reproduce work someone else has already done for them. Eventually, they get to the point where they can do original work. Whereas hackers, from the start, are doing original work; it's just very bad. So hackers start original, and get good, and scientists start good, and get original.
这种工作模式是区别黑客和科学家的另一个显著标志。科学家并不通过干活来学习科学, 他们通过做实验和解题来学习科学。科学家总是从完美的东西开始, 也就是说他们重复前人已经做过的工作, 最后达到某种高度, 才开始做自己创造性的工作。而黑客呢, 一开始就是做创造性的工作–当然这时候作品还不成样子。黑客从创造开始, 最终达到完美。而科学家从完美开始, 最终达到创造。

The other way makers learn is from examples. For a painter, a museum is a reference library of techniques. For hundreds of years it has been part of the traditional education of painters to copy the works of the great masters, because copying forces you to look closely at the way a painting is made.
创造者学习的另一种方法是观摩杰作。对画家来说, 美术馆是技巧的宝库。几百年来, 美术馆都是画家学习和借鉴大师作品的地方, 它成为传统教育方式的一个部分。观摩杰作强迫画家仔细观察那幅画是如何画成的。

Writers do this too. Benjamin Franklin learned to write by summarizing the points in the essays of Addison and Steele and then trying to reproduce them. Raymond Chandler did the same thing with detective stories.
作家也是如此。本杰明-富兰克林曾经总结Addison和Steel的散文的特点, 并加以模仿。Raymond Chandler也是这样学写侦探小说的。

Hackers, likewise, can learn to program by looking at good programs-- not just at what they do, but the source code too. One of the less publicized benefits of the open-source movement is that it has made it easier to learn to program. When I learned to program, we had to rely mostly on examples in books. The one big chunk of code available then was Unix, but even this was not open source. Most of the people who read the source read it in illicit photocopies of John Lions' book, which though written in 1977 was not allowed to be published until 1996.
同样, 黑客也是通过看优秀的程序来学习编程–不仅看它的外在表现, 而且要看源码。开源软件有一个少人提及的优点就是: 你很容易从中学习编程。我学编程的时候, 不得不依赖书里的例子。其中有一大堆代码是属于Unix的, 但Unix也不开源。大部分人是读John Lions的书里的源代码, 而这些内容是不合法的。这本写于1977年的书, 直到1996年都还被禁止出版。

Another example we can take from painting is the way that paintings are created by gradual refinement. Paintings usually begin with a sketch. Gradually the details get filled in. But it is not merely a process of filling in. Sometimes the original plans turn out to be mistaken. Countless paintings, when you look at them in xrays, turn out to have limbs that have been moved or facial features that have been readjusted.
绘画的过程就是不断改进的过程, 这是值得我们学习的另一个地方。绘画通常从草图开始,逐渐地添上细节, 但又不仅仅是添上细节那么简单。有时候会发现最初的想法是错的。无数的人像作品, 在x光照射之下, 会发现面部轮廓修改过, 嘴的位置也移动过, 诸如此类。

Here's a case where we can learn from painting. I think hacking should work this way too. It's unrealistic to expect that the specifications for a program will be perfect. You're better off if you admit this up front, and write programs in a way that allows specifications to change on the fly.
这就是我们应当学习的榜样, 编程也应当遵循同样的做法。想要假设软件的规格设计完美无缺, 这显然是不切实际的。预先接受这种现实对你有好处, 写程序的时候就会有所准备,随时应对可能发生的设计规格上的改变。

(The structure of large companies makes this hard for them to do, so here is another place where startups have an advantage.)
(大公司很难做到这一点, 这又是一个小公司可以发挥优势的地方。)

Everyone by now presumably knows about the danger of premature optimization. I think we should be just as worried about premature design-- deciding too early what a program should do.
现在差不多每个人都知道过早优化的危险。我认为我们也同样应当顾虑另外一个问题, 就是过迟确定软件的设计规格。

The right tools can help us avoid this danger. A good programming language should, like oil paint, make it easy to change your mind. Dynamic typing is a win here because you don't have to commit to specific data representations up front. But the key to flexibility, I think, is to make the language very?abstract. The easiest program to change is one that's very short.
好的工具可以帮助我们避免这个危险。好的语言也可以帮助你较容易地改变主意。动态类型语言就有这个优点, 你用不着预先就指定数据的表现形式。不过, 我认为弹性的关键之处在于, 它使语言具有较高的抽象度, 如果一个程序比较短, 那它就比较容易修改。

This sounds like a paradox, but a great painting has to be better than it has to be. For example, when Leonardo painted the portrait of?Ginevra de Benci?in the National Gallery, he put a juniper bush behind her head. In it he carefully painted each individual leaf. Many painters might have thought, this is just something to put in the background to frame her head. No one will look that closely at it.
这似乎听起来让人迷惑。但是伟大的作品总是精益求精。例如, 达芬奇在国家美术馆画Genevra de Benci像的时候, 头像后面是桧柏树丛, 他仔细地描绘每一片叶子。许多画家也许认为,这些东西是衬托头像的, 没人会仔细看。

Not Leonardo. How hard he worked on part of a painting didn't depend at all on how closely he expected anyone to look at it. He was like Michael Jordan. Relentless.
达芬奇并不这样认为。他绘画的认真程度, 并不取决于看画的人的认真程度如何。他就像麦克·乔丹,不断重复。

Relentlessness wins because, in the aggregate, unseen details become visible. When people walk by the portrait of Ginevra de Benci, their attention is often immediately arrested by it, even before they look at the label and notice that it says Leonardo da Vinci. All those unseen details combine to produce something that's just stunning, like a thousand barely audible voices all singing in tune.
达芬奇和米开朗琪罗一样, 都是一丝不苟。从总体看去, 那些似乎看不见的细节也会变得显著。这是一丝不苟的重要之处。观众经过这幅画的时候, 注意力一下子就被吸引过去, 那些原本不易觉察的细节, 综合在一起产生了惊人的效果, 就好像一千个细微的声音唱出的和声一样。

Great software, likewise, requires a fanatical devotion to beauty. If you look inside good software, you find that parts no one is ever supposed to see are beautiful too. I'm not claiming I write great software, but I know that when it comes to code I behave in a way that would make me eligible for prescription drugs if I approached everyday life the same way. It drives me crazy to see code that's badly indented, or that uses ugly variable names.
伟大的软件对于美的追求, 也需要超人的投入。当你仔细查看好软件的时候, 会发现那些不为人注意的部分同样优美。我不是说我自己写的软件是伟大的, 但我知道, 写代码的时候,要尽量写得清晰易读。有的程序变量名取得丑陋极了, 有的程序行缩进乱七八糟, 读这样的代码真能让我发疯。

If a hacker were a mere implementor, turning a spec into code, then he could just work his way through it from one end to the other like someone digging a ditch. But if the hacker is a creator, we have to take inspiration into account.
如果把黑客仅仅当作代码工人的话, 那他会像工人挖水沟一样从一头干到另一头。但是如果把黑客当作创造者的话, 我们就必须考虑灵感的因素。

In hacking, like painting, work comes in cycles. Sometimes you get excited about some new project and you want to work sixteen hours a day on it. Other times nothing seems interesting.
编程序的过程和绘画的过程类似, 也会有起有落。上新项目的时候, 一天干16个小时不知道累, 也有时候, 无论如何都提不起兴致。

To do good work you have to take these cycles into account, because they're affected by how you react to them. When you're driving a car with a manual transmission on a hill, you have to back off the clutch sometimes to avoid stalling. Backing off can likewise prevent ambition from stalling. In both painting and hacking there are some tasks that are terrifyingly ambitious, and others that are comfortingly routine. It's a good idea to save some easy tasks for moments when you would otherwise stall.
这种状况也必须考虑在内, 你应对的方法不同, 效果也会不一样。当你开着手动档汽车过山的时候, 有时候为了防止抛锚, 不得不松开离合器。松开离合器可以防止抛锚。在绘画和编程之中, 有一些是关键的东西, 另外一些是常规的工作, 留下一些容易作的工作, 等你厌倦的时候, 就做这些较轻松的工作。

In hacking, this can literally mean saving up bugs. I like debugging: it's the one time that hacking is as straightforward as people think it is. You have a totally constrained problem, and all you have to do is solve it. Your program is supposed to do x. Instead it does y. Where does it go wrong? You know you're going to win in the end. It's as relaxing as painting a wall.
比如说, 在编程时可以故意留一些bug, 我比较喜欢找bug。这时候, 黑客这个词的含义可以说恰当极了。你面临的问题总体上是有限制的, 你要做的就是解决掉它。假定你的程序应该做x, 结果却做了y, 哪里出了问题? 你可以断定最终一定是可以解决的。这个活跟刷墙一样, 是不错的调剂。

The example of painting can teach us not only how to manage our own work, but how to work together. A lot of the great art of the past is the work of multiple hands, though there may only be one name on the wall next to it in the museum. Leonardo was an apprentice in the workshop of Verrocchio and painted one of the angels in his?Baptism of Christ. This sort of thing was the rule, not the exception. Michelangelo was considered especially dedicated for insisting on painting all the figures on the ceiling of the Sistine Chapel himself.
绘画不仅可以教我们如何处理自己的工作, 还教我们如何协同工作。过去很多伟大的作品都是由一群人共同完成的, 尽管在美术馆的标签上可能只写着一个人的名字。达芬奇在Verrocchio的工作室当学徒时, 就参与绘制《基督受洗》中的天使。这样的事情当时很常见。当米开朗其罗坚持要自己一人绘制西斯廷教堂屋顶的人像时, 就被认为是很不得体的事情。

As far as I know, when painters worked together on a painting, they never worked on the same parts. It was common for the master to paint the principal figures and for assistants to paint the others and the background. But you never had one guy painting over the work of another.
就我所知, 画家们一起作画时, 他们并不是一起画一个共同的部分, 而是一个主要画家画主题人物, 他的副手画背景和其他部分, 绝对不会有人掺和别人正在画的东西。

I think this is the right model for collaboration in software too. Don't push it too far. When a piece of code is being hacked by three or four different people, no one of whom really owns it, it will end up being like a common-room. It will tend to feel bleak and abandoned, and accumulate cruft. The right way to collaborate, I think, is to divide projects into sharply defined modules, each with a definite owner, and with interfaces between them that are as carefully designed and, if possible, as articulated as programming languages.
我认为这种模式也适用于软件开发, 不过别走得太远。如果一段代码有三四个程序员分别写过, 那么没人真正对它负责。结果就会变成公用房间一样没人收拾, 又冷清又灰暗。正确的做法是把程序分成严格定义的模块, 每个模块有专人负责, 仔细设计模块之间的接口, 使之尽可能像程序语言本身那样, 精确地表达出来。

Like painting, most software is intended for a human audience. And so hackers, like painters, must have empathy to do really great work. You have to be able to see things from the user's point of view.
软件和绘画一样, 都是为人而做的。黑客也应当像画家一样, 努力创作出伟大的作品。你必须为用户的立场着想。

When I was a kid I was always being told to look at things from someone else's point of view. What this always meant in practice was to do what someone else wanted, instead of what I wanted. This of course gave empathy a bad name, and I made a point of not cultivating it.
我小时候, 就听人讲要学会从别人的立场来设想。意思就是做别人想要你做的事情, 而不是做你自己想做的事情。这当然给”换位思考”这个词带来了坏名声。因此我一直不愿意这样做。

Boy, was I wrong. It turns out that looking at things from other people's point of view is practically the secret of success. It doesn't necessarily mean being self-sacrificing. Far from it. Understanding how someone else sees things doesn't imply that you'll act in his interest; in some situations-- in war, for example-- you want to do exactly the opposite. [4]
可是, 我错了。换位思考确实是成功的秘密, 这并不意味着放弃自我。理解别人的观点, 并不是说你要按别人的兴趣办事。在某种情况下刚好相反, 举个例子, 打仗的时候, 理解敌人观点, 其目的恰好是要反其道而行之。[4]

Most makers make things for a human audience. And to engage an audience you have to understand what they need. Nearly all the greatest paintings are paintings of people, for example, because people are what people are interested in.
大多数创作是为人的, 你得理解人的需要。差不多所有伟大的作品主题都是人, 因为人最感兴趣的, 就是人类自身。

Empathy is probably the single most important difference between a good hacker and a great one. Some hackers are quite smart, but when it comes to empathy are practically solipsists. It's hard for such people to design great software [5], because they can't see things from the user's point of view.
好程序员和伟大的程序员之间的唯一的差别, 就是体察别人的能力。有些程序员很聪明, 但论到”换位思考”, 则是完全的自我主义者。这样的人不可能设计出伟大的软件[5], 他们从来不懂得理解别人的观点。

One way to tell how good people are at empathy is to watch them explain a technical question to someone without a technical background. We probably all know people who, though otherwise smart, are just comically bad at this. If someone asks them at a dinner party what a programming language is, they'll say something like ``Oh, a high-level language is what the compiler uses as input to generate object code.'' High-level language? Compiler? Object code? Someone who doesn't know what a programming language is obviously doesn't know what these things are, either.
判断一个人换位思考的能力如何, 最好的办法是看他怎样向那些不懂技术的人讲解技术问题。我们大概都见过那样一些人, 不管多么聪明, 这件事情上却是糟得很。如果有人问, 什么是编程语言, 他们会说, 呃, 就是一种高级语言, 能经过编译器处理产生目标码。高级语言?编译器? 目标码? 不知道编程语言的人, 难道会知道这些东西?

Part of what software has to do is explain itself. So to write good software you have to understand how little users understand. They're going to walk up to the software with no preparation, and it had better do what they guess it will, because they're not going to read the manual. The best system I've ever seen in this respect was the original Macintosh, in 1985. It did what software almost never does: it just worked. [6]
软件的目标之一, 就是解释自己。你要写出好程序, 就应当知道用户对软件了解甚少。他们用软件时, 全无思想准备。如果软件的行为刚好合乎他们的设想, 那就最好了。别指望用户会去读操作手册。这方面, 我见过的最好系统是早期的苹果, 那时候还是1985年。苹果干了所有软件都做不了的事情, 那就是能正常运行。[6]

Source code, too, should explain itself. If I could get people to remember just one quote about programming, it would be the one at the beginning of?Structure and Interpretation of Computer Programs.
源码同样也应当解释自己。如果让人回忆关于编程的名言, 经常提到的是结构化和解释语言初期的一句话:

Programs should be written for people to read, and only incidentally for machines to execute.

程序写出来是给人看的, 碰巧机器也能运行。

You need to have empathy not just for your users, but for your readers. It's in your interest, because you'll be one of them. Many a hacker has written a program only to find on returning to it six months later that he has no idea how it works. I know several people who've sworn off Perl after such experiences. [7]
你不但要为用户设身处地地着想, 对读者也是一样, 因为读者可能就是你自己。好多程序员写了程序, 过半年再看, 简直看不懂究竟是怎么回事。我就见过有几个人因为这原因放弃了perl。[7]

Lack of empathy is associated with intelligence, to the point that there is even something of a fashion for it in some places. But I don't think there's any correlation. You can do well in math and the natural sciences without having to learn empathy, and people in these fields tend to be smart, so the two qualities have come to be associated. But there are plenty of dumb people who are bad at empathy too. Just listen to the people who call in with questions on talk shows. They ask whatever it is they're asking in such a roundabout way that the hosts often have to rephrase the question for them.
缺乏换位思考的能力仿佛是高智商的特征, 尤其在某些地方, 这都成了一种风尚。但我不觉得真的有什么关联。数学和自然科学和人类感情无关, 这些领域的人显然都很聪明, 于是乎高智商就和”不通世故人情”挂起构来。事实上好多平常智商的人在这方面也不行。看看脱口秀节目里那些站起来发问的人, 那些问题问的, 真叫拐弯抹角, 主持人得重新梳理一遍, 才能搞得清是啥意思。

So, if hacking works like painting and writing, is it as cool? After all, you only get one life. You might as well spend it working on something great.
如果编程和绘画写作一样的话, 它也一样酷吗? 毕竟, 人只有一次生命, 最好是做有意义的事情。

Unfortunately, the question is hard to answer. There is always a big time lag in prestige. It's like light from a distant star. Painting has prestige now because of great work people did five hundred years ago. At the time, no one thought these paintings were as important as we do today. It would have seemed very odd to people at the time that Federico da Montefeltro, the Duke of Urbino, would one day be known mostly as the guy with the strange nose in a?painting?by Piero della Francesca.
这问题真难回答。在赢得名气上总是有很大的滞后。这就好像遥远的星星发出的亮光, 要经过好多年才能到达我们眼里。绘画行业光芒四射是因为500年前就产生的杰作。那时候,没人会象我们现在这样看重这些作品。我们现在所知的Urbino公爵Federico daMontafeltro先生的形象, 是从Piero della Francesca的作品里的高鼻子男人哪里得来的。这在当时的人眼里看来, 一定是非常奇特的。

So while I admit that hacking doesn't seem as cool as painting now, we should remember that painting itself didn't seem as cool in its glory days as it does now.
所以当我说编程没有绘画那么酷的时候, 我们应当记住绘画在它古老的光辉年代, 同样也不见得那么酷。

What we can say with some confidence is that these are the glory days of hacking. In most fields the great work is done early on. The paintings made between 1430 and 1500 are still unsurpassed. Shakespeare appeared just as professional theater was being born,and pushed the medium so far that every playwright since has had to live in his shadow. Albrecht Durer did the same thing with engraving, and Jane Austen with the novel.
我们可以自信地说, 现在正是黑客事业的光辉年代, 在大部分领域, 伟大的作品诞生很早。1430-1500年代的绘画现在仍难以超越, 莎士比亚彷佛生来就是戏剧家, 把这门艺术推进到如此之高的程度, 以致于后来的剧作家都生活在他的阴影里。Albrecht Durer之于雕刻, 奥斯丁之于小说, 也是如此。

Over and over we see the same pattern. A new medium appears, and people are so excited about it that they explore most of its possibilities in the first couple generations. Hacking seems to be in this phase now.
一次又一次, 我们看到同样的模式。新的媒体诞生了, 人们热情高涨, 短短几代人就把它的能量发挥到极至。黑客事业似乎也正处于这样的时期。

Painting was not, in Leonardo's time, as cool as his work helped make it. How cool hacking turns out to be will depend on what we can do with this new medium.
达芬奇时代的绘画行业并不酷, 是他的杰作造就了绘画行业的酷。黑客事业之未来, 全依赖我们今日之创造。

Notes
作者注:

[1] The greatest damage that photography has done to painting may be the fact that it killed the best day job. Most of the great painters in history supported themselves by painting portraits.
[1] 照相术的出现, 毁掉了画家的日常工作。历史上很多画家靠替人画像维持生计。

[2] I've been told that Microsoft discourages employees from contributing to open-source projects, even in their spare time. But so many of the best hackers work on open-source projects now that the main effect of this policy may be to ensure that they won't be able to hire any first-rate programmers.
[2] 我听说微软不鼓励员工从事开源项目, 业余搞也不行。不过现在有那么多黑客都在做开源项目, 这种政策也许会令他们难以招募到很多一流程序员。

[3] What you learn about programming in college is much like what you learn about books or clothes or dating: what bad taste you had in high school.
[3] 大学所能学到的编程技术, 其状况相当于你学到的关于读书, 打扮或者约会的知识: 你上高中那时候的品味多差啊。

[4] Here's an example of applied empathy. At Viaweb, if we couldn't decide between two alternatives, we'd ask, what would our competitors hate most? At one point a competitor added a feature to their software that was basically useless, but since it was one of few they had that we didn't, they made much of it in the trade press. We could have tried to explain that the feature was useless, but we decided it would annoy our competitor more if we just implemented it ourselves, so we hacked together our own version that afternoon.
[4] 这里有一个”换位思考”的例子。在Viaweb的时候, 如果在两个选择之间下不了决心, 我们就会问: 我们的对手最恨什么? 当一个对手在软件里加了个没用的特性, 这个特性我们没有, 他们就在媒体上大作文章。我们当然也可以解释说这个特性根本是废物, 但是我们还是决定也实现它, 因为这样的话, 对手会更生气。于是当天下午我们就加上了这个特性。

[5] Except text editors and compilers. Hackers don't need empathy to design these, because they are themselves typical users.
[5] 不包括文本编辑器和编译器。因为这两样东西黑客自己也天天用, 自己就是典型用户,所以用不着了解别人的观点。

[6] Well, almost. They overshot the available RAM somewhat, causing much inconvenient disk swapping, but this could be fixed within a few months by buying an additional disk drive.
[6] 差不多如此。他们在内存使用上弄巧成拙, 产生好多很麻烦的磁盘交换。几个月后, 我买了个新驱动器加上, 这问题就解决了。

[7] The way to make programs easy to read is not to stuff them with comments. I would take Abelson and Sussman's quote a step further. Programming languages should be designed to express algorithms, and only incidentally to tell computers how to execute them. A good programming language ought to be better for explaining software than English. You should only need comments when there is some kind of kludge you need to warn readers about, just as on a road there are only arrows on parts with unexpectedly sharp curves.
[7] 给程序加注释, 并不是增加易读性的好办法。我把Abelson和Sussman的话再发挥一下:程序语言是用来表达算法的, 碰巧也能在机器上运行。好的编程语言, 表达软件的能力比英语更好。只有在代码含义复杂难解的地方, 才有必要加注释, 就好像高速公路上急转弯的地方才会有警告标志。

Thanks to Trevor Blackwell, Robert Morris, Dan Giffin, and Lisa Randall for reading drafts of this, and to Henry Leitner and Larry Finkelstein for inviting me to speak.

via: http://www.paulgraham.com/hp.html

, ,