注：本文转自王垠的博客——当然我在扯淡：http://www.yinwang.org/blog-cn/2017/07/06/master-pl
很多编程初学者至今还在给我写信请教，问我该学习什么程序语言，怎么学习。由于我知道如何掌握“所有”的程序语言，总是感觉这种该学“一种”什么语言的问题比较低级，所以一直没来得及回复他们 :P 可是逐渐的，我发现原来不只是小白们有这个问题，就连美国大公司的很多资深工程师，其实也没搞明白。
十年学会编程不是说你要学十年才能开始编程。正像人们常说的那样，你可以在一天内学会象棋的所有规则并开始下棋，但要成为一个象棋大师，你还有很长的路要走……
注：本文转自 Peter Norvig 的 Teach Yourself Programming in Ten Years。
中文版翻译底板参考：http://daiyuwen.freeshell.org/gb/misc/21-days-cn.html 和http://blog.jobbole.com/22905/ 以及 https://blog.youxu.info/21-days.html。
注意：因为原文成文较早，而且作者似乎也一直在修改。中文版的第一个（以及最后一个）链接中的翻译部分很多过期了，新的翻译参考后面的伯乐在线（jobbole）中的。（也有不少过期的）
因为均有过期，所以在其基础上也补充了部分更新，包括修正一些翻译错误，文字错误以及一些格式上的问题等。
英文版的原文中还有一个中文翻译版本，不过链接无法打开。
信步走进任何一家书店，你会看到名为《如何在 24 小时内学会 Java》的书，还有各 种各样类似的书： 在几天内或几小时内学会 C，SQL，Ruby，算法等等，一眼望不到 尽头。我在 Amazon 上做了如下的高级检索 ：[title: teach, yourself, hours, since: 2000 得到了512 本这样的书。在前十本中有九本是关于编程的书（其它的是关于记账的）。把 “teach yourself” 换成 “learn” 或者用 "hours" 换成 "days"，可以得到了类似的结果。
Walk into any bookstore, and you'll see how to Teach Yourself Java in 24 Hours alongside endless variations offering to teach C, SQL, Ruby, Algorithms, and so on in a few days or hours. The Amazon advanced search for [title: teach, yourself, hours, since: 2000 and found 512 such books. Of the top ten, nine are programming books (the other is about bookkeeping). Similar results come from replacing "teach yourself" with "learn" or "hours" with "days."
从上面的搜索结果可以看出来，要么就是人们对计算机技术的学习如饥似渴，要么就是计算机技术实在太简单，不费吹灰之力就能学会。
The conclusion is that either people are in a big rush to learn about programming, or that programming is somehow fabulously easier to learn than anything else.
Felleisen 以及其它人在他们的著作《如何设计程序》一书中明确指出了这种“速成”的趋势，并评论到：“垃圾的编程技术当然非常容易，傻子都能在 21 天之内学会，哪怕他天生就是个白痴。” Abtruse Goose 的漫画中也有类似尝试。
Felleisen et al. give a nod to this trend in their book How to Design Programs, when they say "Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies." The Abtruse Goose comic also had their take.
让我们分析一下，象一本名为《24 小时内学会 C++》的书意味着什么：
Let's analyze what a title like Teach Yourself C++ in 24 Hours could mean:
学习： 在 24 小时里，你没有时间写一些重大的程序，并从成功或失败中得益。你没有时间与有经验的程序员合作，并理解在 C++ 的环境下工作是怎么回事。一句话，你不会有时间学到太多东西。因此他们只能谈论一些肤浅的东西，而不是深入的理解。正如亚历山大教皇所说，浅尝辄止是危险的事情。
Teach Yourself: In 24 hours you won't have time to write several significant programs, and learn from your successes and failures with them. You won't have time to work with an experienced programmer and understand what it is like to live in a C++ environment. In short, you won't have time to learn much. So the book can only be talking about a superficial familiarity, not a deep understanding. As Alexander Pope said, a little learning is a dangerous thing.
C++： 在 24小时的时间里，你可能学会 C++ 的语法（如果你 已经学过类似的语言），但你学不到更多的如何使用这些语法的知识。也就是说， 假如你曾是个 BASIC 程序员，你可以学着用 C++ 语法写出 BASIC 风格的程序，但你不可能了解 C++ 真正的好处（和坏处）。那么关键是什么？ Alan Perlis 说过：“一种不改变你编程的思维方式的语言，不值得去学。” 一种可 能的情况是：你必须学一点儿 C++（或可能性更大的像 JavaScript 或 Processing 之类），因为你为了完成某种特定的任务，需要与一个现存的工具建立接口。不过那不是学习如何编程，而是在学习如何完成那个任务。
C++: In 24 hours you might be able to learn some of the syntax of C++ (if you already know another language), but you couldn't learn much about how to use the language. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of C++ (or more likely, something like JavaScript or Processing) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task.
24 小时内： 很不幸，这不够，原因由下一节告诉我们。
in 24 Hours: Unfortunately, this is not enough, as the next section shows.
研究人员(Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973))一系列调查显示，在各个领域内，要想获得专业级别的水平，大约需要 10 年时间的努力。参与此项调查的领域包括：国际象棋，作曲，发报，绘画，钢琴演奏，游泳，网球以及对神经心理学和拓扑学的研究。若要在某一领域内达到专家级的水平，其关键在于“刻意练习”，也就是说，并非是机械地，一遍又一遍地练习，而是要不断地挑战自我，试图超越自身当前的水平，通过不断的尝试挑战，并在尝试的过程中和尝试之后对自身的表现进行分析和总结，吸取经验，纠正之前犯过的各种错误。把这一过程不断重复，才能取得成功。所谓的“捷径”是不存在的，即使对于莫扎特这种天才来说，也没有捷径可走，尽管 4 岁就开始作曲，可是他也花了 13 年的时间，才真正地写出了世界级的作品。再举一个例子，甲壳虫乐队（The Beatles）,他们似乎在 1964 年凭借一系列热门单曲和其在艾德沙利文秀（The Ed Sullivan show）上的演出一炮而红，但是你也许不知道，他们早在 1957 年就在利物浦和汉堡两地进行小规模演出了，而在此之前的非正式演出更是不计其数。甲壳虫乐队的主要成名曲《Sgt. Peppers》，则是 1967 年才发行的。
Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene with a string of #1 hits and an appearance on the Ed Sullivan show in 1964. But they had been playing small clubs in Liverpool and Hamburg since 1957, and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967.
Malcolm Gladwell 推广了这个理念，尽管他的重点在 10000 个小时而不是 10 年。Henri Cartier-Bresson (1908-2004)说过，“你所拍摄的头 10000 张照片都是最糟糕的”。（他没有预料到，有了数码相机后，有些人可以在一周内达到这个数量~）真正的专业或许需要花费一生的时间。Samuel Johnson (塞缪尔 约翰逊 1709-1784)说：“在任何一个领域要想做到极好,势必穷尽一生的精力，否则根本无法企及。” Chaucer (乔叟 1340-1400)也发出过“生命如此短暂，技能如此高深”的感叹。Hippocrates (希波克拉底，约 400BC)因写下了如下的句子而被人称颂：“ars longa, vita brevis”，该句是来自于一个更长的引用：”Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile”, 这段话（拉丁文）翻译成英语就是：“生命很短暂，但是技艺却很高深，机遇转瞬即逝，探索难以捉摸，抉择困难重重”。
Malcolm Gladwell has popularized the idea, although he concentrates on 10,000 hours, not 10 years. Henri Cartier-Bresson (1908-2004) had another metric: "Your first 10,000 photographs are your worst." (He didn't anticipate that with digital cameras, some people can reach that mark in a week.) True expertise may take a lifetime: Samuel Johnson (1709-1784) said "Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price." And Chaucer (1340-1400) complained "the lyf so short, the craft so long to lerne." Hippocrates (c. 400BC) is known for the excerpt "ars longa, vita brevis", which is part of the longer quotation "Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile", which in English renders as "Life is short, [the] craft long, opportunity fleeting, experiment treacherous, judgment difficult."
显然，没有一个单一的数字可以作为最终的回答：假定所有技能（比如编程，国际象棋，跳棋，音乐）都需要相同的时间来成为专家或者假定任何人都需要一样的时间是没理由的。正如 K. Anders Ericsson 教授所指出的那样：“在绝大多数领域，哪怕是最有天分的个人，他们达到最高水平所耗费的时间也是极为显著的。10000 小时这个数字只是想让你意识到即便是人们口中的那些最具天赋的个体想达到最高水平也需要年复一年的每周花上 10 到 20 小时。”
Of course, no single number can be the final answer: it doesn't seem reasonable to assume that all skills (e.g., programming, chess playing, checkers playing, and music playing) could all require exactly the same amount of time to master, nor that all people will take exactly the same amount of time. As Prof. K. Anders Ericssonputs it, "In most domains it's remarkable how much time even the most talented individuals need in order to reach the highest levels of performance. The 10,000 hour number just gives you a sense that we're talking years of 10 to 20 hours a week which those who some people would argue are the most innately talented individuals still need to get to the highest level."
这是我为编程成功开出的方子：Here's my recipe for programming success:
设法对编程感兴趣，并且因为它有趣而编一些程序。确保编程一直充满足够乐趣，这样你才愿意投入十年/10000 小时宝贵时间。
Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in your ten years/10,000 hours.
写程序。 最好的学习方式是 从实践中学习。 用更技术性的话说，“在一个给定的领域内，个人的最大能力不 是自动地由扩展了的经验取得的，但即使是高度有经验的人也可以通过有意识的 努力来提高自己的能力” (p. 366) 和 “最有效的学习需要因人而异的适当难度，目标明确的任务，丰富的信息反馈，以及重复的机会和错误修正。” (p. 20-21) 此书 Cognition in Practice: Mind，Mathematics，and Culture in Everyday Life 是阐明此观点的令人感兴趣的参考文献。
Program. The best kind of learning is learning by doing. To put it more technically, "the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve." (p. 366) and "the most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors." (p. 20-21) The book Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life is an interesting reference for this viewpoint.
与其他程序员交流； 阅读其它程序。这比任何书本或训练课程都重要。
Talk with other programmers; read other programs. This is more important than any book or training course.
如果愿意，在大学里呆上 4 年（或更长，在研究生院里）。你会接触到一些需要文凭的工作，你会对此领域有更深的理解。如果你不喜欢学校， 你可以（会有所牺牲）依靠自身或在工作中获得相似的经验。在任何情况下，光啃书本是不够的。Eric Raymond，The New Hacker's Dictionary 一书的作者，说过，“计算机科学不能把任何人变成编程专家，就象光研究刷子和颜料不会使人变成画家一样。” 我雇佣过的最好的程序员之一仅有高中文凭；他做出了许多优秀的软件，有他自己的新闻组， 而且通过股票期权买到了自己的夜总会。
If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don't enjoy school, you can (with some dedication) get similar experience on your own or on the job. In any case, book learning alone won't be enough. "Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter" says Eric Raymond, author of The New Hacker's Dictionary. One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub.
和其他程序员一起做项目。在其中的一些项目中作为最好的程序员； 而在另一些项目中是最差的。当你是最好的，你能测试领导项目的能力，用你 的观点激发别人。当你是最差的，你学习杰出者是怎么做的，了解他们不喜欢做 什么（因为他们吩咐你做事）。
Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you're the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you're the worst, you learn what the masters do, and you learn what they don't like to do (because they make you do it for them).
在其他程序员**之后接手项目**。使自己理解别人写的程序。 当程序的原作者不在的时候，研究什么需要理解并且修改它。思考如何设计你的 程序以便后来者的维护。
Work on projects after other programmers. Understand a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain them after you.
学习至少半打的编程语言。包括一种支持类抽象的语言（像 Java 或 C++），一种支持函数化抽象的语言（像 Lisp 或 ML 或 Haskell），一种支持语法抽象的语言（像 Lisp），一种支持声明规格说明的语言（像 Prolog 或 C++ 的模板），以及那些强调并行的语言（像 Clojure 或 Go）。
Learn at least a half dozen programming languages. Include one language that emphasizes class abstractions (like Java or C++), one that emphasizes functional abstraction (like Lisp or ML or Haskell), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), and one that emphasizes parallelism (like Clojure or Go).
请记住“计算机科学”中有“计算机”一词。了解你的计算机要花多 长时间执行一条指令，从内存中取一个字（有cache），从磁盘中读取连续的字， 和在磁盘中找到新的位置。（答案）
Remember that there is a "computer" in "computer science". Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk. (Answers here.)
参与一种语言标准化的工作。它可以是 ANSI C++ 委员会， 也可以是决定你周围小范围内的编程风格是应该两个还是四个空格缩进。通过任何一种方式，你了解到其他人在某种语言中的想法，他们的理解深度，甚至一些他们这样想的原因。
Get involved in a language standardization effort. It could be the ANSI C++ committee, or it could be deciding if your local coding style will have 2 or 4 space indentation levels. Either way, you learn about what other people like in a language, how deeply they feel so, and perhaps even a little about why they feel so.
具备良好的判断力，能尽快地从语言标准化的纠缠中脱身。
Have the good sense to get off the language standardization effort as quickly as possible.
明白了这些，仅从书本中你能得到多少就成了一个问题。在我第一个孩子出生前， 我读了所有的（关于育儿的）How to 书籍，仍然感觉是个手足无措的新手。30 个月以后，我 的第二个孩子快要出生了，我回头温习这些书了吗？ 没有。相反，我依靠我的个人 经验，它比专家写的数千页书更有用和可靠。
With all that in mind, its questionable how far you can get just by book learning. Before my first child was born, I read all the How To books, and still felt like a clueless novice. 30 Months later, when my second child was due, did I go back to the books for a refresher? No. Instead, I relied on my personal experience, which turned out to be far more useful and reassuring to me than the thousands of pages written by experts.
Fred Brooks在他的随笔 《没有银弹》 中定出了一个寻找优秀软件设计者的三步计划：
Fred Brooks, in his essay No Silver Bullet identified a three-part plan for finding great software designers:
1. 尽可能早地，有系统地识别顶级的设计人员。
1. 为设计人员指派一位职业导师，负责他们技术方面的成长，仔细地为他们规划 职业生涯。
1. 为成长中的设计人员提供相互交流和学习的机会。
1. Systematically identify top designers as early as possible.
1. Assign a career mentor to be responsible for the development of the prospect and carefully keep a career file.
1. Provide opportunities for growing designers to interact and stimulate each other.
此计划假设某些人已经具备了杰出设计者的必要才能； 要做的只是如何恰当地诱导他们。 Alan Perlis 说得更简明扼要：“每个人都能被教会雕刻：对米开朗其罗而言， 反倒是告诉他哪些事不要做。同样的道理也适用于优秀的程序员。”
This assumes that some people already have the qualities necessary for being a great designer; the job is to properly coax them along. Alan Perlis put it more succinctly: "Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers".
Perlis 认为，伟大的软件开发人员都有一种内在的特质，这种特质往往比他们所接受的训练更重要。但是这些特质是从哪里来的呢？是与生俱来的？还是通过后天勤奋而来？正如 Auguste Gusteau（动画电影《料理鼠王》里的幻象大厨）所说，“谁都能做饭，但只有那些无所畏惧的人才能成为大厨！”我把“将你生命中的大部分时间花在刻意练习上”更多视作为一种自愿！但或许“无所畏惧”才是概括它的方式。或者，就像是《料理鼠王》里那个与 Gusteau 作对的刻薄的美食评论家 Anton Ego 说的那样：“不是任何人都能成为伟大的艺术家，不过，伟大的艺术家可以来自任何地方。”
Perlis is saying that the greats have some internal quality that transcends their training. But where does the quality come from? Is it innate? Or do they develop it through diligence? As Auguste Gusteau (the fictional chef inRatatouille) puts it, "anyone can cook, but only the fearless can be great." I think of it more as willingness to devote a large portion of one's life to deliberative practice. But maybe fearless is a way to summarize that. Or, as Gusteau's critic, Anton Ego, says: "Not everyone can become a great artist, but a great artist can come from anywhere."
所以尽管买本 Java/Ruby/Javascript/PHP 的书吧。你可能会从中学到点儿东西。但作为一个程序员，你不会在 21 天内或 24 小时内改变你的人生，或你实际的水平。你尝试过连续 24 个月不懈努力提高自己么？呵呵，如果你做到了，好吧，那么你开始上路了……
So go ahead and buy that Java/Ruby/Javascript/PHP book; you'll probably get some use out of it. But you won't change your life, or your real overall expertise as a programmer in 24 hours or 21 days. How about working hard to continually improve over 24 months? Well, now you're starting to get somewhere...
Bloom, Benjamin (ed.) Developing Talent in Young People, Ballantine, 1985.
Brooks, Fred, No Silver Bullets, IEEE Computer, vol. 20, no. 4, 1987, p. 10-19.
Bryan, W.L. & Harter, N. "Studies on the telegraphic language: The acquisition of a hierarchy of habits. Psychology Review, 1899, 8, 345-375
Hayes, John R., Complete Problem Solver Lawrence Erlbaum, 1989.
Chase, William G. & Simon, Herbert A. "Perception in Chess" Cognitive Psychology, 1973, 4, 55-81.
Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988.
典型 PC 系统各种操作指令的大概时间（nanosec：纳秒）Approximate timing for various operations on a typical PC:
| execute typical instruction
执行基本指令 |
1/1,000,000,000 sec = 1 nanosec |
| fetch from L1 cache memory
从一级缓存中读取数据 |
0.5 nanosec |
| branch misprediction
分支预测失败 |
5 nanosec |
| fetch from L2 cache memory
从二级缓存获取数据 |
7 nanosec |
| Mutex lock/unlock
互斥加锁/解锁 |
25 nanosec |
| fetch from main memory
从主内存获取数据 |
100 nanosec |
| send 2K bytes over 1Gbps network
通过1G bps 的网络发送 2K 字节 |
20,000 nanosec |
| read 1MB sequentially from memory
从内存中顺序读取 1MB 数据 |
250,000 nanosec |
| fetch from new disk location (seek)
从新的磁盘位置获取数据（寻道） |
8,000,000 nanosec |
| read 1MB sequentially from disk
从磁盘中顺序读取 1MB 数据 |
20,000,000 nanosec |
| send packet US to Europe and back
从美国发送一个报文包到欧洲再返回 |
150 milliseconds = 150,000,000 nanosec |
Several people have asked what programming language they should learn first. There is no one answer, but consider these points:
利用你的朋友。当被问起“我该用哪种操作系统，Windows，Unix， 还是 Mac？”，我总是回答：“你朋友用什么，你就用什么。” 你从朋友那能学到知识，这种优势可以抵销不同操作系统或语言之间本质的差异。也考虑你将来的朋友：程序员社区 — 你将成为它的一部分如果你继续往前走的话。你选择的语言是否有一个成长中的社区，还是人数不多、即将消亡？ 有没有书籍、网站、 在线论坛回答你的问题？ 你喜欢论坛里的那些人吗？
Use your friends. When asked "what operating system should I use, Windows, Unix, or Mac?", my answer is usually: "use whatever your friends use." The advantage you get from learning from your friends will offset any intrinsic difference between OS, or between programming languages. Also consider your future friends: the community of programmers that you will be a part of if you continue. Does your chosen language have a large growing community or a small dying one? Are there books, web sites, and online forums to get answers from? Do you like the people in those forums?
保持简单. 像 C++ 和 Java 这样的语言是为经验丰富的 程序员组成的团队进行专业开发而设计的，他们专注于代码运行时的效率。因此，这些语言有些部分非常复杂。 而你关注的是如何编程，不需要那些复杂性。你 需要的是这样的语言： 对单个的编程新手来说，它易学易记。
Keep it simple. Programming languages such as C++ and Java are designed for professional development by large teams of experienced programmers who are concerned about the run-time efficiency of their code. As a result, these languages have complicated parts designed for these circumstances. You're concerned with learning to program. You don't need that complication. You want a language that was designed to be easy to learn and remember by a single new programmer.
练习。你偏爱哪种学弹钢琴的方式：通常的交互式的方式，你一 按下琴键就能听到音符；还是“批量”模式，你只有弹完整首曲子才能听到音符？ 显然，用交互模式学习弹钢琴更容易些，编程也一样。坚持用交互模式学习并使 用一种语言。
Play. Which way would you rather learn to play the piano: the normal, interactive way, in which you hear each note as soon as you hit a key, or "batch" mode, in which you only hear the notes after you finish a whole song? Clearly, interactive mode makes learning easier for the piano, and also for programming. Insist on a language with an interactive mode and use it.
有了上面的准则，我推荐的第一个编程语言是 Python 或 Scheme。另一个选择是 Javascript，不是因为它对初学者友好，而是因为有大量的在线教程，比如 Khan Academy's tutorial。因人而异，还有其它好的选择。如果你的年纪是 10 岁以下，你可能更喜欢Alice 或 Squeak 或 Blockly （大一些年纪的人也可能会喜欢）关键是你要选择并开始实践。
Given these criteria, my recommendations for a first programming language would be Python or Scheme. Another choice is Javascript, not because it is perfectly well-designed for beginners, but because there are so many online tutorials for it, such as Khan Academy's tutorial. But your circumstances may vary, and there are other good choices. If your age is a single-digit, you might prefer Alice or Squeak or Blockly (older learners might also enjoy these). The important thing is that you choose and get started.
不少人问我，他们该从什么书籍或网页开始学起。我重申“仅从书本里学习是不 够的。” 但我还是推荐：
Several people have asked what books and web pages they should learn from. I repeat that "book learning alone won't be enough" but I can recommend the following:
Scheme: Structure and Interpretation of Computer Programs (Abelson & Sussman)可能是最好 的计算机科学的入门书，而且它的确把讲授编程作为理解计算机科学的一种方法。 你可以在 online videos of lectures 观看本书的在线视频教程，以及 complete text online 的在线文字版。 学习本书是有些挑战的，选用其它语言会成功的人在这里可能会遇到一些困难。
Scheme: Structure and Interpretation of Computer Programs (Abelson & Sussman) is probably the best introduction to computer science, and it does teach programming as a way of understanding the computer science. You can see online videos of lectures on this book, as well as the complete text online. The book is challenging and will weed out some people who perhaps could be successful with another approach.
Scheme: How to Design Programs (Felleisen et al.)是关于如何用一种优美的、函数化的方式设 计程序的最好的书之一。
Scheme: How to Design Programs (Felleisen et al.) is one of the best books on how to actually design programs in an elegant and functional way.
Python: Python Programming: An Intro to CS (Zelle)是优秀的 Python 入门指导。
Python: Python Programming: An Intro to CS (Zelle) is a good introduction using Python.
Python: Python.org上有许多在线指导。
Python: Several online tutorials are available at Python.org.
Oz: Concepts, Techniques, and Models of Computer Programming (Van Roy & Haridi) 被视为Abelson & Sussman 的当代继承者。它是对编程的高层次概念的巡视。 涉及的范围比 Abelson & Sussman 更广，同时可能更容易学习和跟进。 它用了叫 做 Oz 的语言，不太知名，却可以作为学习其它语言的基础。
Oz: Concepts, Techniques, and Models of Computer Programming (Van Roy & Haridi) is seen by some as the modern-day successor to Abelson & Sussman. It is a tour through the big ideas of programming, covering a wider range than Abelson & Sussman while being perhaps easier to read and follow. It uses a language, Oz, that is not widely known but serves as a basis for learning other languages.
T. Capey points out that the Complete Problem Solver page on Amazon now has the "Teach Yourself Bengali in 21 days" and "Teach Yourself Grammar and Style" books under the "Customers who shopped for this item also shopped for these items" section. I guess that a large portion of the people who look at that book are coming from this page. Thanks to Ross Cohen for help with Hippocrates.
T. Capey 指出，Amazon 网页上那个 Complete Problem Solver 页面把《21 天搞定孟加拉语》以及《21 天学会语法》这两本书移到了“购买此书的用户还购买过这些产品”这个区域内。我估计大部分人就是从这个区域看到这本书的。感谢 Ross Cohen 的帮助。
这是一篇吐槽文，部分观点大家看看就好。另：这篇文章成文似乎也比较早，所以有些预测大家也可以看看是否准确。
这是我写的旋风式的编程语言简介 —— 我本来为亚马逊开发者杂志本月的期刊写的，但是发现我写的东西没法见人。
This is my whirlwind languages tour — the one I was going to write for the Amazon Developers Journal this month, but couldn't find a way to do it that was... presentable.
首先，我偶尔一不小心口出脏话，或者对上帝不恭的话，所以在很官方很正式的亚马逊上发表是不合适的； 所以我就把它塞到我的博客里了，我的博客反正没人看的。除了你以外。是的，只有你会看，你好啊。
For one thing, I lapse occasionally into coarseness and profanity here, so it wasn't appropriate for an official-ish Amazon publication. Instead, I'm stuffing it into my blog, which nobody reads. Except for you. Yep, just you. Hiya.
其次，这是一项进行中的工程，现在只是东打一耙西搞一下，还没有精加工过的。又一个把它写到博客里的很大的理由。不需要很好，或很完整。就是我今天想说的一些话。请随便！
For another, it's really a work in progress, just a few snippets here and there, not polished at all. Another great reason to make it a blog entry. Doesn't have to be good, or complete. It's just what I've got today. Enjoy!
我的旋风式简介会讲 C、C++、Lisp、Java、Perl (我们在亚马逊用到的所有语言)、Ruby (我就是喜欢) 和 Python，把 Python 加进来是因为 —— 好吧，你看了就知道了，现在我可不说。
My whirlwind tour will cover C, C++, Lisp, Java, Perl, (all languages we use at Amazon), Ruby (which I just plain like), and Python, which is in there because — well, no sense getting ahead of ourselves, now.
你必须懂 C。为啥? 因为出于所有现实的理由，这个世界上你过去，现在，将来会用到的每一台计算机都是一台冯·诺依曼机器，而 C 是一种轻量级的，很有表达力的语法，能很好的展现冯·诺依曼机器的能力。
You just have to know C. Why? Because for all practical purposes, every computer in the world you'll ever use is a von Neumann machine, and C is a lightweight, expressive syntax for the von Neumann machine's capabilities.
冯·诺依曼架构就是你每天都用的计算机的架构的标准：一个 CPU，内存，硬盘，一条总线。多核计算机并没有带来本质上的变化。冯·诺依曼机是一个很方便，很便宜，上世纪五十年代的实现图灵机的技术，图灵机是执行计算的最知名的抽象模型。
The von Neumann architecture is the standard computer architecture you use every day: a CPU, RAM, a disk, a bus. Multi-CPU doesn't really change it that much. The von Neumann machine is a convenient, cost-effective, 1950s realization of a Turing Machine, which is a famous abstract model for performing computations.
世上还有其他的计算的机器。比如，Lisp 机器，是上世纪 50 年代对 Lisp 计算模型的实现。Lisp 模型是基于 lambda 代数的一种计算语言表示法，后者是与图灵机同构的一种模型。不像图灵机，lambda 代数能被人类读和写。但是这二者是同等能力的。它们同样精确的表示了计算机能干什么。
There are other kinds of machines too. For instance, there are Lisp Machines, which are convenient 1950s realizations of Lisp, a programming language notation based on the lambda calculus, which is another model for performing computations. Unlike Turing machines, the lambda calculus can be read and written by humans. But the two models are equivalent in power. They both model precisely what computers are capable of.
Lisp 机现在不是很流行了，除了在跳蚤市场里。从谁更受欢迎来说，冯·诺依曼机器赢了。还有一些其他的计算机，比如神经网络计算机或元胞自动机，但是这些都不够大众化，至少现在是这样的。
Lisp Machines aren't very common though, except at garage sales. von Neumann machines won the popularity race. There are various other kinds of computers, such as convenient realizations of neural networks or cellular automata, but they're nowhere as popular either, at least not yet.
所以你必须知道 C。
So you have to know C.
还有一个你必须知道 C 的原因是，Unix 是用 C 写的。巧的是，Windows 也是。基本上所有的其他操作系统都是用 C 写的。因为这些操作系统都是冯·诺依曼机的操作系统，你还能用别的吗? 任何跟 C 很不一样的东西都会跟硬件的实际能力相差太远而导致无法满足性能上的需要，至少对一个操作系统来说是这样—至少在上个世纪是这样，碰巧这些系统都是上个世纪的。
You also have to know C because it's the language that Unix is written in, and happens also to be the language that Windows and virtually all other operating systems are written in, because they're OSes for von Neumann machines, so what else would you use? Anything significantly different from C is going to be too far removed from the actual capabilities of the hardware to perform well enough, at least for an OS — at least in the last century, which is when they were all written.
你还应该知道 Lisp。你不必用它来干实际工作，虽然它在很多 GNU 的软件里都会很用得着。尤其是，你应该学会 Scheme，Lisp 的一种小巧化的，纯洁的方言。GNU 的版本叫 Guile。
You should also know Lisp. You don't have to use it for real work, although it comes in quite handy for lots of GNU applications. In particular, you should learn Scheme, which is a small, pure dialect of Lisp. The GNU version is called Guile.
他们在麻省理工和加州伯克利教新学生一到两个学期的 Scheme，这些学生都对他们为啥要学这么奇怪的语言抓破脑袋。实话实说，作为第一门学习的语言，这是一个很烂的选择，第二门也是很烂。你应该学会它，最终，但不是作为第一门或第二门语言。
They teach Scheme at MIT and Berkeley to new students for a semester or two, and the students have absolutely no clue as to why they're learning this weird language. It's a lousy first language, to be honest, and probably a lousy second one too. You should learn it, eventually, and not as your first or second language.
这是很难的哦。这是很大的一步。学会怎么用 Lisp 写出像 C 语言的程序是不够的，那没有意义。C 和 Lisp 一个就像红外线，一个就像紫外线，它们分布在光谱的最两端。它俩一个牛逼的地方刚好是另一个傻逼了的地方。
It's hard, though. It's a big jump. It's not sufficient to learn how to write C-like programs in Lisp. That's pointless. C and Lisp stand at opposite ends of the spectrum; they're each great at what the other one sucks at.
如果说，C 是最靠近计算机是如何工作的语言模型，Lisp 就是最能反映计算(注意，这里没有了“机”字，计算机和计算是很不同的！译者注)是如何工作的模型。你不需要懂很多 Lisp，真的。紧咬 Scheme 就哦了，因为它是最简单最干净的。其他的 Lisp 已经发展成了很大，很复杂(很好很强大? 译者：-)的编程环境，就像 C++ 和 Java，要有很多库啊，工具啊等等之类。那些，你不需要知道。但是你应该能用 Scheme 写程序。如果你能够做出 The Little Schemer 和 The Seasoned Schemer 这两本书里的所有习题，你懂得就够多了，我认为。
If C is the closest language to modeling how computers work, Lisp is the closest to modeling how computation works. You don't need to know a lot of Lisp, really. Stick with Scheme, since it's the simplest and cleanest. Other Lisps have grown into big, complex programming environments, just like C++ and Java have, with libraries and tools and stuff. That, you don't need to know. But you should be able to write programs in Scheme. If you can make your way through all the exercises in The Little Schemer and The Seasoned Schemer, you'll know enough, I think.
但是对于你天天要做的编程工作，你应该基于以下条款选择你的语言：库，文档，工具支持，操作系统集成，资源，和一堆其他的东西。这些条款跟计算机如何工作关系很小，但是跟人类如何工作关系甚大。
But you choose a language for day-to-day programming based on its libraries, documentation, tools support, OS integration, resources, and a host of other things that have very little to do with how computers work, and a whole lot to do with how people work.
人们还在用很直白的 C 语言写东西。很多东西。你应该懂 C！
People still write stuff in straight C. Lots of stuff. You should know it!
C++ 是地球上最蠢的语言，即使是从蠢这个字的真正意义上出发。C++ 很无厘头。它不知道自己是什么东西。它没有自省(introspective，面向对象里的一个概念，译者注)。C 也没有，但是 C 不是“面向对象”的，而面向对象很大程度上是关于要让你的程序知道它自己。对象就像演员。所以面向对象语言应该有运行时的自省机制，知道自己是个什么类的对象。C++ 不是这样的，真的，你不会那样用它。
C++ is the dumbest language on earth, in the very real sense of being the least sentient. It doesn't know about itself. It is not introspective. Neither is C, but C isn't "Object-Oriented", and object orientation is in no small measure about making your programs know about themselves. Objects are actors. So OO languages need to have runtime reflection and typing. C++ doesn't, not really, not that you'd ever use.
关于 C：写一个 C 的编译器是那么的简单，以至于你可以用 C 写一个关于 C 的工具，用起来就像是有内省机制。而 C++ 呢，基本上是不可解析的，所以如果你想写一个很牛逼的工具用来 —— 比如，告诉你你的虚函数的原型，或者帮你重构你的代码，你将不得不依赖别人的工具集，因为你自己在除非脑子进屎的情况下是根本不会去写一个 C++ 的解析器的。而市面上所有的 C++ 的解析器都很傻逼。
As for C: it's so easy to write a C compiler that you can build tools on top of C that act like introspection. C++, on the other hand, is essentially un-parseable, so if you want to write smart tools that can, for example, tell you the signatures of your virtual functions, or refactor your code for you, you're stuck using someone else's toolset, since you sure as heck aren't gonna parse it. And all the toolsets for parsing C++ out there just plain suck.
C++很蠢，你不能用蠢语言创造一个好系统。语言决定世界，蠢语言决定蠢世界。
C++ is dumb, and you can't write smart systems in a dumb language. Languages shape the world. Dumb languages make for dumb worlds.
所有的计算都基于抽象。你用低级的东西创造出高级的东西。但是你不能用分子创造出一个城市。尝试使用太低级别的抽象只会给你带来麻烦。
All of computing is based on abstractions. You build higher-level things on lower-level ones. You don't try to build a city out of molecules. Trying to use too low-level an abstraction gets you into trouble.
我们就惹上麻烦了 (是指亚马逊的员工，还是所有 C++ 的程序员? 我也不知道，译者注)。
We are in trouble.
理智的情况下，你用 C 写的最大的东东就是一个操作系统。而操作系统其实不是很大的，真的。它们看起来很大，但那是因为它们有很多应用软件，操作系统本身的内核是蛮小的。
The biggest thing you can reasonably write in C is an operating system, and they're not very big, not really. They look big because of all their apps, but kernels are small.
你用 C++ 能写的最大的东东是……也是操作系统。好吧，或许稍微再大点儿。让我们说，再大三倍吧。或者 10 倍吧。但是操作系统内核最多也就，那啥，一百万行代码? 所以我说你能用 C++ 写的最大的系统大概也就是一千万行代码吧，再大的话就开始不行了，这玩意儿你没法控制了，就像恐怖片里的……
The biggest thing you can write in C++ is... also an operating system. Well, maybe a little bigger. Let's say three times bigger. Or even ten times. But operating system kernels are at most, what, maybe a million lines of code? So I'd argue the biggest system you can reasonably write in C++ is maybe 10 million lines, and then it starts to break down and become this emergent thing that you have no hope of controlling, like the plant in Little Shop of Horrors. Feeeeeed meeeeeee...
我说的一千万行是指如果你那时候还能让你的系统编译通过的话。
If you can get it to compile by then, that is.
我们(在亚马逊，译者注)有五千万行 C++ 代码。不，现在还要更多了。我已经不知道有多少行了。上个圣诞节是五千万行，那是九个月前，而它以每季度八百万行的规模增长。增长率本身也增长，妈呀。
We have 50 million lines of C++ code. No, it's more than that now. I don't know what it is anymore. It was 50 million last Christmas, nine months ago, and was expanding at 8 million lines a quarter. The expansion rate was increasing as well. Ouch.
我们想在这个系统里干点啥好像要一万年。一个亚马逊工程师有一次这样描述我们的代码库：“一座很大的屎山，你见过的最大的山，每次你想修正一个 bug，你的工作就是爬到屎山的正中心去。”
Stuff takes forever to do around here. An Amazon engineer once described our code base as "a huge mountain of poop, the biggest mountain you've ever seen, and your job is to crawl into the very center of it, every time you need to fix something."
伙计们，那哥们可是在四年前说的这话。他现在已经到更环保绿色的牧场上去了。真是太可惜了，他可是个实实在在的高手啊。
That was four years ago, folks. That engineer has moved on to greener pastures. Too bad; he was really good.
这都是 C++ 的错。别跟我争论。就是的。我们用的是世上最蠢的语言。这简直有点老板级的蠢，你说呢? (译者注，meta 在计算机术语里通常表示更高一个层次，比如，meta-language，比普通的 language 高一个层次，意思是关于语言的语言。哲学里应该会经常用到这个词。我不懂哲学，但是我觉得老板们总是比我们高一级，所以 meta-dump 我就翻译成老板级的蠢喽。：-)
It's all C++'s fault. Don't argue. It is. We're using the dumbest language in the world. That's kind of meta-dumb, don't you think?
说了以上这些难听的话，话得说回来了。用 C++ 写出漂亮的代码显然是可以的，我的意思是说，这样的代码应该大部分还是 C，偶尔很有品味的，很有节制的用一点C++。但是这种代码几乎从来不会被写出来。C++ 是个很好玩的游乐场，而如果你把它玩儿得门儿清的话你会觉得自己特牛，所以你总是被诱惑把你知道的所有的东西都用上。但是那是很难做好的，因为从一开始这个语言就太狗屎了，最终，你会弄得一塌糊涂，即使你很能干。
With that said, it is obviously possible to write nice C++ code, by which I mean, code that's mostly C, with some C++ features mixed in tastefully and minimally. But it almost never happens. C++ is a vast playground, and makes you feel smart when you know all of it, so you're always tempted to use all of it. But that's really, really hard to do well, because it's such a crap language to begin with. In the end, you just make a mess, even if you're good.
我知道，我说的都是异端邪说，该被钉到十字架上的。随便吧。我在大学里的时候老喜欢 C++ 了，因为我那时候就只知道这一门语言。当我听到我的语言教授，Craig Chambers，绝对的厌憎 C++，我想：“为啥呢? 我觉得它挺好的啊”。而当我听到 STL (标准模板库)的发明者被采访时说他恨 OOP (面向对象编程)时，我更是认为他肯定是磕药了。怎么会有人恨 OOP 呢，而这个人竟然还是 STL 的发明者?
I know, this is Heresy, with a capital-'H'. Whatever. I loved C++ in college, because it's all I knew. When I heard that my languages prof, Craig Chambers, absolutely detested C++, I thought: "Why? I like it just fine." And when I heard that the inventor of STL was on record as saying he hated OOP, I thought he was cracked. How could anyone hate OOP, especially the inventor of STL?
亲不敬，熟生厌(语出圣经，译者注)。说的是在大多数情况下，跟一件事物熟悉了之后你就失去对它的膜拜尊敬了; 在计算机语言里情况不是这样的。光对一门语言熟悉不会导致你看轻这门语言。你必须成为另一门更优秀的语言的专家(才能让你明白原来那门语言有多么多的问题)。
Familiarity breeds contempt in most cases, but not with computer languages. You have to become an expert with a better language before you can start to have contempt for the one you're most familiar with.
所以如果你不喜欢我针对 C++ 大放厥词，请你去学另一门语言并成为一个专家(我推荐 Lisp)，只有那时你才有足够的武器与我争论。然而，那时你将不会跟我争了。你上了我的当了。你也会跟我一样变得不喜欢 C++ 了，你或许会觉得我这个人很恶心，把你骗得不喜欢自己曾经的最爱了。所以或许你应该把我说的一切都忘了。C++挺好的其实，真的。它就是很棒棒(译者注，作者在这里用了 ducky，这是一个女性喜欢用的夸某物好的词，近来也为玻璃们喜爱)。忘了我说的话。C++ 不错的。
So if you don't like what I'm saying about about C++, go become an expert at a better language (I recommend Lisp), and then you'll be armed to disagree with me. You won't, though. I'll have tricked you. You won't like C++ anymore, and you might be irked that I tricked you into disliking your ex-favorite language. So maybe you'd better just forget about all this. C++ is great. Really. It's just ducky. Forget what I said about it. It's fine.
(我打赌这一节会让你觉得惊讶，即使你已经关注我的博客有一阵了[译者注，作者也可能是说，即使你成为亚马逊的员工有一阵了])
(I'm betting this next section will astonish you, even if you've been here a while.)
亚马逊创业之初，我们有很多明星级的工程师。我不认识他们所有人，但是我认识几个。
When Amazon got its start, we had brilliant engineers. I didn't know all of them, but I knew some of them.
比如？Shel Kaphan, 大拿。Greg Linden, 大拿。Eric Benson。即使在他加入亚马逊之前就已经有自己响亮的名气了。也是大拿。
Examples? Shel Kaphan. Brilliant. Greg Linden. Brilliant. Eric Benson. Independently famous in his own right, before he ever even came to Amazon. Also brilliant.
他们写了 Obidos 服务器。是 Obidos 让亚马逊成功的。只是后来那些生产大便很拿手的工程师，网页开发者，搞前端的人 —— 这些人因为生产大便很拿手而总是能让经理们满意 —— 只是在后来这些人把 Obidos 搞糟了。(他们的大便)把整条河都堵了，打个比方说的话。但是 Obidos 是亚马逊最初的成功的一块关键的基石。
They wrote the Obidos webserver. Obidos made Amazon successful. It was only later that poop-making engineers and web devs, frontend folks mostly — schedule-driven people who could make their managers happy by delivering crap fast — it was only later that these people made Obidos bad. Clogged the river, so to speak. But Obidos was a key cornerstone of Amazon's initial success.
这些最早的牛人们在亚马逊神圣的代码库里只允许两种语言：C 和 Lisp。
The original brilliant guys and gals here only allowed two languages in Amazon's hallowed source repository: C and Lisp.
你自己去想吧。
Go figure.
当然，他们所有人都使用 Emacs。靠，Eric Benson 是 XEmacs 的作者之一。这个世界上所有伟大的工程师都在用 Emacs[注1]。那种世界因你而不同级别的伟大。不是坐在你旁边的格子里的那哥们那种伟大。也不是 Fred，走廊尽头那哥们。我说的是我们这个行业里最伟大的软件开发者，那些能改变这个工业的面貌的人。像 James Gosling 们(Java 语言设计者)，Donald Knuth 们(这个人没有听说过的话赶紧改行吧，别搞计算机了)，Paul Graham 们[注2]，Jamie Zawinski 们，Eric Benson 们。真正的工程师用 Emacs。你必须很有点聪明才能把 Emacs 用好，而如果你能成为一个 Emacs 大师的话它会给你难以置信的牛力。有机会的话你应该站到 Paul Nordstrom 的肩后看看他是怎么工作的，如果你不相信我的话。对那些一辈子都在用烂 Visual Studio 之类的集成开发环境的人来说，一定会大开眼界的。
They all used Emacs, of course. Hell, Eric Benson was one of the authors of XEmacs1. All of the greatest engineers in the world use Emacs. The world-changer types. Not the great gal in the cube next to you. Not Fred, the amazing guy down the hall. I'm talking about the greatest software developers of our profession, the ones who changed the face of the industry. The James Goslings, the Donald Knuths, the Paul Grahams2, the Jamie Zawinskis, the Eric Bensons. Real engineers use Emacs. You have to be way smart to use it well, and it makes you incredibly powerful if you can master it. Go look over Paul Nordstrom's shoulder while he works sometime, if you don't believe me. It's a real eye-opener for someone who's used Visual Blub .NET-like IDEs their whole career.
Emacs 是那种你可以用 100 年的编辑器。
Emacs is the 100-year editor.
Shel, Eric, Greg，和其他像他们那样的人，我没有足够幸运能跟他们直接一起工作：他们禁止在这里使用 C++，他们禁止使用 Perl(或者 Java，为完整起见)。他们是明白人。
Shel, Eric, Greg, and others like them that I wasn't fortunate enough to work with directly: they didn't allow C++ here, and they didn't allow Perl. (Or Java, for that matter). They knew better.
现在我们都在用C++，Java 和 Perl 了，所有的代码都用这些语言。我们的前辈们已经到更环保的牧场上去了 (指没有大便的牧场，译者注)。
Now C++, Java and Perl are all we write in. The elders have moved on to greener pastures too.
Shel 用 C 写了 Mailman，客服部的人把它用 Lisp 封装了一下。Emacs-Lisp。你不需要知道 Mailman 是什么东西。除非你是个 Amazon 的老员工，或许不是搞技术的，而且你曾经不得不让客户哈皮 (只有在这种情况下你才需要知道 Mailman，译者注)。不是间接的，因为你用 C++ 写的一个狗屎功能跑不起来了，让客户很生气，于是你不得不去搞定它以恢复客户的哈皮度。不，我是说直接的，意思是，你必须跟他们聊。我们可爱的，不识字的，呱呱其谈的，心地善良的，充满希望的，困惑的，能帮点小忙的，愤怒的，哈皮的客户们，真正的客户们，那些从咱们这里买东西的人，我们的客户们。(如果你必须跟他们打交道的话，)那你就会知道 Mailman 这个东西。
Shel wrote Mailman in C, and Customer Service wrapped it in Lisp. Emacs-Lisp. You don't know what Mailman is. Not unless you're a longtime Amazon employee, probably non-technical, and you've had to make our customers happy. Not indirectly, because some bullshit feature you wrote broke (because it was in C++) and pissed off our customers, so you had to go and fix it to restore happiness. No, I mean directly; i.e., you had to talk to them. Our lovely, illiterate, eloquent, well-meaning, hopeful, confused, helpful, angry, happy customers, the real ones, the ones buying stuff from us, our customers. Then you know Mailman.
Mailman 是客服部的客户电子邮件处理软件，我们用了它有…四，五年? 反正是很长时间。它是用 Emacs 写的，所有人都爱死它了。
Mailman was the Customer Service customer-email processing application for ... four, five years? A long time, anyway. It was written in Emacs. Everyone loved it.
人们现在还很爱它。直到今天，我依旧不得不听我们一些非技术员工跟我长篇大论的叨叨他们是多么的怀念 Mailman。我可绝不是满嘴喷粪。上个圣诞节我参加了一个 Amazon 的派对，一个我不知道自己怎么会被邀请的派对，里面全是些西装笔挺的商务人士，谁都长得比我帅，比我光鲜。以及一些我在公司里曾经打过交道的人(这句不知道怎么译)。四个美女认出了我是在客服部里干的，把我包围了，跟我说了十五分钟她们是多么的怀念 Mailman 和 Emacs，而现在的亚马逊(我们用 JSP 花了好多年准备换掉 Mailman 的那一套软件)是怎么的不能满足她们，让她们觉得跟以前一样爽。
People still love it. To this very day, I still have to listen to long stories from our non-technical folks about how much they miss Mailman. I'm not shitting you. Last Christmas I was at an Amazon party, some party I have no idea how I got invited to, filled with business people, all of them much prettier and more charming than me and the folks I work with here in the Furnace, the Boiler Room of Amazon. Four young women found out I was in Customer Service, cornered me, and talked for fifteen minutes about how much they missed Mailman and Emacs, and how Arizona (the JSP replacement we'd spent years developing) still just wasn't doing it for them.
这一切都太梦幻了，我觉得她们可能是喝多了。
It was truly surreal. I think they may have spiked the eggnog.
Shel 是个天才。Emacs 是天才。连非技术人员都爱 Emacs。我现在就是在 Emacs 里打这些文字。我绝不情愿在任何其他地方打字。这不只是关于让你的效率得到飞跃，通过那些地球上其他地方找不到的快捷键和文本编辑功能。我每分钟打一百三到一百四十个英文单词，在 Emacs 里，当我在写没有格式要求的文本的时候。我测过这个时间速度。自己写了一个测打字速度的 Emacs 应用。但我想跟你说的不只是这个。
Shel's a genius. Emacs is a genius. Even non-technical people love Emacs. I'm typing in Emacs right now. I'd never voluntarily type anywhere else. It's more than just a productivity boost from having great typing shortcuts and text-editing features found nowhere else on the planet. I type 130 to 140 WPM, error-free, in Emacs, when I'm doing free-form text. I've timed it, with a typing-test Emacs application I wrote. But it's more than that.
Emacs 有的是一种你叫不出名字来的品质。
Emacs has the Quality Without a Name.
我们现在不用 Mailman 了。那是因为我们有一种叫得出名字的品质 —— 就是，烂。我们很烂。我们(当时)找不到 Emacs-Lisp 足够牛的人把 Mailman 继续搞下去。今天这应该不难了; 亚马逊现在到处都是 Emacs Lisp 的黑客。但是在那时候，客服部的人没法从别人那里得到帮助。于是他们就用他们当时手头有的资源去搞这件事。他们当时没有足够多的 Emacs-Lisp 的人。有一段时间，他们甚至找来 Bob Glickstein 当合同工，那个给 O’Reilly 写了那本 Gnu Emacs 扩展的书的家伙，坐在一个小办公室里给 Emacs 写 Mailman 的扩展。
We retired Mailman. That's because we have the Quality With a Name — namely, Suckiness. We suck. We couldn't find anyone who was good enough at Emacs-Lisp to make it work. Nowadays it would be easy; Amazon's filled up with Emacs Lisp hackers, but back then, CS Apps couldn't get the time of day from anyone, so they did what they could with what they had, and there weren't enough Emacs-Lisp folks. For a while, they even had Bob Glickstein on contract, the guy who wrote the O'Reilly "giraffe" book Writing Gnu Emacs Extensions, sitting there writing Gnu Emacs Extensions for Mailman in this little office in the Securities building.
客服应用部是 Amazon 的第一个两块比萨饼的团队(代表团队人数的增加，编者注)。这个团队是完全自立的。不管是那时还是现在。没人跟他们说话，没人帮他们。没有枪，没有炮，他们自己造。他们没有网页工程师，没有支持工程师。屁也没有。有的只是一堆骨灰级的工程师和一个能带新人的文化。这就是他们需要的一切了。
CS Apps was Amazon's first 2-pizza team, you know. They're completely autonomous — then and now. Nobody talks to them, nobody helps them, they build everything themselves. They don't have web devs, they don't have support engineers, they don't have squat, except for rock-solid engineers and a mentoring culture. And that's all they've ever needed.
但他们最终不得不让 Mailman 光荣退休。妈哎。而我呢今天还听到人们说他们是多么的怀念它。甚至在派对上。
But they had to retire Mailman. Alas. Alackaday. And I still get to hear about how much people miss it. At parties, even.
我想今天按人头比例来说，客服部仍然拥有比亚马逊任何其他团队更多的 Lisp 黑客。可能他们用到 Lisp 的机会不多了，但是 Eric Raymond 说过，即使你很少用 Lisp 写程序，学习 Lisp 会是意义深远的一个经历，能让你下辈子都成为一个更好的工程师。
I think there may still be more Lisp hackers, per capita, in CS Apps than in any other group at Amazon. Not that they get to use it much, but as Eric Raymond said, even if you don't program in it much, learning Lisp will be a profound experience that will make you a better engineer for the rest of your life.
卡尔，宗教现在已经不是大众的精神鸦片了。现在鸦片是集成开发环境了。(卡尔·马克思。这个人不知道的话应该打屁屁)。
Religion isn't the opiate of the masses anymore, Karl. IDEs are.
Java 是过去的 10 年中计算行业里发生过的最好的同时也是最坏的事。
Java is simultaneously the best and the worst thing that has happened to computing in the past 10 years.
一方面，Java 把你从 C++ 编程的很多枯燥易错的细节中解救出来了。没有数组越界了，没有 core dump 了。抛出来的异常能让你精确定位到出错的那一行代码，而且 99% 的时候都是正确的那一行出错了的代码。对象们在需要的时候能智能地把它们自己打印出来。等等等等。
On the one hand, Java frees you up from many mundane and error-prone details of C++ coding. No more bounds errors, no more core dumps. Exceptions thrown point you to the exact line of code that erred, and are right 99% of the time. Objects print themselves intelligently on demand. Etc., etc.
另一方面，除了是一种语言，一个虚拟机，一个巨无霸的类库，一个安全模型，一个可移植的字节码格式，Java 还是一个宗教。邪教。所以你不能太相信对它太虔诚的人。想要招一个好的 Java 工程师是一项很有技术挑战的活。
On the other hand, in addition to being a language, a virtual machine, a huge set of class libraries, a security model, and a portable bytecode format, Java is a religion. So you can't trust anyone who loves it too much. It's a tricky business to hire good Java programmers.
但是总的来说，Java 是软件工程史上的一大进步。
But Java really has been a big step forward for software engineering in general.
从 C++ 到 Java 不只是语法上的改变。这是一种需要一段时间去好好体会的一种震撼性的世界观的转变。这有点像突然你被配了一个执行助理。你知道老总们为什么总是好像有时间去开会，总是知道公司现在运行的情况，总是写出很酷酷的文档吗? 老总们常常忘记其实他们不是一个人在战斗，他们都是两个全职的人，他们和他们的执行助理们。有一个执行助理把你从琐事中解救出来让你有时间去思考那些真的需要你去解决的问题; 没有的话你将不得不花一半的时间在那些无聊的世俗的事情上。切换到 Java 编程语言就把你变成了两个程序员 —— 一个处理那些你不需要关心的东西，另一个可以集中精力在问题本身上。这是一个很震人的改变，一个你应该很快就能习惯能喜欢上的改变。
Going from C++ to Java isn't just changing syntax. It's a shocking paradigm shift that takes a while to sink in. It's like suddenly getting your own Executive Assistant. You know how VPs always seem to have all this time to be in meetings, and know how the company's running, and write cool documents, and stuff like that? VPs tend to forget that they're actually TWO full-time people: their self and their EA. Having an EA frees you up to think about the problems you need to solve; not having one forces you to spend half your time on mundane tasks. Switching to Java turns you into two programmers — one taking care of all this stuff that you no longer have to think much about, and another one focused on the problem domain. It's a staggering difference, and one you can get used to in a real hurry.
就像 Jamie Zawinski (Netscape 牛人，开发 Mozilla 浏览器，好像学历是高中毕业?)在他著名的“Java 真烂(java sucks)”那篇文章里说的：“先说那些好东西：Java 没有 free() 函数。我必须一开始就承认，其他的东西都没什么了不起。(没有 free)是能让我原谅其他所有东西的特性，不管其他东西有多烂。讲完这一点后，我的文章里其他一切几乎都完全没有重要性了。”
As Jamie Zawinski said in his famous "java sucks" article: "First the good stuff: Java doesn't have free(). I have to admit right off that, after that, all else is gravy. That one point makes me able to forgive just about anything else, no matter how egregious. Given this one point, everything else in this document fades nearly into insignificance."
Jamie 的文章写在 1997 年，按 Java 年来算的话是很早以前了，跟他写这篇文章时比，Java 已经有很大的改善; 一些他抱怨的东西甚至已经被 fix 了。
Jamie's article was written in 1997, which in Java years is a long time ago, and Java has improved a lot since he wrote it; some of the things he complains about are even fixed now.
但是大多数还是没有被 fix。Java 作为一门语言还是有点烂。但就如 Jamie 指出的，Java“是今天为止最好的语言。我的意思是说，它是今天市面上那些烂得底儿掉地一堆语言比起来有那么一点能被我接受。”
Most of them aren't. Java does still kind of suck, as a language. But as Jamie points out, it's "the best language going today, which is to say, it's the marginally acceptable one among the set of complete bagbiting loser languages that we have to work with out here in the real world."
真的，你应该读读他那篇文章。
Really, you should read it.
Java 几乎每一方面都很好，除了它的语言本身，而这是 JWZ 抱怨的主要对象。但那是一个很大的抱怨。再好的库也救不了一个烂语言。相信我：你可能比我知道多得多的东西，但是我知道好兵救不了烂将。在 Geoworks 搞了五年汇编语言都会了我这个道理。
Java is truly wonderful along almost every dimension except for the language itself, which is mostly what JWZ was griping about. But that's a lot to gripe about. Libraries can only get you so far if your language sucks. Trust me: you may know many, many things better than I do, but I know that libraries can't really save a sucky language. Five years of assembly-language hell at Geoworks taught me that.
跟 C++ 比，Java 作为一个语言还过得去。好吧，别扯了，Java 要好很多。因为它有(内建)的字符串。哥们，你说一个没有内建的字符串的语言是人用的吗。
Compared to C++, Java as a language is about even. Well, scratch that, it's a lot better, because it has strings, oh man, how can you use a language with lousy string support.
但是 Java 跟 C++ 比少了一些好东西，比如(函数调用时)传引用，栈上的对象，typedef，宏，以及运算符重载。一些时不时地会很称手的东西。
But Java's missing some nice features from C++, such as pass-by-reference(-to-stack-object), typedefs, macros, and operator overloading. Stuff that comes in handy now and again.
哦，还有多重继承，我现在老了，反而挺欣赏了的多重继承。如果你认为我这个观点僵硬不灵活的家伙是多态教义很好的反例的话，我倒是可以给你举几个为什么你需要多态继承的好例子，或者至少像 Ruby 那样的 mixin 或者自动的派遣。下次问问我白龙马的事情。今天我要告诉你为什么 Java 的 interface 是个烂货。
Oh, and multiple inheritance, which now I've come to appreciate in my old age. If you think my Opinionated Elf was a good counterpoint to polymorphism dogma, I've got several brilliant examples of why you need multiple inheritance, or at least Ruby-style mixins or automatic delegation. Ask me about the Glowing Sword or Cloak of Thieving sometime. Interfaces suck.
几年前 Gosling 自己都说，如果一切都能重来的话，他不会搞出个 interface 的概念。
Gosling even said, a few years ago, that if he had to do it all over again, he wouldn't have used interfaces.
但是那正是 Java 的问题。当 James 说出那句话的时候，人们被雷到了。我甚至能感觉到那股雷劲儿，能感觉到 Sun 公司市场部和法务部的鸟人是多么想把 James 灭口，然后告诉大家他没那么说过。
But that's just exactly what the problem with Java is. When James said that, people were shocked. I could feel the shock waves, could feel the marketing and legal folks at Sun maneuvering to hush him up, brush it off, say it wasn't so.
Java 的问题就是人们都被那帮人搞的广告效应蒙住了眼。C++，Perl，任何流行语言都有这个问题。这是很严重的，因为如果没有一些说大话吹牛逼的广告，一个语言是不会流行起来的。所以如果一个语言的设计者说他的语言没有被设计得很完美的话，就是赶紧用麻醉枪射击这胡说八道的家伙并关闭会议的时候了。
The problem with Java is that people are blinded by the marketing hype. That's the problem with C++, with Perl, with any language that's popular, and it's a serious one, because languages can't become popular without hype. So if the language designer suggests innocently that the language might not have been designed perfectly, it's time to shoot the language designer full of horse tranquilizers and shut down the conference.
语言们需要放点儿卫星才能活，我只希望人们不要被卫星耀瞎了眼。
Languages need hype to survive; I just wish people didn't have to be blinded by it.
我学了面向对象编程， 我自己也对此大吹大擂。当我加入亚马逊时，我不能告诉你我有什么智慧或者经验，但我可以给你背诵出所有关于 OOP 的魔咒。多重继承是邪恶的，因为大家都这么说; 运算符重载是邪恶的，诸如此类。我甚至有点模糊地知道为什么是邪恶的，但实际上不知道。后来我明白了，这些都不邪恶，不是烂玩意儿，烂的是开发者，是我。我现在还是烂，但是希望每年都不烂一点起来。
I drank the OOP Kool-Aid, I regurgitated the hype myself. When I started at Amazon, I could recite for you all the incantations, psalms, and voodoo chants that I'd learned, all in lieu of intelligence or experience, the ones that told me Multiple Inheritance is Evil 'cuz Everyone Says So, and Operator Overloading Is Evil, and so on. I even vaguely sort of knew why, but not really. Since then I've come to realize that it's not MI that sucks, it's developers who suck. I sucked, and I still do, although hopefully less every year.
上礼拜我碰到一个来面试的，他告诉我多继承是邪恶的，因为，比如，你可以从头，胳膊，腿，躯干多重继承出一个人来。他既是对的，又是错的。那样的多继情形当然邪恶，但那都是因为他自己太邪恶了。那样继承出来的“东西”远远就能看见有多蠢，如果他还把这玩意儿弄进门来那就更邪恶了。
I had an interview candidate last week tell me that MI is Evil because, for instance, you could make a Human class that multiply-inherits from Head, Arm, Leg, and Torso. He was both right and wrong. That MI situation was evil, sure, but it was all him. Stupid from a distance, evil if he'd made it in through the front door.
不良开发者，占了这世上开发者的大多数，他们能用你扔给他们随便什么语言写出不良的代码。
Bad developers, who constitute the majority of all developers worldwide, can write bad code in any language you throw at them.
说了这些，还是得说回来，多继承不是请客吃饭那么轻松的事儿; mixin 看起来是更好的解决方案，但是还没人完美的解决这个问题。但我还是认为 Java 比 C++ 好，即使它没有多继。因为我知道不管我的出发点是多么好，某一天我还是会被一堆不懂怎么写好代码的人包围，让他们用 Java 比用 C++ 会带来更少的伤害。
That said, though, MI is no picnic; mixins seem to be a better solution, but nobody has solved the problem perfectly yet. But I'll still take Java over C++, even without MI, because I know that no matter how good my intentions are, I will at some point be surrounded by people who don't know how to code, and they will do far less damage with Java than with C++.
此外，Java 除了语言本身外还有老多其他的重要有用的东西。且 Java 语言本身也在进化，虽然像冰川一样慢，所以我们还是能看到希望。Java 正是我们应该在亚马逊推荐使用的语言。
Besides, there's way more to Java than the core language. And even the language is evolving, albeit glacially, so there's hope. It's what we should be using at Amazon.
你就是得小心点儿，因为和其他任何语言一样，你能很容易找出一堆人，他们很懂一门语言及其编程环境，但对品味，计算或者其他任何重要的东西却一无所知。
You just have to be careful, because as with any other language, you can easily find people who know a lot about the language environment, and very little about taste, computing, or anything else that's important.
当你有怀疑时，还是雇那种会好几门语言的 Java 程序员，那种厌憎 J2EE/EJB 之类松松跨跨的所谓框架的，那种使用 Emacs 的。这都是一些实战经验。
When in doubt, hire Java programmers who are polyglots, who detest large spongy frameworks like J2EE and EJB, and who use Emacs. All good rules of thumb.
Perl，怎么说呢?
Perl. Where to start?
Perl 是个老朋友。老老朋友。我开始写 Perl 代码的时候，可能是 1995 年。而它为我很好的服务了差不多 10 年的时间。
Perl is an old friend. Perl and I go way back. I started writing Perl stuff in maybe 1995, and it's served me well for nearly a decade.
它就像你骑了十万二十万英里的老自行车，你心里永远有一块地方装着它，虽然现在你已经换了一辆更加现代化的只有五磅重的自行车，而且这一辆也不像老的那辆顶得你屁眼疼了。
It's like that old bicycle you've put 100k or 200k miles on, and you'll always have a warm fuzzy spot for it, even though you've since moved on to a more modern bike that weighs 5 lbs and doesn't make your ass hurt so much.
Perl 受欢迎原因有仨：
1. 用 Perl 你很快就能搞定你的问题。而这是最终的衡量标准。
1. Perl 有世上最好的市场推广。你可以写一本介绍他们市场推广有多绝的书。Sun 公司砸大笔钱给 Java 推市场，Perl 在受欢迎程度来说能跟 Java 齐头并进，但 Perl 纯粹是依靠 Larry Wall 和他那帮哥们的三寸不烂之舌做市场。哈佛商学院的人应该去研究 Perl 的市场是怎么做出来的。真的让人瞠目结舌。
1. 直到差不多，呃，现在，Perl 没有真正的竞争者。
Perl is popular for three reasons:
1. You can <em>get stuff done</em> really fast in Perl, which is what really matters, in the end.
1. Perl has the best marketing in the world. You could write a book about how brilliant their marketing is. Sun has marketed Java with money, and Perl is almost keeping up, popularity-wise, purely on the on sheer marketing brilliance of Larry Wall and his buddies. Folks at Harvard Business School should study Perl's marketing. It's astonishing.
1. Until roughly, oh, <em>now</em>, it had no real competitors.
有比 Perl “好”的语言。操，有很多比 Perl 好的语言，如果你定义“好”为“不是给疯子用的”的话。Lisp, Smalltalk, Python，妈呀，我可能可以列出二三十种比 Perl “好”的语言。从这些语言不像这个夏天在台湾街头爆了肚皮的抹香鲸这个角度来说。鲸鱼肠子到处都是，汽车上，机车上，行人身上。这就是 Perl。让人着迷，真的。
There are "better" languages than Perl — hell, there are lots of them, if you define "better" as "not being insane". Lisp, Smalltalk, Python, gosh, I could probably name 20 or 30 languages that are "better" than Perl, inasmuch as they don't look like that Sperm Whale that exploded in the streets of Taiwan over the summer. Whale guts everywhere, covering cars, motorcycles, pedestrians. That's Perl. It's charming, really.
但是 Perl 有很多很多好的特性，直到最近，都是其他语言没有的。它们弥补了 Perl 肠子在外的不足。你可以从爆了肚皮的鲸鱼可以做很多有用的东西出来，比如香水。这很有用。Perl 也是这样。
But Perl has many, many things going for it that, until recently, no other language had, and they compensated for its exo-intestinal qualities. You can make all sorts of useful things out of exploded whale, including perfume. It's quite useful. And so is Perl.
当其他的那些语言(尤其是 Lisp 和 Smalltalk)都想假装操作系统并不存在，列表(Lisp 的)和对象(Smalltalk 的)就是把屎搞出来的唯一存在，Perl 却走了截然相反的路子。Larry 说：Unix 和字符串是搞出屎来的唯一存在。
While all those other languages (Lisp and Smalltalk being particularly noteworthy offenders) tried to pretend that operating systems don't exist, and that lists (for Lisp) or objects (for Smalltalk) are the be-all, end-all of getting shit done, Perl did exactly the opposite. Larry said: Unix and string processing are the be-all, end-all of getting shit done.
对很多任务来说，他绝对是正确的。所以 Perl 绝对是 Unix 系统管理和字符串处理的史上最强语言，除了一个，刚出来的一个，从哥斯拉(电影哥斯拉看过没)之地出来的一个。我一会儿会讲到那一个。
And for many tasks, he was absolutely right. So Perl is better at Unix integration and string processing than any language on the planet, save one, and that one only arrived on the scene recently, from the land of Godzilla. I'll get to that one later.
可惜，Larry 太太太太在意 Unix 系统管理和字符串处理以致他压根忘了列表和对象，等他明白过来想改正的时候已经晚了。实际上，在 Perl 早期的…好吧，对鲸鱼肠子我实在不想用“设计”这个词，就说生命周期中吧，他犯的几个关键错误让把列表和对象加进来变得如此尴尬，以致 Perl 已经进化成一个真正的 Rube Goldberg 机器，至少当你想在 Perl 里用列表和对象的时候。(Rube Goldberg 是一漫画家，常画一些很复杂的机器，但只完成简单的工作，比如一个小球滚过很多关卡，最后把门打开。译者注)。
Sadly, Larry focused sooooo hard on Unix integration and string processing that he totally forgot about lists and objects until it was far too late to implement them properly. In fact, a few key mistakes he made early on in Perl's... well, I hesitate to use the word "design" for whale guts, but let's call it Perl's "lifecycle" — those mistakes made it so hard to do lists and objects correctly that Perl has evolved into a genuine Rube Goldberg machine, at least if you want to use lists or objects.
列表和对象也他妈的是很重要的，Larry！(farging 应该是作者不想说 fucking 那么直白，译者注)
Lists and objects are pretty farging important too, Larry!
Perl 没法表达列表因为 Larry 一早犯了一个悲剧性的愚蠢的错误，把列表全抹平。于是(1, 2, (3, 4))魔术般地变成(1, 2, 3, 4)。不是说你会想让它这样工作，而是 Larry 刚好那天在搞一个这样会更方便的问题。于是 Perl 的数据结构从此就变得爆炸了的鲸鱼了。
Perl can't do lists because Larry made the tragically stupid decision early on to flatten them automatically. So (1, 2, (3, 4)) magically becomes (1, 2, 3, 4). Not that you ever want it to work this way. But Larry happened to be working on some problem for which it was convenient on that particular day, and Perl's data structures have been pure exploded whale ever since.
今天你看 Perl 的书，小教程或 PPT 的时候，不花三分之一的时间在“引用”上是不可能的。这就是 Larry 可怜的，坏了的，Goldberg (漫画家，想起来没? 译者注)式的对他那抹平列表的疯狂错误的解决方案。但是 Perl 的市场宣传做得那么难以置信地好以致它让你觉得这是你身上发生过的最好的东西。你可以对任何东西取它的引用。这很有趣！闻起来也很香（说肠子呢，译者注，呵呵）！
Now you can't read a book or tutorial or PowerPoint on Perl without spending at least a third of your time learning about "references", which are Larry's pathetic, broken, Goldbergian fix for his list-flattening insanity. But Perl's marketing is so incredibly good that it makes you feel as if references are the best thing that ever happened to you. You can take a reference to anything! It's fun! Smells good, too!
Perl 不能支持面向对象编程因为 Larry 压根不相信这玩意儿。这可能没什么大不了; 我也不是很确定我是不是信这个 OOP。但是那么为啥他又要试着把对象加进 Perl 呢? Perl 的面向对象是个半成品，且在 Perl 社区里没多少人重视。它就是不像字符串处理或 Unix 集成那样充满灵感。
Perl can't do objects because Larry never reeeeally believed in them. Maybe that's OK; I'm still not quite sure if I believe in them either. But then why did he try adding them? Perl's OO is a halfhearted add-on that never caught on with the Perl community. It's just not as inspired as the string-processing or Unix integration stuff.
当然了，Perl 还有其他很多怪怪的特性。比如它的“上下文”，这是 Larry 要有 N 个变量名字空间的喜剧式决定的一个恐怖片式的产物。这些空间由 sigil 来区分(就是 Perl 里变量名前面的‘$’，‘@’，‘%’字符)，看着像是从 shell 脚本里拷贝来的。在 Perl 里，所有的运算符，所有的函数，所有的操作其行为都是六取一的随机的，取决于当前的“上下文”。没有一些规则或助记法能帮你搞定这些特定操作在特定上下文里的特定行为。你得把它们全记在脑子里。
And of course, Perl has plenty of other crackpot design features. Take its "contexts", for instance, which are a horrid outgrowth of Larry's comical decision to have N variable namespaces, dereferenced by sigils, which he sort of copied from shell-script. In Perl, every operator, every function, every operation in the language behaves randomly in one of six different ways, depending on the current "context". There are no rules or heuristics governing how a particular operation will behave in a given context. You just have to commit it all to memory.
想要个例子? 这儿有一个：在一个值量(scalar，对应于 vector，向量)上下文里对一个哈希取值你得到一个字符串，里面是个分数，分子是目前已分配的键，分母是总共有多少个桶。鲸鱼肠子，我告诉你。
Need an example? Here's one: accessing a hash in a scalar context gives you a string containing a fraction whose numerator is the number of allocated keys, and the denominator is the number of buckets. Whale guts, I'm telling you.
但就像我说的—直到最近，没啥能像 Perl 那样把屎搞定。
Like I said, though — until recently, nothing could get the job done like Perl could.
每过 15 年左右，一门语言就会被更好的代替。C 被 C++ 代替，至少对大应用开发而又需要性能和数据类型的人们来说。C++ 被 Java 代替，而 Java 无疑在 7 年后又会被更好的东西代替—好吧，我说的是完全代替 C++ 的 7 年后，这到目前为止还没有发生，主要是因为微软能在 Java 霸占桌面系统之前狙击它。但是在服务器上的应用而言，C++ 的阵地已经慢慢让给 Java 了。
Every 15 years or so, languages are replaced with better ones. C was replaced by C++, at least for large-scale application development by people who needed performance but desperately wanted data types too. C++ is being replaced by Java, and Java will doubtless be replaced with something better in seven years — well, seven years after it finishes replacing C++, which evidently hasn't fully happened yet, mostly because Microsoft was able to stall it before it became ubiquitous on the desktop. But for server-side applications, C++ is basically on its way out.
Perl 有一天也会消逝。那是因为一门新的语言 Ruby 刚刚终于被翻译成英语了。没错，它是在日本发明的，这么多地儿，没想到日本人搞出来了，还以为他们只是硬件和制造上占有名气，而不是他们的软件业，所以大家都跟你一样惊奇。为什么呢，大家可能都在想。但是我认为这都是跟打字有关。我根本不能想象他们以前能打字打得足够快，英文字母只有 26 个，他们却有上万个字。但是 Emacs 几年前支持多字节字符了，所以我猜他们现在打字速度他妈的快多了。(所以能搞出 Ruby 来了，译者猜作者是这个意思) (是的，他们也用 Emacs —— 事实上日本人负责了 Emacs 多字节支持的大部工作，而且搞得坚不可摧。)
Perl will be gone soon, too. That's because a new language called Ruby has finally been translated into English. Yep, it was invented in Japan, of all places — everyone else was as surprised as you are, since Japan's known for its hardware and manufacturing, but not for its software development. Why, is anyone's guess, but I'm thinking it's the whole typing thing; I just can't imagine they were able to type fast enough before, what with having an alphabet with ten thousand characters in it. But Emacs got multibyte support a few years ago, so I can imagine they're pretty dang fast with it now. (And yes, they use Emacs — in fact Japanese folks did the majority of the Mule [multibyte] support for Emacs, and it's rock-solid.)
不管怎么样，Ruby 从 Perl 那里偷师了所有的好东西; 实际上，Matz, Ruby 的作者(Yukihiro Matsumoto，如果我没记错的话，但是他外号“Matz”)，觉得他从 Perl 那里偷的有点太多了，他的鞋上也粘了些鲸鱼肠子。但是只是一丢丢。
Anyway, Ruby stole everything good from Perl; in fact, Matz, Ruby's author (Yukihiro Matsumoto, if I recall correctly, but he goes by "Matz"), feels he may have stolen a little too much from Perl, and got some whale guts on his shoes. But only a little.
最重要的是，Ruby 拿来了 Perl 的串处理和 Unix 集成，一点没改，就是说语法都是一样的，于是乎啥也不说了，你就拥有了 Perl 最好的那部分。这是个不错的开局，特别是如果你不把 Perl 剩下的东西也拿进来的话。
For the most part, Ruby took Perl's string processing and Unix integration as-is, meaning the syntax is identical, and so right there, before anything else happens, you already have the Best of Perl. And that's a great start, especially if you don't take the Rest of Perl.
但是之后 Matz 还从 Lisp 那里拿来的最好的列表处理，Smalltalk 和其他语言那里拿来了最好的面向对象，CLU 那里拿来了最好的迭代器，以及基本上是每个人每个事的最好的东西。
But then Matz took the best of list processing from Lisp, and the best of OO from Smalltalk and other languages, and the best of iterators from CLU, and pretty much the best of everything from everyone.
而他让这些东西全部都跑起来，跑得那么顺，你都不会注意到这些东西在那儿。我比其他任何语言都快就学会了 Ruby，我总共会三十到四十门语言; 而我花了大概三天时间就能用 Ruby 比 Perl 还流畅地工作了，当了八年的 Perl 黑客后。这些东西是这么的和谐你都能自己猜它们是怎么工作的，而且大多数时候你都能猜对。漂亮。有趣。靠谱。
And he somehow made it all work together so well that you don't even notice that it has all that stuff. I learned Ruby faster than any other language, out of maybe 30 or 40 total; it took me about 3 days before I was more comfortable using Ruby than I was in Perl, after eight years of Perl hacking. It's so consistent that you start being able to guess how things will work, and you're right most of the time. It's beautiful. And fun. And practical.
如果把语言比成自行车，那么 AWK 就是一辆粉系的儿童自行车，前面有个白色小框，还插块小旗，Perl 就是沙滩车(还记得那有多酷吧? 唉。)，而 Ruby 则是一辆七千五美金的钛合金山地自行车。从 Perl 飞跃到 Ruby 意义不下于从 C++ 到 Java 的飞跃。却没有任何缺陷，因为 Ruby 几乎是 Perl 功能的一个超集，而 Java 却拿掉了一些人们想要的东西，且没有真正的提供一个替代品。
If languages are bicycles, then Awk is a pink kiddie bike with a white basket and streamers coming off the handlebars, Perl is a beach cruiser (remember how cool they were? Gosh.) and Ruby is a $7,500 titanium mountain bike. The leap from Perl to Ruby is as significant as the leap from C++ to Java, but without any of the downsides, because Ruby's essentially a proper superset of Perl's functionality, whereas Java took some things away that people missed, and didn't offer real replacements for them.
下次我会写更多关于 Ruby 的东西。我先需要灵感。去读读 Lucky Stiff 的(poignant) guide to Ruby 吧。那本书是一本有灵感的书。真的，读一下。超赞。我不理解产生它的那种头脑，但它很有趣，很犀利，且全是关于 Ruby 的。好像。你会看到的。
I'll write more about Ruby sometime. I need to be inspired first. Read Why the Lucky Stiff's (poignant) guide to Ruby. That is an inspired piece of work. Really. Read it. It's amazing. I don't understand the kind of mind that could produce it, but it's funny, and poignant, and all about Ruby. Sort of. You'll see.
啊，Python 怎么说呢，一个不错的语言，这么多年来一直旁边在等待它的机会? Python 社区很长时间以来是那些勇敢地吞下红药片从 Perl 骇客帝国中醒来的人的避难营。
Well gosh, what about Python, a nice language that has patiently been waiting in the wings for all these years? The Python community has long been the refuge for folks who finally took the red pill and woke up from the Perl Matrix.
啊，有点像 Smalltalk 的人们，他们永远在等待替代 C++，没想到半路杀出 Java 一下把它们操翻了，漂亮地，永久地。哎哟。Ruby 正在对 Python 做着同样的事，现在，今天。可能会在一夜之间吧。
Well, they're just like the Smalltalk folks, who waited forever to replace C++, and then Java came along and screwed them royally, and permanently. Oops. Ruby's doing exactly that to Python, right now, today. Practically overnight.
Python 本来可以统治世界，可惜它有两个致命缺陷：空格，和冷淡。
Python would have taken over the world, but it has two fatal flaws: the whitespace thing, and the permafrost thing.
空格很简单，就是说 Python 是用缩进来表达代码块之间的嵌套。它强制你必须按一定格式把所有的东西缩进，他们这样做是为了让所有人写的代码看上去一样。不料蛮多程序员讨厌这点，因为他们觉得自己的自由被拿走了; 感觉就像 Python 侵犯了宪法赋予他们的可以随便缩进格式和全写在一行上的权利。
The whitespace thing is simply that Python uses indentation to determine block nesting. It forces you to indent everything a certain way, and they do this so that everyone's code will look the same. A surprising number of programmers hate this, because it feels to them like their freedom is being taken away; it feels as if Python is trampling their constitutional right to use shotgun formatting and obfuscated one-liners.3
Python 的作者，Guido Van Rossum，也在早期犯过一些很傻的技术错误 —— 没有像 Larry 的失误那么严重，但是还是有几个。比如，最早 Python 没有字面变量范围，但它同时也没有动态变量范围，而动态变量范围可能会有它一些问题，但它还是有用的。Python 却没有这些，只有全局的和本地(函数)的两种范围。所以即使它是一个真正的 OO 系统，类甚至不能访问它们自己的动态成员变量。你必须给成员函数传“self”参数，一大堆 self 参数很快就会把你搞疯掉，即使你不在意空格问题。
Python's author, Guido Van Rossum, also made some boneheaded technical blunders early on — none quite as extravagant as Larry's blunders, but a few were real doozies nonetheless. For instance, Python originally had no lexical scoping. But it didn't have dynamic scoping either, and dynamic scoping may have its share of problems, but it at least sort of works. Python had NOTHING except for global and local (function) scope, so even though it had a "real" OO system, classes couldn't even access their own damned instance variables. You have to pass a "self" parameter to EVERY instance method and then get to your instance data by accessing it through self. So everything in Python is self, selfself, selfselfself, selfSELFselfSELF__SELF__, and it drives you frigging nuts, even if you don't mind the whitespace thing.
等等之类。
Etc.
但在我看来，Python 不行其实是因为冷淡。这阻止了它成为首选脚本语言，或者首选一切语言。靠，人们现在还在用 Tcl 作嵌入解释执行器，虽然 Python 比 Tcl 好得不要太多 —— 除了，我说，这个冷淡问题。
But in my opinion, it's really the frost thing that killed Python, and has prevented it from ever achieving its wish to be the premier scripting language, or the premier anything language, for that matter. Heck, people still use Tcl as an embedded interpreter, even though Python is far superior to Tcl in every conceivable way — except, that is, for the frost thing.
（此处开始我不知所云。呵呵，这样吧，把原文贴在最后面。译者注）
What’s the frost thing, you ask? Well, I used to have a lot of exceptionally mean stuff written here, but since Python’s actually quite pleasant to work with (if you can overlook its warts)， I no longer think it’s such a great idea to bash on Pythonistas。The “frost thing” is just that they used to have a tendency to be a bit, well, frosty。Why?
Because they were so tired of hearing about the whitespace thing！
I think that’s why Python never reached Perl’s level of popularity， but maybe I’m just imagining things。
这才是我真正想给亚马逊开发者杂志写的文章。或者至少是这样的。出于某些原因，我的真感情好像只有在我凌晨三点到六点失眠的时候都会流露。该睡觉了！我下个会议再过两小时就开始了。
That was the ADJ article I really wanted to write。Or at least something like it。For some reason, though, my true feelings only seem to come out during insomniac attacks between 3am and 6am。Time for bed！2 hours ’til my next meeting。
注1，Eric 告诉我当时几乎全是 Jamie Zawinski，当他们在 Lucid 工作的时候。
注2，我写了这个之后很多人告诉我 Paul Graham 是用 VI 的，想不到。
注3，为了有据可查，我个人根本不介意空格问题。我认为因为这个而不喜欢 Python 是很傻的。我只是说有一堆比例让人惊奇的其他工程师讨厌空格问题。
注：本文转自：王卫Oneway的专栏 的 http://blog.csdn.net/oneway102/article/details/6086741
我尽量用平和一点的口吻跟你说说关于程序员的那点事儿。我在一个叫摩托罗拉的公司干过，那地方有 50% 的人整天干的事情就是催另外 25% 的人没完没了的解剩下那 25% 的人造成的 bug。我是个程序员，每天敲敲打打，哪天电脑崩溃了你会发现我这辈子啥都没留下。大多数人甚至都没有想过我们是怎么把手机捣鼓出来的，包括是是否人手一套乐高的家庭套装工具。
我那可爱的岳父岳母在向自己的亲戚朋友们介绍我的时候，总是用一种充满自豪的口吻轻描淡写的说，他在摩托罗拉上班（我离开摩托罗拉以后他们会说，他以前在摩托罗拉上班）。然后那帮倒霉催的亲戚朋友们就会一种既内行又套近乎的口气说，你能埋导偏伊熟几啵？...我内诺几亚屏幕不咸你能修啵？
类似的事情在我刚毕业的时候也会经常发生，人们一听到邮电大学就会忧国忧民的叹一口气：现在这邮局不景气啊，快递也都是体力活儿...
今天下午我的我同事同客户见面，我们花了一个多小时也没法很好的解释为什么我们的客户端在收到一个完整的图片（虽然它超时了）后又再次发生相同的请求，并且在 3 秒钟又收到应答之后还是没法让它显示出来。“有关部门”可以“不解释”，但程序员一点儿都不能含糊。
然后另外一个同事给我发了一个链接，关于大洋彼岸一个悲催的程序员阿什顿的故事（http://www.zhuoqun.NET/html/y2010/1565.html）。“他写过的任何一行代码都没有运行过。过去两年内他做的任何一件事情都没有对世界产生过什么影响。”
尽管我从内心里明白这个世界上还有很多人活得比我悲惨，但我还是忍不住的悲从中来，几乎逆流。
我每天努力编写代码的间隙，会上水木清华的笑话版放松一下，或是看看不露点的美女图片解解乏。我也看一些业界的新闻，那些狗日的天天把“创新/用户体验/敏捷开发”等等挂在嘴边，却从来没为这个世界贡献过哪怕一行代码。我还用免费的在线翻译软件，为的是给代码中的每一个变量都起一个地道的英文名字，至少让印度同事们看上去可读性强一些。
我有个师弟，因为工作的关系他居然不得不在晚上编程。在他失恋的那天晚上我们一起喝酒，他泪流满面的对我说，其实他觉得最悲痛的事情是自己连坐台的小姐都不如，她们还可以赚外快，而这却是我的生活。
上个月我和几个校友聚餐，其中一个 26 岁的小伙子一直没怎么吃，末了他十分沉重的说，怕自己这辈子就只能当个程序员了...编程年龄最长为 12 年的我们充满羞愧地以遍历的形式相互对视了一圈；包间的空气里充满了悲怆和绝望。
我努力回忆看过的每一部有程序员出现的片子，发现这些人不是前景就是背景，总是处于焦外。有时候他们在黑掉一些系统之后会有有幸运的正脸出现，但很快就会以一种飞来横祸（例如被鼠标线勒住或滑落的电脑砸到）的方式死掉，连像主角那样中枪或被爆炸都不配。他们没有名表名车，没有女人和性，最多养一只看上去和本人一样非主流的宠物蜥蜴。
那晚上我做了个梦，梦见这个世界有一个总的电源开关，邪恶的章鱼博士用手（他有八只手）恶狠狠的掐掉了开关，然后我干了一辈子什么都没留下。
我老婆每天下班都会跟我讲她们办公室好玩的事情，例如 A 和 B 闹矛盾打了起来然后 B 就把 A 全年的工资单群发给所有同事...我也跟她说我们好玩的事情：A 写的代码把互斥和信号量弄混淆了，导致执行的结果总是时对时错，B 给他做 code review 之后把互斥和信号量都去掉了，发现根本不需要这些东西也能得到正确的结果，因为所有的一切都运行在同一个线程里...
如你所知，这个世界上有两种人永远没法理解程序员的幽默和笑点，一种是不会编程的人，一种是没有幽默感的人。就如同狗日的 KJ 说过的，这个世界有两种人，一种是程序员，一种不是程序员。
非程序员可以要求程序员提高点文化素质和举止修养，但程序员却不能要求非程序员们在讨论大事小事的时候多一点理性的态度和客观科学的精神。这也是我和我老婆的家庭生活原则。
我认识的朋友中有做编剧，也有画画的，这两个倒霉的家伙的作品从来没有在这个世界上以一种公开的方式被人看过。但是所有的人都充满耐心和爱心的安慰他们，没关系，总有那么一天你会进军好莱坞，或是在佳士得拍卖场的。可是这帮势利眼们每次见到我都会用一种不出所料的心态，以一种关切惋惜的口吻说，你怎么还在编程啊？他们从来不会安慰我说，总有一天你会成为比尔盖茨的；哪怕是王江民也行，尽管他已经英年早逝。
哲人们说过，是你去迎合这个世界，而不是这个世界来迎合你。我为了迎合这个狗日的世界，不得不在编程之余去做一些事情，目的只是让自己成为一个不是那么普通的程序员而已。世界可能是你的，也可能是他的，但不是程序员的，尽管这个世界凡是插电的东西里基本都跑着匿名程序员们一行一行写出来的代码。
我得看一些大部头，不是《鬼吹灯》，至少得是《明朝那些事儿》，这样他们在谈论《万历十五年》的时候我至少能插得上话，偶尔也能谈笑风生。我最近看的一本书是《高级迷信》，我敢打赌不管你是不是程序员你都不一定看得懂。
我买了单反还有镜头，虽然都是二手的，但我和所有烧不起器材的人们一样，坚信重要的不是镜头而是镜头后边的这颗脑袋。
我还听摇滚，虽然他们的 iPod 里大多数时候放的都是些小资小清新。至少我也有自己的品味。
我的那些程序员同事和朋友们，有的去登山远足，有的学调酒（因为没法学会调姑娘），还有的自己和自己玩 SM。因为程序员们对于这个复杂的世界来说都属于足够简单的那一类人，性格简单，爱好简单，甚至行为也简单。他们有时只是想引起身边的人对自己的程序员朋友或程序员家人一点足够的重视，就像你养的小狗那样。
有时我也把一些编程的心得写出来，插入一些故弄玄虚的废话，然后发到博客里。我从来不知道自己写的代码什么时候在哪些地方运行着，但我却可以清楚的看到多少人访问过我的博客（尽管有些人只是误点），还有多少人留言（尽管大部分都是“顶”或“狗屁”一类的狗屁）。但得感谢他们，深夜里我抚摸屏幕上这些莫名的访客记录，感觉自己那灰色的二进制程序员生活因此而照进了一丝圣光，看上去变成了 8 进制：赤橙红黄绿蓝紫，还有白。
对于程序员来说，一个最好的世界，就是我们可以心无旁骛编程的世界，是我们可以骄傲的高呼“我要编一辈子程”的世界，是非程序员的那些人像追捧 iPad 一样奉程序员为明星和教主的世界。
注： 本文转自：https://www.douban.com/group/topic/16793315/，文章出自《别闹了，费曼先生》，作者费曼为一理论物理学家，诺贝尔物理学奖获得者。