并行计算为未来而存在?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　实际上，用想象出来的一种一百年后的语言来写程序，这件事情的可靠程度，取决于你对语言内核的估计是否足够正确。常规的排序，你现在就可以写出来。但是，想要预测一百年后的语言使用什么函数库就很难了。很可能许多函数库针对的领域现在还根本不存在。比如，如果SETI@home①计划成功，我们就需要与外星人联系的函数库了。当然，如果外星人的文明高度发达，已经到了用XML格式交换信息的地步，那就不需要新的函数库了。(①SETI@home是一个寻找地球以外智慧生命的科学实验，由加州大学伯克利分校发起并主持。它使用射电望远镜监听太空中的无线电信号，然后用计算机进行数据分析，如果发现有些信号不可能自然产生，就可以证明外星文明的存在。1995年，该项目决定向志愿者开放，使用全球联网的大量计算机进行分布式计算，1999年5月开始正式运行。详细情况参见http://setiathome.berkeley.edu。——译者注)

　　另一个极端是，我觉得今天你就能设计出一百年后的语言内核。事实上，在有些人看来，大部分语言内核在1958年就已经设计出来了。②(②Lisp语言的第一版规格说明书是1958年发布的。——译者注)

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

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

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

　　如果我们现在就能拥有一百年后的编程语言，那就至少能用来写出优秀的伪码③。我们会用它开发软件吗?因为一百年后的编程语言需要为某些应用程序生成快速代码，所以很可能它生成的代码能够在我们的硬件上运行，速度也还可以接受。相比一百年后的用户，我们也许不得不对这种语言做更多的优化，但是总的来看，它应该仍然会为我们带来净收益。(③伪码又称虚拟代码，用来抽象地描述算法，而不是现实存在的编程代码。——译者注)

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

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

　　原文链接：http://article.yeeyan.org/view/159737/178070