Rogue Wave对Bjarne Stroustrup的专访

荣耀 译  《程序员》2003/06

RW：C++在Internet时代还有意义吗？

Bjarne：那是当然。C++代码不适合下载到不安全计算机中，但大多数计算情况并非如此。 

对于涉及系统编程和资源受限和/或性能要求严格的许多应用来说，C++是最佳语言选择。Google就是一个例子，支撑小型设备的嵌入系统则是另外一个范例。 

此外，还有许多程序并不直接和Internet打交道，对它们而言，世界并无显著变化。 

RW：鉴于.NET平台中立的语言已经摆上台面，您认为这对C++将会产生怎样的影响？

Bjarne：对C++社群会有一些影响。一些程序员从事和特定运行环境（例如.NET、某种特定嵌入系统或UNIX变体）密切相关的编程。对于他们来说，和平台平滑地集成，就成了需要考虑的头等大事。

在微软.NET世界里，C++受到了足够重视，它仍将是一门举足轻重的语言，但在很大程度上，重心将不可避免地集中于和平台集成以及同以其它语言编写的代码进行互操作。从更长远的观点来看，人们将会获得某种程度的语言中立，而付出的代价则是严重的平台相依。这将会抑制对C++较新成分的试验，但是，鉴于为数众多的程序员只是不可理喻地使用C++的一个有限子集，所以，从短期来看，.NET可能实际上会成为“更好地使用C++”的一个激励因素。 

换句话说，我的内心和那些为平台中立和可移植性而奋斗的程序员紧密相连。对于这些程序员来说，轻巧的接口和平台中立的库至关重要。ISO标准则是纽带，它将各C++社群分支维系在一起，并阻止语言四分五裂为混乱的专有方言。 

RW：ISO/ANSI C++标准委员会开始讨论修改和扩充C++语言和库。您最希望看到什么样的扩充，抑或您最反对什么样的扩充？

Bjarne：我的指导思想非常简单：对于语言的扩充，我们应该小心谨慎，深思熟虑，而对于标准库的扩充，我们应该把握时机，积极进取。我的理由几乎同样简单：我们希望提高可移植性和稳定性，而修改语言是做不到这一点的。库就不一样了，假如我们拿到手的是一个烂库，我们可以把它扔在一边，而采用一个更好的替代品，也可以自己创建或购买一个“比从编译器厂商那儿得到的”更好的库。 

如今，人们对程序语言期望过高，形形色色的专有语言就泄露了这一点。通过不断扩大标准库的规模，这些期望可以轻而易举地得到满足 — 特别是，假如我们可以“象对iostreams和STL所做的那样”将大量的库组织为一个可扩展的框架的话。 

就象扩充标准库核心一样，对语言进行成功的扩充也需要一个正确的方向。在语言领域，我希望集中于小型设施，这些小型设施能使语言更为一致，并因而使语言更加易于学习和使用。这跟那些“对完成他们工作而不是语言细节更感兴趣”的程序员有什么关系呢？最显而易见的影响将会是标准库提供的新东西。一个规模更大的标准库，既节省开发劳动，也会降低对教学技巧的要求。早期C++的一个问题在于，即使对面向对象编程提供了良好支持，但它并没有提供一个优秀的库，以将OOP技术示范给用户看，这导致了大量的混乱和无稽之谈。泛型编程的引入工作做得要好一些，很大程度上是因为STL提供了一个学习和使用的具体范例。我多么希望我们早能有一个同样出色的例子，来展示异常（exceptions）的使用方法！

我正致力于设计开发一个名叫XTI（eXtended Type Information）的库，它为一般C++类型信息提供接口，用于内省（introspection）和程序转换（program transformation）。我希望看到诸如此类的东西能够进入标准库。一般而言，我希望看到对分布式编程更好的支持，并坚信那种问题应该由库来解决。 

RW：您认为C++编程的重要趋势是什么？

Bjarne：C++世界是如此之大，以至于你很难断定你所看到的东西到底是不是一种趋势。我猜想在嵌入社群C++的使用有大幅增长，但我对此不能确定。我知道对模板元编程（template metaprogramming）、泛型编程（generic programming）以及再生式编程（generative programming）感兴趣的人与日俱增，但我不能确定它们的群众基础到底有多么广泛。我猜测这些热门话题为先锋和学者们所津津乐道，其中部分而非全部新技术将会在接下来的几年里成为主流。看起来现在好像还有不少C++开放源码项目，但我也不能肯定。C++世界是如此之大，以至于没有任何个体可以完全理解它。 

象泛型编程这样的新技术和模板异常（template exceptions）这样的新语言工具，正慢慢进入开放源码社群（当然了，在我看来，这个进程还是太慢了）。我希望看到一些开放源码项目能够更多地采用现代编程风格。导致这种“保守”的现状的原因在于，开放源码社群无法让开发者们“欢聚一堂”，以确保所有人对工具和技术的看法，类似且跟得上时代。 

RW：C++已经成功到这种地步了吗 — 那些需要一种“具有C++设计标准”的语言的程序员会自动投向C++？

