 May 2003 2003 年 5 月 (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. 我从来不喜欢“计算机科学”这个词。 我不喜欢它的主要原因是根本没有这样的东西。 计算机科学是一堆松散相关的领域，因历史的偶然而被凑在一起，就像南斯拉夫一样。 一方面，有些人实际上是数学家，但他们称自己所做的为计算机科学，以便获得 DARPA 的资助。 中间有些人正在研究计算机的自然历史——例如，研究算法在网络中路由数据的行为。 而在另一端，有黑客，他们试图编写有趣的软件，对他们来说，计算机只是表达的媒介，就像混凝土对建筑师或油漆对画家一样。 这就好像数学家、物理学家和建筑师都必须在同一个部门一样。 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 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." 不幸的是，美丽的事物并不总是论文的最佳主题。首先，研究必须是原创的——正如任何撰写博士论文的人所知道的，确保你在探索未开发领域的方式就是占据一块没人想要的土地。其次，研究必须是实质性的——而尴尬的系统会产生更有分量的论文，因为你可以写出为完成任务而必须克服的障碍。没有什么比从错误的假设开始更能产生重要问题的了。大多数人工智能的情况就是这个规则的例子；如果你假设知识可以表示为一系列谓词逻辑表达式的列表，而这些表达式的参数代表抽象概念，那么你将有很多论文要写，讨论如何使其有效。正如里基·里卡多曾经说过的，“露西，你有很多事情需要解释。” 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 good sense 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. 唯一的外部考验是时间。随着时间的推移，美好的事物往往会繁荣，而丑陋的事物则会被抛弃。不幸的是，所需的时间可能会超过人类的寿命。塞缪尔·约翰逊曾说，一个作家的声誉需要一百年才能趋于一致。你必须等到作家有影响力的朋友去世，然后再等他们所有的追随者去世。 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. 我最近才发现这一点。当雅虎收购 Viaweb 时，他们问我想做什么。我从来不太喜欢商业方面的事情，于是我说我只想编程。当我来到雅虎时，我发现对他们来说，编程意味着实施软件，而不是设计软件。程序员被视为技术人员，他们将产品经理的愿景（如果可以这样称呼的话）转化为代码。 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. 进行设计战争的地方是在新市场，在那里还没有人成功建立任何防线。在那里，通过采取大胆的设计方法，并让同一团队负责设计和实施产品，你可以获得巨大的成功。微软在开始时就是这样做的，苹果也是，惠普也是。我怀疑几乎每一个成功的初创公司都是如此。 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. 所有制造商都面临这个问题。价格由供需决定，而对有趣的工作需求并没有解决个别客户日常问题的需求那么大。在百老汇以外的剧院演出并没有像在展会上穿着大猩猩服装那样赚钱。写小说的收入不如为垃圾处理器撰写广告文案。黑客编程语言的收入也不如弄清楚如何将某公司的遗留数据库连接到他们的网络服务器。 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] 几乎所有的创作者在职业生涯早期都有白天的工作。画家和作家尤其如此。如果你幸运的话，可以找到一份与自己真正工作密切相关的白天工作。音乐家通常似乎在唱片店工作。一个正在开发某种编程语言或操作系统的黑客也可能能够找到一份使用它的白天工作。 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，我们会对不愿意这样做的人持谨慎态度。当我们面试程序员时，我们最关心的就是他们在业余时间编写了什么软件。你无法真正做好任何事情，除非你热爱它，如果你热爱黑客技术，你必然会在自己的项目上工作。 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] 我们可以从绘画的例子中学到一件事，或者至少可以确认，那就是如何学习黑客技术。你主要是通过实践来学习绘画。黑客也是如此。大多数黑客并不是通过上大学的编程课程来学习黑客技术的。他们在十三岁时通过编写自己的程序来学习黑客技术。即使在大学课堂上，你主要也是通过黑客行为来学习黑客技术。 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. 作家们也是如此。本杰明·富兰克林通过总结阿迪森和斯蒂尔的文章要点，然后尝试重现它们来学习写作。雷蒙德·钱德勒在侦探故事中也做了同样的事情。 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，但即便如此也不是开源的。大多数阅读源代码的人都是通过非法复印的约翰·莱昂斯的书来阅读的，这本书虽然写于 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. 这听起来像是一个悖论，但一幅伟大的画作必须比它所需的更出色。例如，当达芬奇在国家美术馆绘制吉内芙拉·德·本奇的肖像时，他在她的头后面放了一丛杜松树。在那里，他仔细地画出了每一片叶子。许多画家可能会认为，这只是用来衬托她头部的背景，没人会那么仔细地看它。 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. 在黑客攻击中，就像绘画一样，工作是周期性的。有时你会对某个新项目感到兴奋，想要每天工作十六个小时。其他时候，似乎没有什么有趣的事情。 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. 在黑客攻击中，这字面上可以意味着积累漏洞。我喜欢调试：这是黑客攻击最简单明了的时刻。你面临一个完全受限的问题，你要做的就是解决它。你的程序应该执行 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. 绘画的例子不仅可以教会我们如何管理自己的工作，还可以教会我们如何合作。许多伟大的艺术作品都是多个人共同创作的，尽管在博物馆的墙上可能只有一个名字。达芬奇曾是维罗基奥工作室的学徒，并在他的《基督受洗》中画了一个天使。这种情况是常态，而非例外。米开朗基罗被认为特别专注，因为他坚持亲自绘制西斯廷教堂天花板上的所有人物。 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] 我错得离谱。事实证明，从他人的角度看问题几乎是成功的秘诀。这并不一定意味着要自我牺牲。远非如此。理解别人如何看待事物并不意味着你会按照他的利益行事；在某些情况下——例如在战争中——你可能正好想做相反的事情。 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. 同理心可能是优秀黑客与伟大黑客之间最重要的区别。一些黑客非常聪明，但在同理心方面几乎是自我中心的。这类人很难设计出优秀的软件，因为他们无法从用户的角度看问题。 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 年的原版 Macintosh。它做到了软件几乎从未做到的事情：它就是好用。 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。 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. 不幸的是，这个问题很难回答。声望总是有很大的时间滞后。这就像来自遥远星星的光芒。绘画现在有声望，是因为五百年前人们所做的伟大工作。在当时，没有人认为这些画作的重要性如我们今天所认为的那样。对于当时的人们来说，乌尔比诺公爵费德里科·达·蒙特费尔特罗有一天会因皮耶罗·德拉·弗朗西斯卡的一幅画中那个奇怪的鼻子而闻名，似乎是非常奇怪的。 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 年间创作的画作至今仍无与伦比。莎士比亚出现在专业戏剧刚刚诞生之际，并将这一媒介推向了极致，以至于此后每位剧作家都不得不生活在他的阴影之下。阿尔布雷希特·丢勒在版画方面也做到了这一点，简·奥斯汀则在小说领域达到了同样的成就。 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. 摄影对绘画造成的最大伤害可能是它扼杀了最好的日常工作。历史上大多数伟大的画家都是通过绘制肖像来维持生计的。 [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. 我听说微软不鼓励员工在业余时间参与开源项目。但如今许多顶尖黑客都在从事开源项目，因此这一政策的主要影响可能是确保他们无法招聘到任何一流的程序员。 [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. 你在大学学到的编程知识就像你对书籍、衣服或约会的理解：你在高中时的糟糕品味。 [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. 这是一个应用同理心的例子。在 Viaweb，如果我们无法在两个选择之间做出决定，我们会问，竞争对手最讨厌什么？有一次，一个竞争对手在他们的软件中添加了一个基本上无用的功能，但由于这是他们拥有而我们没有的少数几个功能之一，他们在行业媒体上大肆宣传。我们本可以试图解释这个功能是无用的，但我们决定如果我们自己实现这个功能，会让竞争对手更加恼火，于是我们在那天下午迅速制作了自己的版本。 [5] Except text editors and compilers. Hackers don't need empathy to design these, because they are themselves typical users. 除了文本编辑器和编译器。黑客在设计这些时不需要同理心，因为他们本身就是典型的用户。 [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. 好吧，差不多。他们超出了可用的 RAM，导致了许多不便的磁盘交换，但通过购买额外的磁盘驱动器，这个问题可以在几个月内解决。 [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. 使程序易于阅读的方法不是在其中塞满注释。我会进一步阐述阿贝尔森和萨斯曼的观点。编程语言应该被设计用来表达算法，而仅仅是偶然地告诉计算机如何执行它们。一种好的编程语言应该比英语更适合解释软件。只有在有某种需要警告读者的权宜之计时，你才需要注释，就像在道路上，只有在意外的急转弯处才会有箭头指示。 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. 感谢特雷弗·布莱克威尔、罗伯特·莫里斯、丹·吉芬和丽莎·兰道尔阅读这篇草稿，感谢亨利·莱特纳和拉里·芬克尔斯坦邀请我发言。 |
|
You'll find this essay and 14 others in