心里牢牢记住这个目标是有好处的学习开车的时候，当你设计语言的时候。一个需要记住的原则就是要把车开直，不是通过将车身对齐画在地上的分隔线，而是通过瞄准远处的某个点。即使你目标只在几米开外，这样做也是正确的认为，设计编程语言时，也应该这样做。

只有少数几件事是可以确定的那时，很难预测一百年后的人类生活。汽车将具备低空飞行能力，乡村规划的法规将放宽，大楼可以造到几百层，大街上一天到晚看不见太阳，女性个个都学过防身术。本文只想讨论其中的一个细节：一百年后，人们使用什么语言开发软件？

而是幸运的话，为什么这个问题值得思考？原因不是最终会用上这些语言。从现在开始就能用上这些语言。

编程语言就像生物物种一样，认为。存在一个进化的脉络，许许多多分支最终都会成为进化的死胡同。这种现象已经发生了Cobol语言曾经流行一时，但是现在看来没有任何后续语言继承它思想。就像尼安德特人 一样，进化之路已经走到尽头。

或者是相信学会Java就能找到工作的大学生数量，预言Java也会如此。有人写信说：怎么能说Java不会成功呢？已经胜利了觉得这要看你胜利规范是什么。如果规范是相关书籍的出版量。那么 Java确实已经胜利了当我说Java不会成功时，意思是和Cobol一样，进化之路已经走到尽头。

未必正确。这里的重点不是看衰Java而是提出编程语言存在一个进化的脉络，这只是猜想。从而引导读者思考，整个进化过程中，某一种语言的位置到底在哪里？之所以要问这个问题，不是为了一百年后让后人感叹我曾经如此英明，而是为了找到进化的主干。会启发我去选择那些靠近主干的语言，这样对当前的编程最有利。

选择进化的主干可能都是最佳方案。要是倒霉选错了变成了一个尼安德特人，无论何时。那就太糟了对手克鲁马努人时不时就会来攻打你把你食物全部偷走。

这就是想找出一百年后的编程语言的原因。不愿意押错赌注。

Fortran分支看来正在与Algol继承者聚合。理论上，编程语言的进化与生物学进化还是有区别的因为不同分支的语言会发生聚合。比方。不同的生物物种也可能发生聚合，但是可能性很低，所以大概历来没有真正出现过。

一个原因是概率空间比较小，编程语言之所以可能出现聚合。另一个原因是突变不是随机的语言的设计者们总是有意识地借鉴其他语言的设计思想。

认清编程语言的进化路径特别有用，对于语言设计者来说。因为这样就可以照着样子设计语言了这时，认清进化的主干就不只有助于识别现存的优秀语言，还可以把它当作设计语言的指南。

这个局部可以用基本运算符表达出来）任何一种编程语言都可以分成两大组成部分：基本运算符的集合（扮演公理的角色）以及除运算符以外的其他局部（原则上。

基本运算符是一种语言能否临时存在最重要因素。其他因素都不是决定性的这有点像买房子的时候你应该先考虑地理位置。别的地方将来出问题都有办法弥补，认为。但是地理位置是没法变的

还必须控制它规模。数学家总是觉得公理越少越好，慎重选择公理还不够。觉得他说到点子上。

考虑哪些局部可以被摒弃，仔细审视一种语言的内核。这至少也是一种很有用的训练。临时的职业生涯中，发现冗余的代码会导致更多冗余的代码，不只软件如此，而且像我这样性格懒散的人，发现在床底下和房间的角落里这个命题也成立，一件垃圾会产生更多的垃圾。

生命力就越顽强。判断是那些内核最小、最干净的编程语言才会存在于进化的主干上。一种语言的内核设计得越小、越干净。

猜测一百年后人们使用什么编程语言，当然。这本身就是一个很大的假设。也许一百年后人类已经不编程了或者直接告诉计算机想做什么，计算机就会自动完成。

目前为止，不过。计算机智能并没有取得太大进展。猜测一百年后，人们还是使用与现在差不多的顺序指挥计算机。可能有一些我今天需要编程解决的问题，那时已经不需要编程了但是想，那时还会存在大量与今天一样的编程任务。

软件发展的历史已经走过了50年。这50年中，可能认为只有那些自以为是人才会去预言一百年后的技术。但是请不要忘记。编程语言的进化其实是非常缓慢的因此展望一百年后的语言并不是虚无缥缈的想法。

而程序则是一种严格符合规则的描述，编程语言进化缓慢的原因在于它并不是真正的技术。语言只是一种书写法。以书面形式记录计算机应该如何解决你问题。所以，编程语言的进化速度更像数学符号的进化速度，而不像真正的技术（比如交通或通信技术）进化速度。数学符号的进化是缓慢的渐变式变化，而不是真正技术的那种跳跃式发展。

