The Hundred-Year Language
April 2003 (This essay is derived from a keynote talk at PyCon 2003.) It's hard to predict what life will be like in a hundred years.
2003 年 4 月（本文摘自 PyCon 2003 的主题演讲。）很难预测一百年后的生活会是什么样子。
There are only a few things we can say with certainty.
我们可以肯定地说的只有几件事。
We know that everyone will drive flying cars, that zoning laws will be relaxed to allow buildings hundreds of stories tall, that it will be dark most of the time, and that women will all be trained in the martial arts.
我们知道，每个人都会驾驶飞行汽车，分区法将放宽，允许建筑物达到数百层楼高，大部分时间都是黑暗的，女性都将接受武术训练。
Here I want to zoom in on one detail of this picture.
这里我想放大这张图片的一个细节。
What kind of programming language will they use to write the software controlling those flying cars?
他们将使用什么样的编程语言来编写控制这些飞行汽车的软件？
This is worth thinking about not so much because we'll actually get to use these languages as because, if we're lucky, we'll use languages on the path from this point to that.
这值得思考，与其说是因为我们实际上会使用这些语言，不如说是因为，如果幸运的话，我们将在从这一点到另一点的路径上使用语言。
I think that, like species, languages will form evolutionary trees, with dead-ends branching off all over.
我认为，就像物种一样，语言将形成进化树，并在各处分支出死胡同。
We can see this
我们可以看到这个
happening already.
已经发生了。
Cobol, for all its sometime popularity, does not seem to have any intellectual descendants.
尽管科博尔一度很受欢迎，但它似乎没有任何知识分子的后裔。
It is an evolutionary dead-end-- a Neanderthal language.
这是一种进化的死胡同——一种尼安德特人的语言。
I predict a similar fate for Java.
我预测 Java 也会有类似的命运。
People sometimes send me mail saying, "How can you say that Java won't turn out to be a successful language?
有时人们会给我发邮件说：“你怎么能说 Java 不会成为一种成功的语言呢？
It's already a successful language." And I admit that it is, if you measure success by shelf space taken up by books on it
它已经是一种成功的语言了。”我承认确实如此，如果你用书籍所占据的书架空间来衡量成功的话
(particularly individual books on it), or by the number of undergrads who believe they have to learn it to get a job.
（特别是有关这方面的个别书籍），或者认为自己必须学习它才能找到工作的本科生数量。
When I say Java won't turn out to be a successful language, I mean something more specific: that Java will turn out to be an evolutionary dead-end, like Cobol.
当我说 Java 不会成为一种成功的语言时，我的意思是更具体的：Java 将成为一个进化的死胡同，就像 Cobol 一样。
This is just a guess.
这只是一个猜测。
I may be wrong.
我可能错了。
My point here is not to dis Java, but to raise the issue of evolutionary trees and get people asking, where on the tree is language X?
我在这里的目的不是要批评 Java，而是要提出进化树的问题，让人们问，X 语言在进化树上的哪个位置？
The reason to ask this question isn't just so that our ghosts can say, in a hundred years, I told you so.
问这个问题的原因不仅仅是为了让我们的鬼魂可以说，一百年后，我告诉过你了。
It's because staying close to the main branches is a useful heuristic for finding languages that will be good to program in now.
这是因为靠近主要分支对于寻找现在适合编程的语言是一种有用的启发式方法。
At any given time, you're probably happiest on the main branches of an evolutionary tree.
在任何给定的时间，你可能在进化树的主要分支上最快乐。
Even when there were still plenty of Neanderthals, it must have sucked to be one.
即使当时还有大量尼安德特人，成为其中一员也一定很糟糕。
The
的
Cro-Magnons would have been constantly coming over and beating you up and stealing your food.
克鲁马努人会不断过来殴打你并偷走你的食物。
The reason I want to know what languages will be like in a hundred years is so that I know what branch of the tree to bet on now.
我想知道一百年后语言会是什么样子，这样我就知道现在应该押注于树的哪个分支。
The evolution of languages differs from the evolution of species because branches can converge.
语言的进化与物种的进化不同，因为分支可以聚合。
The Fortran branch, for example, seems to be merging with the descendants of Algol.
例如，Fortran 分支似乎正在与 Algol 的后代合并。
In theory this is possible for species too, but it's
理论上这对于物种来说也是可能的，但它是
not likely to have happened to any bigger than a cell.
这种情况不太可能发生在比细胞更大的细胞上。
Convergence is more likely for languages partly because the space of possibilities is smaller, and partly because mutations are not random.
语言更可能趋同，部分原因是可能性的空间较小，部分原因是突变不是随机的。
Language designers deliberately incorporate ideas from other languages.
语言设计者有意融入其他语言的思想。
It's especially useful for language designers to think about where the evolution of programming languages is likely to lead, because they can steer accordingly.
对于语言设计者来说，思考编程语言的发展可能会走向何方尤其有用，因为他们可以进行相应的引导。
In that case, "stay on a main branch" becomes more than a way to choose a good language.
在这种情况下，“留在主分支上”就不仅仅是选择一门好语言的方法了。
It becomes a heuristic for making the right decisions about language design.
它成为做出有关语言设计的正确决策的启发式方法。
Any programming language can be divided into two parts: some set of fundamental operators that play the role of axioms, and the rest of the language, which could in principle be written in terms of these fundamental operators.
任何编程语言都可以分为两部分：一些起到公理作用的基本运算符集，以及原则上可以用这些基本运算符来编写的语言的其余部分。
I think the fundamental operators are the most important factor in a
我认为基本运算符是最重要的因素
language's long term survival.
语言的长期生存。
The rest you can change.
其余的你可以改变。
It's like the rule that in buying a house you should consider location first of all.
就像买房子首先要考虑地段一样。
Everything else you can fix later, but you can't fix the location.
其他一切你可以稍后修复，但你无法修复位置。
I think it's important not just that the axioms be well chosen, but that there be few of them.
我认为重要的不仅仅是公理的选择，而且公理的数量要少。
Mathematicians have always felt this way about axioms-- the fewer, the better-- and I think they're
数学家们一直对公理有这样的感觉——越少越好——而且我认为他们是
onto something.
到某物上。
At the very least, it has to be a useful exercise to look closely at the core of a language to see if there are any axioms that could be weeded out.
至少，仔细观察语言的核心，看看是否有任何可以被淘汰的公理，必须是一个有用的练习。
I've found in my long career as a slob that cruft breeds cruft, and I've seen this happen in software as well as under beds and in the corners of rooms.
在我漫长的职业生涯中，我发现自己是个邋遢的人，肮脏的东西会滋生肮脏的东西，我在软件中、床下和房间的角落里都看到过这种情况。
I have a hunch that the main branches of the evolutionary tree pass through the languages
我有预感，进化树的主要分支会穿过语言
that have the smallest, cleanest cores.
拥有最小、最干净的核心。
The more of a language you can write in itself, the better.
你能用自己编写的语言越多越好。
Of course, I'm making a big assumption in even asking what programming languages will be like in a hundred years.
当然，即使问一百年后编程语言会是什么样子，我也是在做出一个很大的假设。
Will we even be writing programs in a hundred years?
一百年后我们还会编写程序吗？
Won't we just tell computers what we want them to do?
我们难道不应该告诉计算机我们希望它们做什么吗？
There hasn't been a lot of progress in that department so far.
到目前为止，该部门还没有取得很大进展。
My guess is that a hundred years from now people will
我的猜测是一百年后人们会
still tell computers what to do using programs we would recognize as such.
仍然使用我们能够识别的程序告诉计算机做什么。
There may be tasks that we solve now by writing programs and which in a hundred years you won't have to write programs to solve, but I think there will still be a good deal of programming of the type that we do today.
也许有些任务我们现在通过编写程序来解决，一百年后你将不需要编写程序来解决这些任务，但我认为仍然会有大量我们今天所做的类型的编程。
It may seem presumptuous to think anyone can predict what any technology will look like in a hundred years.
认为任何人都可以预测一百年后任何技术会是什么样子的想法似乎有些自大。
But
但是
remember that we already have almost fifty years of history behind us.
请记住，我们已经有近五十年的历史了。
Looking forward a hundred years is a graspable idea when we consider how slowly languages have evolved in the past fifty.
当我们考虑到语言在过去五十年的发展是多么缓慢时，展望一百年是一个可以理解的想法。
Languages evolve slowly because they're not really technologies.
语言发展缓慢，因为它们并不是真正的技术。
Languages are notation.
语言是符号。
A program is a formal description of the problem you want a computer to solve for you.
程序是对您希望计算机为您解决的问题的正式描述。
So the rate of evolution in programming languages is more like the
所以编程语言的进化速度更像是
rate of evolution in mathematical notation than, say, transportation or communications.
用数学符号表示的进化速度比交通或通讯的进化速度快。
Mathematical notation does evolve, but not with the giant leaps you see in technology.
数学符号确实在发展，但并没有随着技术的巨大飞跃而发展。
Whatever computers are made of in a hundred years, it seems safe to predict they will be much faster than they are now.
无论一百年后计算机是由什么构成的，似乎可以肯定地预测它们的速度将比现在快得多。
If Moore's Law continues to put out, they will be 74 quintillion (73,786,976,294,838,206,464) times faster.
如果摩尔定律继续发挥作用，它们的速度将提高 74 万亿 (73,786,976,294,838,206,464) 倍。
That's kind of
那是一种
hard to imagine.
很难想象。
And indeed, the most likely prediction in the speed department may be that Moore's Law will stop working.
事实上，速度部门最有可能的预测可能是摩尔定律将不再起作用。
Anything that is supposed to double every eighteen months seems likely to run up against some kind of fundamental limit eventually.
任何预计每十八个月翻一番的事情似乎最终都可能会遇到某种基本限制。
But I have no trouble believing that computers will be very much faster.
但我毫不犹豫地相信计算机会更快。
Even if they only end up being a paltry million times faster, that should change the ground rules for programming
即使它们最终只快了微不足道的一百万倍，这也应该改变编程的基本规则
languages substantially.
基本上是语言。
Among other things, there will be more room for what would now be considered slow languages, meaning languages that don't yield very efficient code.
除此之外，现在被认为是慢速语言的语言将会有更多的空间，这意味着不能产生非常高效的代码的语言。
And yet some applications will still demand speed.
然而，一些应用程序仍然需要速度。
Some of the problems we want to solve with computers are created by computers; for example, the rate at which you have to process video images depends on the rate at which another computer can
我们想要用计算机解决的一些问题是由计算机创造的；例如，您处理视频图像的速率取决于另一台计算机可以处理的速率
generate them.
生成它们。
And there is another class of problems which inherently have an unlimited capacity to soak up cycles: image rendering, cryptography, simulations.
还有另一类问题本质上具有无限的吸收周期的能力：图像渲染、密码学、模拟。
If some applications can be increasingly inefficient while others continue to demand all the speed the hardware can deliver, faster computers will mean that languages have to cover an ever wider range of efficiencies.
如果某些应用程序的效率越来越低，而其他应用程序继续要求硬件能够提供的所有速度，那么更快的计算机将意味着语言必须涵盖更广泛的效率。
We've seen this happening already.
我们已经看到这种情况发生了。
Current implementations of some
目前的一些实现
popular new languages are shockingly wasteful by the standards of previous decades.
按照过去几十年的标准，流行的新语言是令人震惊的浪费。
This isn't just something that happens with programming languages.
这不仅仅是编程语言才会发生的事情。
It's a general historical trend.
这是历史的总趋势。
As technologies improve, each generation can do things that the previous generation would have considered wasteful.
随着技术的进步，每一代人都可以做上一代人认为浪费的事情。
People thirty years ago would be astonished at how casually we make long distance phone calls.
三十年前的人们会对我们打长途电话如此随意感到惊讶。
People a hundred years ago would be even more astonished that
一百年前的人们会更加惊讶
a package would one day travel from Boston to New York via Memphis.
有一天，一个包裹将从波士顿经孟菲斯运往纽约。
I can already tell you what's going to happen to all those extra cycles that faster hardware is going to give us in the next hundred years.
我已经可以告诉你，在接下来的一百年里，更快的硬件将给我们带来的所有额外周期将会发生什么。
They're nearly all going to be wasted.
它们几乎都会被浪费掉。
I learned to program when computer power was scarce.
当计算机能力匮乏时，我学会了编程。
I can remember taking all the spaces out of my Basic programs so they would fit into the memory of a 4K TRS-80.
我记得把基本程序中的所有空格都去掉了，这样它们就可以放入 4K TRS-80 的内存中。
The
的
thought of all this stupendously inefficient software burning up cycles doing the same thing over and over seems kind of gross to me.
想到所有这些极其低效的软件会消耗周期，一遍又一遍地做同样的事情，对我来说似乎有点恶心。
But I think my intuitions here are wrong.
但我认为我的直觉是错误的。
I'm like someone who grew up poor, and can't bear to spend money even for something important, like going to the doctor.
我就像一个出身贫穷的人，连看病这样重要的事情都舍不得花钱。
Some kinds of waste really are disgusting.
有些浪费确实令人厌恶。
SUVs, for example, would arguably be gross even if they ran on a fuel which would never
例如，SUV 可能会很恶心，即使它们使用的燃料永远不会
run out and generated no pollution.
用完且不产生任何污染。
SUVs are gross because they're the solution to a gross problem.
SUV 很糟糕，因为它们是解决严重问题的办法。
(How to make minivans look more masculine.) But not all waste is bad.
（如何让小型货车看起来更有男子气概。）但并非所有浪费都是坏事。
Now that we have the infrastructure to support it, counting the minutes of your long-distance calls starts to seem niggling.
现在我们已经有了支持它的基础设施，计算长途通话的分钟数开始显得很麻烦。
If you have the resources, it's more elegant to think of all phone calls as one kind of thing, no matter where the other person is.
如果您有资源，那么将所有电话视为一种事情会更优雅，无论对方在哪里。
There's good waste, and bad waste.
有好的浪费，也有坏的浪费。
I'm interested in good waste-- the kind where, by spending more, we can get simpler designs.
我对好的浪费感兴趣——通过花更多的钱，我们可以获得更简单的设计。
How will we take advantage of the opportunities to waste cycles that we'll get from new, faster hardware?
我们将如何利用新的、更快的硬件所带来的浪费周期的机会？
The desire for speed is so deeply engrained in us, with our puny computers, that it will take a conscious effort to overcome it.
对于我们这些微不足道的计算机来说，对速度的渴望是如此根深蒂固，以至于需要有意识地努力才能克服它。
In language design, we should be consciously seeking out
在语言设计中，我们应该有意识地寻找
situations where we can trade efficiency for even the smallest increase in convenience.
在这种情况下，我们可以用效率来换取哪怕是最小的便利性的增加。
Most data structures exist because of speed.
大多数数据结构的存在是因为速度。
For example, many languages today have both strings and lists.
例如，当今许多语言都具有字符串和列表。
Semantically, strings are more or less a subset of lists in which the elements are characters.
从语义上讲，字符串或多或少是列表的子集，其中元素是字符。
So why do you need a separate data type?
那么为什么需要单独的数据类型呢？
You don't, really.
你不知道，真的。
Strings only exist for efficiency.
字符串的存在只是为了提高效率。
But it's lame to clutter up the semantics
但混淆语义是很蹩脚的
of the language with hacks to make programs run faster.
语言的技巧使程序运行得更快。
Having strings in a language seems to be a case of premature optimization.
在语言中使用字符串似乎是过早优化的一个例子。
If we think of the core of a language as a set of axioms, surely it's gross to have additional axioms that add no expressive power, simply for the sake of efficiency.
如果我们将语言的核心视为一组公理，那么仅仅为了效率而添加不增加表达能力的额外公理肯定是很恶心的。
Efficiency is important, but I don't think that's the right way to get it.
效率很重要，但我认为这不是获得效率的正确方法。
The right way to solve that problem, I think, is to separate
我认为解决这个问题的正确方法是分开
the meaning of a program from the implementation details.
一个程序的意义是从实现细节开始的。
Instead of having both lists and strings, have just lists, with some way to give the compiler optimization advice that will allow it to lay out strings as contiguous bytes if necessary.
不要同时拥有列表和字符串，而只拥有列表，并通过某种方式向编译器提供优化建议，使其在必要时将字符串布局为连续字节。
Since speed doesn't matter in most of a program, you won't ordinarily need to bother with this sort of micromanagement.
由于速度在大多数程序中并不重要，因此您通常不需要费心进行这种微观管理。
This will be more and more true as computers get faster.
随着计算机变得越来越快，这一点将变得越来越正确。
Saying less about implementation should also make programs more flexible.
少说实施也应该使计划更加灵活。
Specifications change while a program is being written, and this is not only inevitable, but desirable.
在编写程序时规范会发生变化，这不仅是不可避免的，而且是可取的。
The word "essay" comes from the French verb "essayer", which means "to try".
“essay”一词源自法语动词“essayer”，意思是“尝试”。
An essay, in the original sense, is something you write to try to figure something out.
论文，从最初的意义上来说，是为了试图弄清楚某件事而写的东西。
This happens in software too.
这种情况也发生在软件中。
I think some of the best programs were essays,
我认为一些最好的课程是论文，
in the sense that the authors didn't know when they started exactly what they were trying to write.
从某种意义上说，作者不知道他们什么时候开始确切地写他们想要写的东西。
Lisp hackers already know about the value of being flexible with data structures.
Lisp 黑客已经知道灵活处理数据结构的价值。
We tend to write the first version of a program so that it does everything with lists.
我们倾向于编写程序的第一个版本，以便它可以使用列表完成所有操作。
These initial versions can be so shockingly inefficient that it takes a conscious effort not to think about what they're doing, just as, for me at least, eating a steak requires a
这些最初的版本可能效率低得令人震惊，以至于需要有意识地努力不去思考它们在做什么，就像，至少对我来说，吃牛排需要
conscious effort not to think where it came from.
有意识地努力不去想它来自哪里。
What programmers in a hundred years will be looking for, most of all, is a language where you can throw together an unbelievably inefficient version 1 of a program with the least possible effort.
一百年后，程序员最需要寻找的是一种语言，您可以用最少的努力拼凑出令人难以置信的低效版本 1 的程序。
At least, that's how we'd describe it in present-day terms.
至少，我们现在是这样描述它的。
What they'll say is that they want a language that's easy to program in.
他们会说他们想要一种易于编程的语言。
Inefficient software isn't gross.
低效的软件并不恶心。
What's gross is a language
最糟糕的是语言
that makes programmers do needless work.
这使得程序员做不必要的工作。
Wasting programmer time is the true inefficiency, not wasting machine time.
浪费程序员时间才是真正的低效率，而不是浪费机器时间。
This will become ever more clear as computers get faster.
随着计算机变得越来越快，这一点将变得更加清晰。
I think getting rid of strings is already something we could bear to think about.
我想摆脱弦乐已经是我们值得思考的事情了。
We did it in Arc , and it seems to be a win; some operations that would be awkward to describe as regular expressions can be described easily as recursive functions.
我们在 Arc 中做到了，这似乎是一场胜利；一些难以用正则表达式描述的操作可以很容易地用递归函数描述。
How far will this flattening of data structures go?
数据结构的扁平化能走多远？
I can think of possibilities that shock even me, with my conscientiously broadened mind.
凭借我认真拓宽的视野，我能想到连我自己都感到震惊的可能性。
Will we get rid of arrays, for example?
例如，我们会摆脱数组吗？
After all, they're just a subset of hash tables where the keys are vectors of integers.
毕竟，它们只是哈希表的子集，其中键是整数向量。
Will we replace hash tables themselves with lists?
我们会用列表替换哈希表本身吗？
There are more shocking prospects even than that.
甚至还有比这更令人震惊的前景。
The Lisp that McCarthy described in 1960, for example, didn't
例如，麦卡锡在 1960 年描述的 Lisp 并没有
have numbers.
有数字。
Logically, you don't need to have a separate notion of numbers, because you can represent them as lists: the integer n could be represented as a list of n elements.
从逻辑上讲，您不需要有单独的数字概念，因为您可以将它们表示为列表：整数 n 可以表示为包含 n 个元素的列表。
You can do math this way.
你可以这样做数学。
It's just unbearably inefficient.
这简直是低效得令人难以忍受。
No one actually proposed implementing numbers as lists in practice.
实际上没有人建议在实践中将数字实施为列表。
In fact, McCarthy's 1960 paper was not, at the time, intended to be implemented at all.
事实上，麦卡锡 1960 年的论文当时根本没有打算实施。
It was a theoretical exercise ,
这是一个理论练习，
an attempt to create a more elegant alternative to the Turing Machine.
尝试创建一个更优雅的图灵机替代品。
When someone did, unexpectedly, take this paper and translate it into a working Lisp interpreter, numbers certainly weren't represented as lists; they were represented in binary, as in every other language.
当有人出人意料地把这篇论文翻译成一个可用的 Lisp 解释器时，数字肯定不是用列表来表示的；而是数字。与其他语言一样，它们也以二进制表示。
Could a programming language go so far as to get rid of numbers as a fundamental data type?
编程语言是否可以摆脱数字作为基本数据类型的束缚？
I ask this not so much as a serious
我问这个问题与其说是一个严肃的问题
question as as a way to play chicken with the future.
问题作为与未来玩胆怯的一种方式。
It's like the hypothetical case of an irresistible force meeting an immovable object-- here, an unimaginably inefficient implementation meeting unimaginably great resources.
这就像一个不可抗拒的力量遇到一个不可移动的物体的假设案例——在这里，一个难以想象的低效实施遇到了难以想象的巨大资源。
I don't see why not.
我不明白为什么不。
The future is pretty long.
未来还很长。
If there's something we can do to decrease the number of axioms in the core language, that would seem to be the side to bet on as t approaches
如果我们可以采取一些措施来减少核心语言中公理的数量，那么随着时间的推移，这似乎是值得押注的一方
infinity.
无穷大。
If the idea still seems unbearable in a hundred years, maybe it won't in a thousand.
如果这个想法一百年后仍然令人难以忍受，那么也许一千年后就不会了。
Just to be clear about this, I'm not proposing that all numerical calculations would actually be carried out using lists.
为了澄清这一点，我并不是建议所有数值计算实际上都使用列表进行。
I'm proposing that the core language, prior to any additional notations about implementation, be defined this way.
我建议在任何有关实现的附加符号之前，以这种方式定义核心语言。
In practice any program that wanted to do any amount of math would probably represent
在实践中，任何想要进行任意数量数学计算的程序都可能代表
numbers in binary, but this would be an optimization, not part of the core language semantics.
二进制数字，但这将是一种优化，而不是核心语言语义的一部分。
Another way to burn up cycles is to have many layers of software between the application and the hardware.
另一种消耗周期的方法是在应用程序和硬件之间设置多层软件。
This too is a trend we see happening already: many recent languages are compiled into byte code.
这也是我们已经看到的趋势：许多最近的语言都被编译成字节码。
Bill Woods once told me that, as a rule of thumb, each layer of interpretation costs a factor of 10 in speed.
比尔·伍兹 (Bill Woods) 曾经告诉我，根据经验，每层解释的速度都会降低 10 倍。
This extra cost buys you flexibility.
这种额外的成本可以为您带来灵活性。
The very first version of Arc was an extreme case of this sort of multi-level slowness, with corresponding benefits.
Arc 的第一个版本是这种多级缓慢的极端例子，但也有相应的好处。
It was a classic "metacircular" interpreter written on top of Common Lisp, with a definite family resemblance to the eval function defined in McCarthy's original Lisp paper.
它是一个在 Common Lisp 之上编写的经典“元循环”解释器，与 McCarthy 最初的 Lisp 论文中定义的 eval 函数有明显的家族相似性。
The whole thing was only a couple hundred lines of code, so it was very easy to understand and change.
整个事情只有几百行代码，因此非常容易理解和更改。
The Common Lisp we used, CLisp, itself runs on top
我们使用的 Common Lisp CLisp 本身运行在顶层
of a byte code interpreter.
字节码解释器。
So here we had two levels of interpretation, one of them (the top one) shockingly inefficient, and the language was usable.
所以这里我们有两个级别的解释，其中一个（最上面的一个）效率低得惊人，而语言是可用的。
Barely usable, I admit, but usable.
我承认，勉强可用，但可以用。
Writing software as multiple layers is a powerful technique even within applications.
即使在应用程序中，将软件编写为多层也是一项强大的技术。
Bottom-up programming means writing a program as a series of layers, each of which serves as a language for the one above.
自底向上编程意味着将程序编写为一系列层，每一层都充当上面一层的语言。
This approach tends to yield
这种方法往往会产生
smaller, more flexible programs.
更小、更灵活的程序。
It's also the best route to that holy grail, reusability.
这也是实现可重用性这一圣杯的最佳途径。
A language is by definition reusable.
根据定义，语言是可重用的。
The more of your application you can push down into a language for writing that type of application, the more of your software will be reusable.
您可以将越多的应用程序下放到用于编写该类型应用程序的语言中，您的软件就越可重用。
Somehow the idea of reusability got attached to object-oriented programming in the 1980s, and no amount of evidence to the contrary seems to be able to shake it free.
不知何故，可重用性的想法在 20 世纪 80 年代与面向对象编程联系在一起，并且没有任何相反的证据似乎能够摆脱它。
But
但是
although some object-oriented software is reusable, what makes it reusable is its bottom-upness, not its object-orientedness.
尽管有些面向对象的软件是可重用的，但使其可重用的是它的自下而上的特性，而不是它的面向对象特性。
Consider libraries: they're reusable because they're language, whether they're written in an object-oriented style or not.
考虑一下库：它们是可重用的，因为它们是语言，无论它们是否以面向对象的风格编写。
I don't predict the demise of object-oriented programming, by the way.
顺便说一句，我并不预测面向对象编程的消亡。
Though I don't think it has much to offer good programmers, except in certain specialized domains, it is irresistible to
虽然我不认为它能为优秀的程序员提供什么，除了在某些专门领域之外，但它是不可抗拒的
large organizations.
大型组织。
Object-oriented programming offers a sustainable way to write spaghetti code.
面向对象编程提供了一种可持续的方式来编写意大利面条式代码。
It lets you accrete programs as a series of patches.
它允许您将程序作为一系列补丁来积累。
<!--, without the effort of understanding, or the risk of breaking, existing code.
<!--，无需努力理解，也无需冒破坏现有代码的风险。
--> Large organizations always tend to develop software this way, and I expect this to be as true in a hundred years as it is today.
--> 大型组织总是倾向于以这种方式开发软件，我希望这一点在一百年后也能像今天一样真实。
As long as we're talking about the future, we had better
只要我们谈论未来，我们就更好
talk about parallel computation, because that's where this idea seems to live.
谈论并行计算，因为这就是这个想法的所在。
That is, no matter when you're talking, parallel computation seems to be something that is going to happen in the future.
也就是说，无论你在什么时候谈论，并行计算似乎都是未来将会发生的事情。
Will the future ever catch up with it?
未来能赶上它吗？
People have been talking about parallel computation as something imminent for at least 20 years, and it hasn't affected programming practice much so far.
至少 20 年来，人们一直在谈论并行计算，认为它即将到来，但到目前为止，它还没有对编程实践产生太大影响。
Or hasn't it?
或者不是吗？
Already
已经
chip designers have to think about it, and so must people trying to write systems software on multi-cpu computers.
芯片设计者必须考虑这个问题，尝试在多 CPU 计算机上编写系统软件的人们也必须考虑这个问题。
The real question is, how far up the ladder of abstraction will parallelism go?
真正的问题是，并行性将在抽象阶梯上走多远？
In a hundred years will it affect even application programmers?
一百年后，它甚至会影响应用程序程序员吗？
Or will it be something that compiler writers think about, but which is usually invisible in the source code of applications?
还是编译器编写者会考虑但通常在应用程序的源代码中不可见的东西？
One thing that does seem likely is that most opportunities for
看起来确实有可能的一件事是，大多数机会
parallelism will be wasted.
并行性将被浪费。
This is a special case of my more general prediction that most of the extra computer power we're given will go to waste.
这是我更一般性预测的一个特例，即我们获得的大部分额外计算机能力将被浪费。
I expect that, as with the stupendous speed of the underlying hardware, parallelism will be something that is available if you ask for it explicitly, but ordinarily not used.
我希望，与底层硬件的惊人速度一样，如果您明确要求，并行性将是可用的，但通常不使用。
This implies that the kind of parallelism we have in a hundred years will not, except in special applications, be
这意味着，除了特殊应用之外，一百年后我们所拥有的并行性将不会被改变。
massive parallelism.
大规模并行性。
I expect for ordinary programmers it will be more like being able to fork off processes that all end up running in parallel.
我预计对于普通程序员来说，这更像是能够分叉出所有最终并行运行的进程。
And this will, like asking for specific implementations of data structures, be something that you do fairly late in the life of a program, when you try to optimize it.
就像要求数据结构的具体实现一样，这将是您在程序生命周期的后期尝试优化程序时要做的事情。
Version 1s will ordinarily ignore any advantages to be got from parallel computation, just
版本 1 通常会忽略并行计算带来的任何优势，只是
as they will ignore advantages to be got from specific representations of data.
因为他们会忽略从数据的特定表示中获得的优势。
Except in special kinds of applications, parallelism won't pervade the programs that are written in a hundred years.
除了特殊类型的应用程序之外，并行性不会渗透到一百年后编写的程序中。
It would be premature optimization if it did.
如果这样做的话，那将是过早的优化。
How many programming languages will there be in a hundred years?
一百年后会有多少种编程语言？
There seem to be a huge number of new programming languages lately.
最近似乎出现了大量新的编程语言。
Part of the reason is that
部分原因是
faster hardware has allowed programmers to make different tradeoffs between speed and convenience, depending on the application.
更快的硬件允许程序员根据应用程序在速度和便利性之间做出不同的权衡。
If this is a real trend, the hardware we'll have in a hundred years should only increase it.
如果这是一个真正的趋势，那么一百年后我们将拥有的硬件只会增加它。
And yet there may be only a few widely-used languages in a hundred years.
然而一百年内可能只有几种广泛使用的语言。
Part of the reason I say this is optimism: it seems that, if you did a really good job, you could make a language that was ideal for writing a
我这样说的部分原因是乐观：看起来，如果你做得非常好，你可以创造一种非常适合编写
slow version 1, and yet with the right optimization advice to the compiler, would also yield very fast code when necessary.
缓慢的版本 1，但如果给编译器提供正确的优化建议，在必要时也会产生非常快的代码。
So, since I'm optimistic, I'm going to predict that despite the huge gap they'll have between acceptable and maximal efficiency, programmers in a hundred years will have languages that can span most of it.
因此，由于我很乐观，我将预测，尽管可接受的效率和最大效率之间存在巨大差距，但一百年后程序员将拥有可以跨越大部分效率的语言。
As this gap widens, profilers will become increasingly important.
随着这一差距的扩大，分析器将变得越来越重要。
Little attention is paid to profiling now.
现在很少有人关注分析。
Many people still
很多人还是
seem to believe that the way to get fast applications is to write compilers that generate fast code.
似乎相信获得快速应用程序的方法是编写生成快速代码的编译器。
As the gap between acceptable and maximal performance widens, it will become increasingly clear that the way to get fast applications is to have a good guide from one to the other.
随着可接受的性能和最大性能之间的差距越来越大，越来越清楚的是，获得快速应用程序的方法是从一个到另一个应用程序有一个良好的指导。
When I say there may only be a few languages, I'm not including domain-specific "little languages".
当我说可能只有几种语言时，我并没有包括特定领域的“小语言”。
I think such embedded languages
我认为这样的嵌入式语言
are a great idea, and I expect them to proliferate.
是一个好主意，我希望它们能够扩散。
But I expect them to be written as thin enough skins that users can see the general-purpose language underneath.
但我希望它们能够写得足够薄，以便用户可以看到下面的通用语言。
Who will design the languages of the future?
谁将设计未来的语言？
One of the most exciting trends in the last ten years has been the rise of open-source languages like Perl, Python, and Ruby.
过去十年中最令人兴奋的趋势之一是 Perl、Python 和 Ruby 等开源语言的兴起。
Language design is being taken over by hackers.
语言设计正在被黑客接管。
The results so far are messy, but encouraging.
迄今为止的结果虽然混乱，但令人鼓舞。
There are some stunningly
有一些令人惊叹的
novel ideas in Perl, for example.
例如，Perl 中的新颖想法。
Many are stunningly bad, but that's always true of ambitious efforts.
很多都非常糟糕，但雄心勃勃的努力总是如此。
At its current rate of mutation, God knows what Perl might evolve into in a hundred years.
按照目前的突变速度，天知道一百年后 Perl 会演变成什么。
It's not true that those who can't do, teach (some of the best hackers I know are professors), but it is true that there are a lot of things that those who teach can't do.
那些不会做的事情，并不是说教的人（我认识的一些最好的黑客是教授），但确实有很多事情是教的人做不到的。
Research imposes constraining caste restrictions.
研究施加了严格的种姓限制。
In any academic
在任何学术领域
field there are topics that are ok to work on and others that aren't.
在这个领域中，有些主题可以进行，有些则不可以。
Unfortunately the distinction between acceptable and forbidden topics is usually based on how intellectual the work sounds when described in research papers, rather than how important it is for getting good results.
不幸的是，可接受和禁止的主题之间的区别通常是基于研究论文中描述的工作听起来有多聪明，而不是它对于获得良好结果的重要性。
The extreme case is probably literature; people studying literature rarely say anything that would be of the slightest use to those
极端的情况可能是文学；学习文学的人很少会说一些对他们有丝毫用处的话
producing it.
生产它。
Though the situation is better in the sciences, the overlap between the kind of work you're allowed to do and the kind of work that yields good languages is distressingly small.
尽管科学领域的情况更好，但你被允许做的工作类型和产生良好语言的工作类型之间的重叠却小得令人痛苦。
(Olin Shivers has grumbled eloquently about this.) For example, types seem to be an inexhaustible source of research papers, despite the fact that static typing seems to preclude true macros-- without which, in my opinion, no
（Olin Shivers 对此进行了雄辩的抱怨。）例如，类型似乎是研究论文取之不尽用之不竭的来源，尽管事实上静态类型似乎排除了真正的宏——在我看来，没有它，就没有宏。
language is worth using.
语言是值得使用的。
The trend is not merely toward languages being developed as open-source projects rather than "research", but toward languages being designed by the application programmers who need to use them, rather than by compiler writers.
这种趋势不仅是作为开源项目而不是“研究”来开发语言，而且是由需要使用它们的应用程序程序员而不是编译器编写者来设计语言。
This seems a good trend and I expect it to continue.
这似乎是一个好的趋势，我预计它会持续下去。
Unlike physics in a hundred years, which is almost necessarily impossible to predict, I think it may be possible in principle
与一百年后的物理学几乎必然无法预测不同，我认为原则上可能是可能的
to design a language now that would appeal to users in a hundred years.
现在设计一种能够在一百年后吸引用户的语言。
One way to design a language is to just write down the program you'd like to be able to write, regardless of whether there is a compiler that can translate it or hardware that can run it.
设计语言的一种方法是写下您想要编写的程序，无论是否有可以翻译它的编译器或可以运行它的硬件。
When you do this you can assume unlimited resources.
当您这样做时，您可以承担无限的资源。
It seems like we ought to be able to imagine unlimited resources as well today as in a hundred years.
看来我们应该能够想象今天和一百年后的无限资源。
What program would one like to write?
人们想编写什么程序？
Whatever is least work.
不管是最少的工作。
Except not quite: whatever would be least work if your ideas about programming weren't already influenced by the languages you're currently used to.
但不完全是这样：如果您对编程的想法还没有受到您当前使用的语言的影响，那么无论什么都是最不可行的。
Such influence can be so pervasive that it takes a great effort to overcome it.
这种影响非常普遍，需要付出巨大的努力才能克服。
You'd think it would be obvious to creatures as lazy as us how to express a program with the least effort.
你可能会认为，对于像我们这样懒惰的生物来说，如何用最少的努力来表达一个程序是显而易见的。
In fact, our ideas about what's possible
事实上，我们对可能性的想法
tend to be so limited by whatever language we think in that easier formulations of programs seem very surprising.
往往受到我们认为的任何语言的限制，因此更简单的程序表述似乎非常令人惊讶。
They're something you have to discover, not something you naturally sink into.
它们是你必须去发现的东西，而不是你自然陷入的东西。
One helpful trick here is to use the length of the program as an approximation for how much work it is to write.
这里一个有用的技巧是使用程序的长度作为需要编写的工作量的近似值。
Not the length in characters, of course, but the length in distinct syntactic elements-- basically,
当然，不是字符的长度，而是不同语法元素的长度——基本上，
the size of the parse tree.
解析树的大小。
It may not be quite true that the shortest program is the least work to write, but it's close enough that you're better off aiming for the solid target of brevity than the fuzzy, nearby one of least work.
最短的程序就是编写的工作量最少的说法可能不太正确，但它已经足够接近了，您最好瞄准简洁的可靠目标，而不是模糊的、附近的工作量最少的程序。
Then the algorithm for language design becomes: look at a program and ask, is there any way to write this that's shorter?
那么语言设计的算法就变成了：看一个程序并问，有没有办法写得更短？
In practice, writing programs in an imaginary hundred-year
在实践中，在想象的百年内编写程序
language will work to varying degrees depending on how close you are to the core.
语言会发挥不同程度的作用，具体取决于你与核心的距离有多近。
Sort routines you can write now.
对您现在可以编写的例程进行排序。
But it would be hard to predict now what kinds of libraries might be needed in a hundred years.
但现在很难预测一百年后可能需要什么样的图书馆。
Presumably many libraries will be for domains that don't even exist yet.
想必许多库将用于尚不存在的领域。
If SETI@home works, for example, we'll need libraries for communicating with aliens.
例如，如果 SETI@home 有效，我们将需要图书馆来与外星人交流。
Unless of course they are sufficiently advanced that they already communicate
当然，除非他们足够先进，他们已经可以交流了
in XML.
在 XML 中。
At the other extreme, I think you might be able to design the core language today.
在另一个极端，我认为你今天也许能够设计核心语言。
In fact, some might argue that it was already mostly designed in 1958.
事实上，有些人可能会说它的大部分设计是在 1958 年完成的。
If the hundred year language were available today, would we want to program in it?
如果今天有百年语言可用，我们会想用它来编程吗？
One way to answer this question is to look back.
回答这个问题的一种方法是回顾过去。
If present-day programming languages had been available in 1960, would anyone have wanted to use them?
如果当今的编程语言在 1960 年就已经出现，会有人想使用它们吗？
In some ways, the answer is no. Languages today assume
从某些方面来说，答案是否定的。今天的语言假设
infrastructure that didn't exist in 1960.
1960 年还不存在的基础设施。
For example, a language in which indentation is significant, like Python, would not work very well on printer terminals.
例如，缩进很重要的语言（如 Python）在打印机终端上无法很好地工作。
But putting such problems aside-- assuming, for example, that programs were all just written on paper-- would programmers of the 1960s have liked writing programs in the languages we use now?
但是，抛开这些问题不谈——例如，假设程序都是写在纸上的——20 世纪 60 年代的程序员会喜欢用我们现在使用的语言编写程序吗？
I think so.
我想是的。
Some of the less imaginative ones,
一些缺乏想象力的人，
who had artifacts of early languages built into their ideas of what a program was, might have had trouble.
如果那些将早期语言的产物融入到他们关于程序是什么的想法中，可能会遇到麻烦。
(How can you manipulate data without doing pointer arithmetic?
（如何在不进行指针算术的情况下操作数据？
How can you implement flow charts without gotos?) But I think the smartest programmers would have had no trouble making the most of present-day languages, if they'd had them.
没有 goto 如何实现流程图？）但我认为，如果最聪明的程序员拥有当今的语言，那么他们在充分利用当今的语言时不会遇到任何困难。
If we had the hundred-year language now, it would at least make a
如果我们现在有了百年语言，它至少会成为一种
great pseudocode.
很棒的伪代码。
What about using it to write software?
用它来编写软件怎么样？
Since the hundred-year language will need to generate fast code for some applications, presumably it could generate code efficient enough to run acceptably well on our hardware.
由于百年语言需要为某些应用程序生成快速代码，因此它可能会生成足够高效的代码，以便在我们的硬件上运行良好。
We might have to give more optimization advice than users in a hundred years, but it still might be a net win.
我们可能必须提供比一百年后用户更多的优化建议，但这仍然可能是一个净胜利。
Now we have two ideas that, if you combine them, suggest interesting
现在我们有两个想法，如果你把它们结合起来，会很有趣
possibilities: (1) the hundred-year language could, in principle, be designed today, and (2) such a language, if it existed, might be good to program in today.
可能性：（1）原则上今天就可以设计百年语言，（2）这样一种语言，如果存在的话，可能适合今天编程。
When you see these ideas laid out like that, it's hard not to think, why not try writing the hundred-year language now?
当你看到这些想法被这样阐述时，很难不去想，为什么不现在就尝试编写百年语言呢？
When you're working on language design, I think it is good to have such a target and to keep it consciously in mind.
当你从事语言设计时，我认为有这样一个目标并有意识地牢记在心是很好的。
When you
当你
learn to drive, one of the principles they teach you is to align the car not by lining up the hood with the stripes painted on the road, but by aiming at some point in the distance.
学习驾驶时，他们教你的原则之一就是调整汽车，不是将引擎盖与道路上画的条纹对齐，而是瞄准远处的某个点。
Even if all you care about is what happens in the next ten feet, this is the right answer.
即使您只关心接下来十英尺内发生的事情，这也是正确的答案。
I think we can and should do the same thing with programming languages.
我认为我们可以而且应该用编程语言做同样的事情。
Notes I believe Lisp Machine Lisp was the first language to embody
注释 我相信 Lisp Machine Lisp 是第一种体现的语言
the principle that declarations (except those of dynamic variables) were merely optimization advice, and would not change the meaning of a correct program.
声明（动态变量除外）仅仅是优化建议，不会改变正确程序的含义。
Common Lisp seems to have been the first to state this explicitly.
Common Lisp 似乎是第一个明确声明这一点的。
Thanks to Trevor Blackwell, Robert Morris, and Dan Giffin for reading drafts of this, and to Guido van Rossum, Jeremy Hylton, and the rest of the Python crew for inviting me to speak at PyCon.
感谢 Trevor Blackwell、Robert Morris 和 Dan Giffin 阅读本文的草稿，感谢 Guido van Rossum、Jeremy Hylton 和其他 Python 团队邀请我在 PyCon 上发言。