Bjarne：不然，世界并非如此简单。和所有人一样，程序员也会受到职业市场的影响。和所有人一样，程序员也易于过高估计新东西的优点而低估（或很少提及）其相应的缺点。当他们做出改变的时候，错误地以为他们不应该拉下什么重要的东西。注意，有时C++是一门“新语言”，人们投奔它的原因，和它技术上的优缺点毫无关系。在理想世界里，人们的选择客观而基于自身需要，但在现实世界中，我们往往流于主观，很少能够明了将来所需。结果，我们时而会萌生一种沮丧感。 

RW：和Java、C#以及Visual Basic不同，没有哪个人拥有C++，如此一来，它酷似Linux和其它开放源码项目，但它却没有开放源码运动那么大的诉求力，原因何在？

Bjarne：C++并非以“救世主”自居，它讲究实效，C++也没有什么“政治立场”，除非你蓄意将“非专有，由ISO标准委员会所掌控”划归为一个政治立场。而且，在一些地方，C++的某些替代品的支持者不公正地中伤C++，说它是“一种微软语言”。此外，也许我过于关注性能和规模问题了，我很少去迎合新手和学生的需要。当然了，我对骗局的厌恶，可能也妨碍了对C++进行有效的市场营销。 

RW：对于专有库供应者们的未来角色，您怎么看？

Bjarne：作为Addison-Wesley的“C++ In Depth”丛书编辑，我当然设法遴选重要且有意思的主题以及优秀的作者。我喜欢将库作为使思想和技术形象化的手段，这就是为什么你可以在我的编辑丛书中找到关于ACE、Loki和BGL方面的书籍。它们每一本都展示了技术思想 — 这些思想都不大知名且应用的也不象我所期望的那样广泛。然而，这并不意味我认为这套丛书所描述的每一个库都出类拔萃、尽善尽美。我总是期待更优秀的库。特别要指出的是，出版一本ACE图书，并不暗示比起商业库来我更偏爱开放源码库，两者角色都很重要。 

我不是商人，也不是经济学家，所以我不会宣称哪儿能赚到钱。不过，我的印象是，真正的基础性技术或真正的新思想并不能赚钱，人们更愿意把钞票花在和他们密切相关的应用上。几乎可以断定，成功的专有库和工具才是商机之所在。 

强固的工程、质量、规模、互通性、教学、维护和技术支持，是那些由“不要钱的程序员”所开发的软件需要一段艰苦的时间所要对付的问题。请注意，那些在较大范围内取得了成功的“免费”和开放源码提供者，是凭借“为了盈利”的计划而做到这一点的。就是程序员也有要吃饭的时候！ 

我注意到，在过去几年里，C++标准库的一些商业实现已经广为流行，因此，我看不出标准库有什么必要与商业库竞争。我希望C++标准库能够成为更为专门的库（它们大多是专有库）的优秀基础。 

RW：C为C++铺设了道路，您想像过C++为“下一种”语言铺设道路了吗？开发人员预期能够看到什么样的“范型转换” — 比方说procedural vs. OO？

Bjarne：我怀疑这个世界已经过于四分五裂了，不会存在什么单一的“下一种语言”，Java和C#都不是。 

还有，关于“范型转换”也被谈论过滥。面向对象编程并不是以“在各方面都比过程式编程优越”的姿态而来的。我对技术（techniques）或风格（styles）的思考甚于范型（paradigms）。C++支持好几种风格，它是一门多范型语言。这很重要，因为象“范型”这样的的鬼把戏只是倾向于不互相排斥，而“风格”则可以互相支持。 

所以，我宁愿不去猜想什么“下一种范型”的问题，我只预言它是否到来以及何时到来。你将会发现它和过程式、面向对象以及泛型技术互补，并能良好协作。 

RW：编译期计算（compile-time computation）能力是模板的设计目标之一，抑或只是意外之喜？ 

Bjarne：都有一点。我致力于获得“原始权力”，比如允许内联和合并调用与定义的上下文。我将注意力放在某些重要例子的弹性和效率方面，比如对数组元素求和。那么，再加上对一般性甚于专用特性的自然偏爱，以及对不必要的限制的憎恶，这就为我未曾梦想过的技术（比如STL）开辟了道路，其中，模板好比就是C++的另外一个组成部分。我不喜欢创建纯属意料之中的东西。 

RW：怎么才能让模板变得更易于开发人员学习呢？

Bjarne：我看不出有什么理由相信模板比类和类层次结构更会引起恐慌或难弄。当我引入类和类层次结构时，关于它们是如何得复杂、不安全、不好管、没有用的喧嚣，曾经震耳欲聋。 

可悲的是，很多程序员面对新概念畏缩不前。我想，部分原因是出于“当把它作为关键的工具时”而萌发的谨慎的天性，其它则源于脑力上的懒惰，对新事物可能会破坏舒适的旧时光的忧惧，以及软件业界诽谤竞争者的恶习。 

假如这些推断有道理，那么，当更多的人学习很好地使用新技术，当过度的狂热散去，当我们的工具品质改善时， 那些噪音就会逐渐消失。和其它方法相比，模板能够以更简单的方式，表达某些重要的技术和解决方案，并能产生更有效率的代码。表达简练且速度快的代码，最终总是赢家。

评论