基本上可以断定它运行速度一定会快得多。如果摩尔定律依然成立，无论一百年后的计算机是什么样子。一百年后计算机的运行速度将是现在74乘以1018次方倍（准确地说是73786976294838206464倍）真是让人难以想象。不过实际上更现实的预测并不是速度会提高这么多，而是摩尔定律最终将不成立。不论是什么东西，如果每18个月就增长一倍，那么最后很可能会达到极限。但那时的计算机比现在快得多大概是毫无疑问的即使最后只是略微快了100万倍，也将实质性地改变编程的基本规则。如果其他条件不变，现在被认为运行速度慢的语言（即运行的效率不高）将来会有更大的发展空间。

依然会有对运行速度要求很高的应用顺序。希望计算机解决的有些问题其实是计算机自身引起的比方，那时。计算机处置视频的速度取决于生成这些视频的另一台计算机。此外，还有一些问题自身就要求无限快的处置能力，比如图像渲染、加密/解密、模拟运算等。

而另一些应用顺序会耗尽硬件提供的所有运算能力，既然在现实中一些应用顺序自身的效率较低。那么有了更快速的计算机就意味着编程语言不得不应付更多的极端情况，涵盖更大范围的效率要求。已经看到这种情况发生了要是以几十年前的规范衡量，有一些使用新语言开发的热门应用顺序对硬件资源的浪费非常惊人。

这实际上是一种普遍的历史趋势。随着技术的发展，不只编程语言有这种现象。每一代人都在做上一代人觉得很浪费的事情。30年前的人要是看到今天如此随意地使用长途电话，一定会感到震惊。100年前的人要是看到一个普通的包裹竟然也能享受一天内从波士顿发件、途经孟菲斯、抵达纽约的待遇，恐怕就要更震惊了

已经预测了一旦未来硬件的性能大幅提高将会发生什么事。新增加的运算能力都会被糟蹋掉。

计算机还是稀罕玩意。记得当时使用的微机型号是PS-80内存只有 4K为了把BA SIC顺序装入内存，学习编程的年代。不得不把源码中的空格全部删除。一想到那些极其低效率的软件，不时重复某些愚蠢的运算，把硬件的计算能力全部占用，就感到无法忍受。但是这种反应是错的就像某个出身贫寒的穷孩子，一听到要花钱就舍不得，即使把钱用在重要场所（比如去医院看病）都觉得很难接受。

因为SUV来自一个令人厌恶的想法（如何使得小货车看上去更有男子汉气概）但是并非所有的浪费都是坏的既然如今的电信基础设施已经如此发达，某些浪费确实令人厌恶。比如有人就很讨厌SUV运动型多用途车）即使它采用可再生的清洁能源也改变不了看法。再掐着时间打长途电话就有点锱铢必较了如果有足够的资源，可以将长途电话和外地电话视为同一件事，一切会变得更轻松。

即用更多的钱得到更简单的设计。所以，浪费可以分成好的浪费和坏的浪费。感兴趣的好的浪费。问题就变成了如何才干充分利用新硬件更强大的性能最有利地“浪费”

就会不由自主地希望顺序运行得越快越好，对速度的追求是人类内心深处根深蒂固的欲望。当你看着计算机这个小玩意。真的要下一番功夫才干把这种欲望克制住。设计编程语言的时候，应该有意识地问自己，什么时候可以放弃一些性能，换来一点点便利性的提高。

今天的许多语言都同时有字符串和列表。从语义上看，很多数据结构存在原因都与计算机的速度有关。比方。字符串或多或少可以理解成列表的一个子集，其中的每一个元素都是字符。那么，为什么还需要把字符串单列为一种数据类型呢？完全可以不这么做。只是为了提高效率，所以字符串才会存在但是这种以加快运行速度为目的却使得编程语言的语义大大复杂的行为，很不可取。编程语言设置字符串似乎就是一个过早优化的例子。

那么仅仅为了提高效率就往内核添加多余的公理，如果我把一种语言的内核设想为一些基本公理的集合。却没有带来表达能力的提升，这肯定是一件很糟的事。没错，效率是很重要，但是认为修改语言设计并不是提高效率的正确方法。

单单列表就够了而在实现上做好编译器优化，正确做法应该是将语言的语义与语言的实现予以分离。语义上不需要同时存在列表和字符串。使它必要时把字符串作为连续字节的形式处置。

速度不是最关键的因素，对于大多数程序。所以你通常不需要费心考虑这种硬件层面上的微观管理。随着计算机速度越来越快，这一点已经越发明显了

对实现方式少作限制还会使得顺序具备更大的灵活性。语言的规格发生变化不只是无法防止的也是合理的通过编译器的处置，语言设计时。依照以前规格开发的软件就会照常运行，这就提供了灵活性。

论文就是写一篇文章，essai论文）这个词来自法语的动词essay意思是试试看”从这个原始意义来说。试着搞清楚某件事。软件也是如此。觉得一些最好的软件就像论文一样，也就是说，当作者真正开始动手写这些软件的时候，其实不知道最后会写出什么结果。

往往会把所有事情都用列表的形式处置。所以，Lisp语言的黑客早就明白数据结构灵活性的价值。写程序的第一版时。这些最初版本可能效率低下得惊人，必需努力克制自己才干忍住不动手优化它这就好像吃牛排的时候必需努力克制自己才干不去想牛排是从哪里来的一样，至少对我来说是这样的

哪怕它效率低下得惊人（至少按我今天的眼光来看是如此）会说，一百年后的顺序员最需要的编程语言就是可以让你毫不费力地写出顺序第一版的编程语言。想要的就是很容易上手的编程语言。

这会变得越来越明显。效率低下的软件并不等于很烂的软件。一种让顺序员做无用功的语言才真正称得上很烂。浪费顺序员的时间而不是浪费机器的时间才是真正的无效率。随着计算机速度越来越快。

放弃字符串类型已经是大家可以接受的想法了Arc语言已经这样做了看上去效果不错。以前用正则表达式很难描述的一些操作，觉得。现在用回归函数可以表达得很简单。

得到结果甚至令我自己都吓了一跳。比方，这种数据结构的扁平化趋势会怎么发展？极其努力地设想各种可能。数组会不会消失？终究数组只是散列表的一个子集，其特点就是数组的键全部都是整数向量。进一步说，散列表自身会不会被列表取代呢？

因为可以把它也看作列表，还有比这更惊人的预言。逻辑上其实不需要对整数设置单独的表示法。整数n可以用一个n元素的列表表示。这一样能完成数学运算，只是效率低得让人无法忍受。

更多的希望打开你对未来的思路。只是提出一种假想的情况：如果一股不可抗拒的力量遇到一个不可移动的物体，编程语言会发展到放弃基本数据类型之一的整数这一步吗？这样问并不是真的要你严肃思考这个问题。会发生什么事。具体就本文而言：一种效率低得不可想象的语言遇到性能强大得不可想象的硬件，会发生什么事。看不出放弃整数类型有什么不妥。未来相当漫长。如果我想要减少语言内核中基本公理的数目，无妨把眼光放得远一点，想一想如果时间变量t趋向无限会怎么样。一百年是一个很好的参考指标，如果你觉得某个想法在一百年后仍然可能是难以令人接受，那么也许一千年后它也依然难以令人接受。

意思不是说所有的整数运算都用列表来实现，让我说清楚。而是说语言的内核（不涉及任何编译器的实现）可以这样定义。现实中，任何进行数学运算的顺序可能都是以二进制形式表示数字，但是这属于编译器的优化，而不属于语言内核语义的一部分。

许多新兴的语言就被编译成字节码 比尔·伍兹曾经对我说，另一种消耗硬件性能的方法就是应用软件与硬件之间设置很多的软件层。这也是已经看到一种趋势。根据经验判断，每增加一个解释层，软件的运行速度就会慢一个数量级。但是多余的软件层可以让编程灵活起来。

层很多，Arc语言最初的版本就是一个极端的例子。运行速度非常慢，但是确实带来了相应的好处。Arc一个典型的元循环”metacircular解释器，CommonLisp基础上开发，很像约翰·麦卡锡在经典的Lisp论文中定义的eval函数。Arc解释器一共只有几百行代码，所以很便于理解和修改。采用的CommonLisp版本是CLisp自身是另一个字节码解释器的基础上开发的所以，一共有两层解释器，最上面那层效率低下得惊人，但是语言自身是能用的供认只是勉强可用，但是确实能用。

使用多层形式开发也是一种很强大的技巧。自下而上的编程方法意味着要把软件分成好几层，即使是应用顺序。每一层都可以充当它上面那一层的开发语言。这种方法往往会产生更小、更灵活的顺序。也是通往软件圣杯—可重用性（reusabl最佳路线。从定义上看，语言就是可以重用的编程语言的协助下，应用顺序越是采用这种多层形式开发，可重用性就越好。

也不可能把这两件事完全分开。某些使用面向对象编程开发进去的软件确实具有可重用性，可重用性这个概念多多少少与 20世纪80年代兴起的面向对象编程有些关联。不管怎样寻找证据。但是这不是因为它使用了面向对象编程，而是因为它开发方法是自下而上的以函数库为例，具有可重用性，因为它属于语言的一部分，而不是因为它采用面向对象或者其他编程方法。

不认为面向对象编程将来会消亡。觉得，顺便说一句。除了某些特定的领域，这种编程方法其实没有为优秀顺序员带来很多好处，但是对大公司有不可抗拒的吸引力。面向对象编程使得你有方法对一团乱码似的代码进行可持续性开发。通过不时地打补丁，让你将软件一步步做大。大公司总是倾向于采用这样的方式开发软件。预计一百年后也是如此。

最好谈谈并行计算（parallelcomput因为看上去并行计算好像就是为未来而存在无论怎么想，既然是谈论未来。并行计算似乎都是未来生活的一部分。

人们都在说并行计算马上就会来临。但是目前为止，会在未来实现吗？过去二十年。对编程实践并没有太大影响。这是真的吗？芯片设计师已经不得不把它考虑在内，为多CPU计算机开发系统软件的顺序员也是如此。

并行计算到底能达到哪个笼统层次？一百年后它就会影响到开发应用软件的顺序员吗？或者，但是真正的问题在于。还只是编译器作者需要考虑的事情，应用软件的代码中根本就无处寻觅？

人们都会放弃使用并行计算。虽然我总的预测是未来的软件会挥霍掉大部分新增的硬件性能，一种可能是大多数可以用到并行计算的场所。但是并行计算是一个特例。估计随着硬件性能得到惊人的提升，如果你明确地说想要并行计算，那么肯定可以得到但是通常情况下你不会用到这意味着，除了一些特殊的应用顺序，一百年后的并行计算不会是那种大规模的并行计算（massivparallel预料，对于普通顺序员来说，一切更像对进程进行分叉，然后让多个进程在后台并行运行。

属于对程序的优化，这是编程进行到很后期才要做的事情。类似于你想开发一种特定的数据结构来取代现有的数据结构。顺序的第一个版本通常会忽略并行计算提供的各种好处，就好像编程开始时会忽略某种特定的数据结构给你带来的好处一样。

一百年后，除了某些特定的应用软件。并行计算不会很流行。如果应用软件真的大量使用并行计算，这就属于过早优化了

呈现了大量的新语言。硬件性能提高是一个原因，一百年后会有多少种编程语言？从最近来看。这就允许顺序员根据使用目的运行速度和编程便利性之间做出不同的取舍。如果这就是未来的趋势，那么一百年后强大的硬件只会使得语言数目变得更多。

一百年后的常用语言可能只有很少几种。局部原因是基于我乐观主义，但是另一方面。相信在未来，如果你作品确实很出色，可能选择的一种开发起来很方便的语言。使用这种语言写出来的软件第一版的运行速度很慢，只有对编译器进行优化设置后运行速度才会提升。既然我抱有这种乐观主义，那么我还要做一个预言。有些语言可以达到机器的最高效率，另一些语言的效率则慢到刚刚可以运行而已，两者之间存在巨大的差异。预言一百年后，这段差距之间的各个点上都会有对应的编程语言存在

所以性能分析器（profil将变得越来越重要。目前，因为这段差距正在变得越来越大。性能分析并没有受到重视。许多人好像仍然相信，顺序运行速度提升的关键在于开发出能够生成更快速代码的编译器。代码效率与机器性能的差别正在不时加大，将会越来越清楚地看到应用软件运行速度提升的关键在于有一个好的性能分析器协助指导顺序开发。

但没有把用于特定领域的小众语言”littllanguag算进去。觉得，说将来可能只有很少几种常用语言。这些嵌入式语言的想法很不错，一定会蓬勃发展。但是判断这些“小众语言”会被设计成相当薄的一层，使得用户可以一眼看出在底下作为基础的通用型语言，这样就减少了学习时间，降低了使用本钱。

比方Perl,谁来设计这些未来的语言？过去10年最激动人心的趋势之一就是开源语言的崛起。Python和Rubi语言设计已经被黑客接管。目前为止这样到底是好是坏还看不清楚，但是发展势头令人鼓舞。比方，Perl就有一些绝妙的创新。不过，也包含了一些很糟糕的想法。对于一种充溢进取心、大胆探索的语言来说，这也是很正常的事。以它现在这种变化的速率，大概只有上帝才知道一百年后Perl会变成什么样。

如果你自己做不到那就去当老师。这在语言设计领域不成立，有一句俗话说。认识的一些最出色的黑客就在当教授。但是当老师的人确实有很多事情不能做。研究性职位给黑客带来了一些限制。任何学术领域，都有一些题目是可以做的另一些题目是不可以做的倒霉的这两类题目的区别通常取决于它写成论文后看上去是不是很高深，而不是取决于它对软件业的发展是否重要。最极端的例子可能就是文学，文学研究者的任何效果几乎对文学创作者都毫无影响。

但是研究者可以做的题目与能够对设计优秀语言有所协助的题目之间的交集小得令人沮丧。奥林·希弗斯曾经对这一点表达满意，虽然科学领域的状况要稍好一点。而且说得头头是道。比方，研究变量类型的论文好像多得无穷无尽，尽管事实上静态类型语言看来无法真正支持宏（看来，一种语言不支持宏，那就不值得使用了

而不是以研究性项目的形式呈现。这是语言的一种发展趋势。另一种发展趋势是新语言的设计者更多的自身就需要使用它应用软件作者，新语言更多地以开源项目的形式呈现。而不是编译器作者。这似乎是好的趋势，期待它继续坚持下去。

现在就动手设计一种一百年后可以吸引使用者的新语言，一百年后的物理学基本上不可能预测。但是计算机语言不一样。这在理论上似乎是可能的

不管编译器是否存在也不管有没有支持它硬件。这就是假设存在无限的资源供你支配。不论是今天还是一百年后，设计新语言的方法之一就是直接写下你想写的顺序。这样的假设好像都是有道理的

只要能让你最省力地写出来就行。但是要注意，应该写什么程序？随便什么。这必须是思维没有被当前使用的编程语言影响的情况下。这种影响无处不在必需很努力才干克服。也许觉得，对于人类这样懒惰的生物，喜欢用最省力的方式写程序是再自然不过的事情。但是事实上，思想可能往往会受限于某种现存的语言，只采用在这种语言看来更简单的形式，对我思想的束缚作用会大得令人震惊。新语言必需靠你自己去发现，不能依靠那些让你自然而然就沉下去的思维定势。

而是指各种句法元素的总长度，采用顺序的长度作为它耗费工作量的近似指标是个很有用的技巧。这里的顺序长度当然不是指字符的数量。基本上就是整个解析树的大小。也许不能说最短的顺序就是写起来最省力的顺序，但是当你一心想把顺序写得简洁而不是松松垮垮时，就更接近省力这个目标，日子也会变得好过得多。所以，设计语言的正确做法就变成了看着一段程序，然后问自己是不是能把它写得更短一点？

用想象出来的一种一百年后的语言来写程序，实际上。这件事情的可靠水平，取决于你对语言内核的估计是否足够正确。惯例的排序，现在就可以写出来。但是想要预测一百年后的语言使用什么函数库就很难了很可能许多函数库针对的领域现在还根本不存在比方，如果 SETI@home计划胜利，就需要与外星人联系的函数库了当然，如果外星人的文明高度发达，已经到用 XML格式交换信息的地步，那就不需要新的函数库了

有些人看来，另一个极端是觉得今天你就能设计出一百年后的语言内核。事实上。大部分语言内核在1958年就已经设计进去了

会用它编程吗？观古而知今。如果1960年就能使用今天的编程语言，如果今天就能使用一百年后的编程语言。那时的人们会用它吗？

回答是否定的今天的编程语言依赖的硬件在1960年并不存在比方，某些方面。Python这样的语言，正确的缩进（indent编写时很重要，但是1960年的计算机没有显示器，只有打印机终端，所以编写起来就不会很顺利。但是如果把这些因素排除在外（可以假设，只在纸上编程）20世纪 60年代的顺序员会喜欢用现在语言编程吗？

如何复制数据？没有goto语句，想他会的某些缺乏想象力、深受早期编程语言思想影响的人可能会觉得不可能。没有指针运算。如何实现流程图？但是想，那时最聪明的顺序员一定能轻松地使用今天的大多数语言，假定他能得到话。

那就至少能用来写出优秀的伪码 会用它开发软件吗？因为一百年后的编程语言需要为某些应用顺序生成快速代码，如果我现在就能拥有一百年后的编程语言。所以很可能它生成的代码能够在硬件上运行，速度也还可以接受。相比一百年后的用户，也许不得不对这种语言做更多的优化，但是总的来看，应该仍然会为我带来净收益。

很可能现在就适合编程，现在两个观点就是1一百年后的编程语言在理论上今天就能设计出来；2如果今天真能设计出这样一种语言。并且能够发生更好的结果。如果我把这两个观点联系起来，那就得出了一些有趣的可能性。为什么不现在就动手尝试写出一百年后的编程语言呢？