Bjarne Stroustrup专访：编程语言的演变_bjarne stroustrup的编辑器-CSDN博客

本文链接：https://blog.csdn.net/bigwindlee/article/details/3410618

原文：

An interview On the evolution of languages for MSDN Magazine by Howard Dierking. Vol 23, No 5. April 2008.

http://msdn.microsoft.com/en-us/magazine/cc500572.aspx

作者：

MSDN Magazine总编Howard Dierking

每隔一段时间，都会出现一场进化式的飞跃，它迅速的促进和改善整个工程领域。在软件开发领域，C++编程语言的诞生就引发了这种飞跃。这并非出自于该编程语言本身：面向对象语言，如Simula67和Smalltalk，其实在C++之前就已存在。但由于C++建立于C编程语言之上(且可编译现有的C程序)，因此能够将面向对象的观念导入主流。

从设计模式到元编程，C++为软件设计和发展方面带来不少启发。并且由于在硬件平台之间的可移植性，及其低阶表现能力，C++一定能够成为速度更快、体积更小之硬件趋势的主力语言。

我最近有幸采访了C++的发明人Bjarne Stroustrup，并向他请教一些相关主题，包括他对于编程语言的想法、产业的趋势，乃至于他个人所阅读的书籍。我在讨论过程中提出的诸多问题，皆来自于我blog上由读者提供的建议，因此我要感谢所有帮忙提问的朋友。此外，当然还要感谢Bjarne。

关于编程语言

Howard Dierking (HD) 编程语言为何与人之间有着如此深层的关系，甚至还因此形成语言狂热份子这样的群体？

Bjarne Stroustrup (BS) 关于这个问题，您应该和心理学家、社会学家，或者与经济学家请教，而不是计算机科学家吧！我猜想或许是因为人类用来表现想法的语言，会成为自身的一部分，因此若您只懂得一种语言，就会对其他语言的支持者产生威胁感。在这种情况下，解决的方法就是要深入了解更多种类的语言。若您仅懂得一种编程语言，我实在不认为您能够成为软件界的专业人士。此外尚有经济考虑：虽然基础知识的理解能跨越编程语言的界限，但许多实际的技巧则非如此。因此如果我只会X语言及其工具，而您却主张Y语言及其工具，那么您就实际威胁到我的生计。再次重申，解决的方法是多了解各种语言及其工具 (并具备扎实的基本功)。不幸的是，多数人在完成必要的工作之后，已经没有多少时间，因此无法采纳我建议的解决方法。不过这对于狂热份子则不具任何影响。

HD IDE在软件开发中应该扮演何种角色？IDE应该如何支持编程语言？

BS 我其实不太使用IDE。IDE编辑器若能懂得我所使用的语言固然很好，但我也希望能够在没有IDE的情况下工作。若有一个可通用且优异的IDE，我或许就会有不同的看法，但事实上，IDE大多只适用部分语言或反之亦然 (请参阅 [图 1])。我对于程序代码可移植性的渴望亦展现于此。使用C++时，我希望能直接从原始程序文件的原始码中了解我的系统。我十分不喜欢涉及转换或产生动作的IDE机制，因为这些无法以人类容易理解的方式呈现程序代码。

Figure 1 The IDE Designer as a Language

HD 您是否认为可读性是影响现今通用编程语言的主要问题？如果是，应如何解决？

BS 如果有更简单的语法当然不错，不过我怀疑多数人对于可读性问题的抱怨，并非就实际文字，而是其内容所表达的复杂程度。有太多人都期望靠着在线支持的机制，就能够应付任何语言所撰写的程序，亦即了解该程序的所有结构及其所有逻辑。就以这点与自然语言的用法相比较，难道您认为可以在毫无背景知识的情况下，了解莎士比亚的十四行诗？如果遇到古英语写的贝奥武夫又该怎么办呢？也许，我们对于编程语言的期望过高了。若一种语言能提供各种应用程序领域所需，那么此语言对于该特定领域而言可能就已过度复杂，然而，它必须应付原本就未系结的应用程序组合。某一领域专用的语言只能适用于特例，但是现在我们必须面对多种语言及其交互所带来的复杂问题。

HD 通用编程语言该如何支持应用程序设计理念，例如如组件编程和服务编程？

BS 通用语言应支持编写可表达常规和特定于应用程序概念的库，支持工具构建以及提供连接应用程序的不同部分所需的“粘合剂”。为达到上述目标，编程语言需要有弹性、富有表现力的型别系统、良好的基本性能，以及长期的稳定性。

HD 多重分派是否好用？

BS 没错。传统单一分派面向对象的程序设计语言(例如 Simula、C++、Smalltalk、Java 及 C#)无法轻松准确表达出在运行期才确定型别的简单动作，例如数字相乘或寻找两个形状的交集处等。而仰赖于双重分派、visitor模式之类的代码又太慢，且不如我们预期的容易维护。在运行期支持多重分派的语言(如Dylan和 CLOS)较为好用，而可在编译期支持此功能的语言(如C++)有时亦有所帮助。去年，我和几位学生共同发表了一篇研究论文，题目是如何在C++中轻松加入多重分派功能。结果是，使用多重分派的程序代码用例较简短、使用较少内存，且执行速度比所有我们讨论过的解决方法都来得快 (请参阅 [图 2])。不过这份研究对C++0x而言则是为时已晚。您可以造访research.att.com/~bs/multimethods.pdf阅读相关论文。

Figure 2 Multiple Dispatch via Multiple Inheritance

HD 您对于现今C++的共异变量/反异变量有何看法？您是否预期未来的编程语言版本将会改变目前的行为呢？

BS 不见得如此。就该部分而言，我认为C++可以胜任。您有没有考虑过将vector<Apple>转换成vector<Fruit>这类示例？这样做非常不安全，除非vector<Fruit>是固定不变的（或者可向其添加Orange）。我不认为隐式运行期型别检查是用于解决此类问题的好方法。

HD 和方法调用比较起来，您对于将消息传递做为主要语言功能有何看法？

BS 我喜欢明确的消息传递，不过我是很久以前在分布式系统中使用的。实际上若要运用在大型架构中，我们必须针对消息传递的语言和工具支持上认真的下工夫。我认为这样的工作尚未完成，但我的看法也有可能是错的。若您采用消息和消息队列，有许多与共享和锁定相关的问题都会消失。我乐见能出现此用途的标准C++库，也许过几年就有了。

HD 如果既要支持千差万别的诸多受众，又要鼓励改进代码表现力和设计简洁度，这对通用编程语言而言是否存在固有冲突？编程语言对于后者的支持应该扮演何种角色？

BS 我想您可以透过专门化来达到简洁性的目的。此外，若您的受众是小型团体 (用户社群)，则可投其所好，这样就有可能在控制使用者社群的情况下，撇开传统的表示法和概念(例如「您必须研读型别理论，方可使用」)。通用编程语言不仅受限于需要支持多种用途，还必须易于教导有各种预设想法与教育背景的对象 (基本知识必须能够适用于高中生，且是在师资不足的情形下)。

因此我认为通用编程语言只要能表现完整，促进其简洁性就没有问题。以 C++而言，就可以撰写极为简洁的程序代码。此编程语言适合一般用途，且使用率广泛，这样的范例能够为数以百万计的人使用，且可写入文章及教科书内供数百万人阅读。专门化的编程语言无论有多优雅都无法达到这样的境界。

HD 我们是否太过度强调架构的重要性？

BS 不会，至少对我定义的架构来说不是这样。恰恰相反，架构的重要性其实缺乏强调，且由于不够了解结构性原则，而经常导致产生不良的程序代码。我怀疑架构的主要问题，在于许多程序设计人员对于优良程序代码的条件并没有清楚的概念。能够在看到的时候辨识出优良的程序代码，其实还不够。仅以负面教学的方式订立限制规则也是不足。我们需要清楚的既定规则。

HD 开源社区对于软件质量、设计和职业水准是有利、有弊或者毫无影响？

BS 这真是个很难回答的问题。我看到过能有所帮助的情况（提高了代码质量以及相关人员的职业水准），也遇到过有损害的情况（教导极为不良的习惯与态度），还有许多情况我也说不清。

我无法猜想对社区产生的普遍影响，或者如果开源工作的力度更大一些或更小一些，会发生什么情况。对我来说，社区太大了，猜不透。

编程语言的趋势

HD 您是否认为在不久的将来会倾向使用动态语言？

BS 我不太认为会这样。我认为人类太喜欢拿各式各样的东西来做比较。我不认为我们需要在静态和动态语言之间做选择，此外，我更不相信语言能够明确的分属于这两种类别：就算不是全部，至少有多数的动态语言都具有静态判断的层面，而所有主要静态语言也都有需要在运行期判断数值意义的工作。当然，有些暂时性的趋势是我无法猜测的，但我认为许多实际情况下的语言选择，都是根据应用程序的需求、应用领域，及 (或) 开发人员具备的技能等所做的理性判断。例如，我不会尝试使用Ruby来实现Java运行时，也不会用C++表达交互性很强的模拟语言（这一点与它的实现相反）。

HD 您是否认为最终移除所有 void*/variant/object等项目是正确的做法？([图 3] 是很好的范例)。

Figure 3 Polyhedron Sample

BS 删除所有内容包罗万象的选项从理论上是个好主意，但实际上我们必须将所有要表达的内容完全归成单一类别，才能达到这个目的。例如，我从未看过一个可以操作所有对象的函数；不论要做什么，都必须假设某些条件 (纯转发函数是我所能想到最接近的反例)。目前在C++世界里涉及concepts的工作 (constraints/requirements on generic algorithms)可以有所帮助，但我认为在没有真正能表达「一切」东西的通用机制(虽然我不知道「一切」是什么)的情况下，亦即还是会有无法预期的需求，我们恐怕无法达到这样的目的。

HD 随着松散类型语言又成为了流行趋势，我们是否应再次开始考虑匈牙利标记法呢？

BS 我并不确定有这样的趋势，不过或许就整体而言确实有少数适合松散式语言的部分增加了。换言之，静态型别语言的使用仍可能继续成长(就我认为)，只是松散式语言的成长率更高而已。但请不要使用匈牙利标记法。选用匈牙利标记法不是个好主意。源代码应该反应出程序的意义，而非仿真型别系统。若您真的认为需要使用匈牙利标记法，那么您所使用的编程语言可能并不适合您的应用程序。

HD 在2000年，您做过一场讲座，题目是《C++: A New Language for a New Millennium》，其中介绍了Wrap<T>的概念。基本上这是面向方面程序设计 (Aspect-Oriented Programming，AOP)。您对于AOP(一般而言) 及其Wrap<T>模式的成形 (pointcuts、advice...等等) 有何看法？

BS 我尚未花足够的时间来了解AOP，无法提出确切的答案。我喜欢语言可支持组合功能 (尤其是非侵入式)的特点，较不认同「不支持」以及「由工具支持」的语言。我觉得额外的语言工具以及非标准工具都会提高复杂度。C++模板的非侵入式组合功能极为成功，Standard Template Library (STL)及嵌入式系统程序设计中的一些运用就是很好的范例。能够结合各种想法，而不强迫纳入刻板或预先设计的层次架构中，是极为强大的能力。然而，就管理上对于某些开发人员和维护人员来说，也有其困难之处。在标注上也是十分繁重的工作。C++0x已试图在不影响弹性和性能的情况下解决上述问题。

HD C++语言有某些特性(例如宏)具有造成非预期结果的问题。您希望看到C++或一般现代编程语言中去除混淆那些非预期结果的问题吗？

BS 事实上，我从开始使用C就知道宏的麻烦；但和多数人一样，我低估了这些宏造成麻烦的程度，以及弥漫的负面影响。在C语言中大量使用宏，或许就是我们十年前无法实现优秀C++开发环境的主要原因。此外，C++有太多太令人混淆的对象初始化方式，我希望能在C++0x中采用统一的机制来解决这个问题。我在上一个问题的答案中提到了模板。模板是后来的C++(1985之后)取得成功的主要因素，但这项成功却影响了编程语言本身的发展，同样的，有部分C++0x的功能会专对这个问题进行处理。

由于兼容性原因，C++无法解决我们在过去所发现的许多小问题和不大不小的问题。例如，声明符语法没必要这么复杂，其实任何线性标记法都更好。此外，许多默认值也存在错误：构造函数不应默认为转换，名称不应默认为可从其他源文件访问等等。不能控制链接程序一直是问题根源；特别是实现者似乎喜欢以不兼容的形式提供类似的功能。

另外也有些不错的惊喜。最棒的应该是在与资源管理和错误处理（使用异常）相关的技术中普遍使用了析构函数。我知道析构函数是个不错的主意(毕竟得逆转构造函数的效果)，但我并未发现这利用在C++的重要性有多高。

HD 您在网站上曾经说：「我认为我们应该完善所构建的应用程序，而非完善语言本身」。请问使用域特定语言 (Domain-Specific Language，DSL) 的趋势是否集中体现了您的这一说法？

BS 是的，几乎是无庸置疑。通常都是朝这个方向迈进。有时候甚至有成功的迹象。

HD 您对于DSL有何看法？您对于DSL和通用编程语言之间的关系有何展望？

BS 我担心的是许多语言在设计、实现和引进时声势浩大，然后就销声匿迹，没有任何显著的实效。在这样的过程中 (通常需要多年的长期开发工作)，新的语言需要消耗大量的资源，却不会获得任何回报。我为这样的现象特别撰写了一篇报告，标题为《A Rationale for Semantically Enhanced Library Languages》(research.att.com/~bs/SELLrationale.pdf)。我在文中主张使用库 (可能通过工具来支持)，以及通用编程语言。

我认为 DSL 应该是逼不得已的选择，而非首选。在可能的情况下，DSL 应该完全融入通用编程语言和标准工具链接。DSL需要通用编程语言 (至少需要系统程序设计语言)才能实作，其执行阶段基本功能也是一样。我认为DSL若能确实与至少一种通用编程语言结合，以便轻松藉由使用该编程语言撰写链接库来加入新的机制，这会是比较好的做法。显然，专业人士都必须掌握多种语言，但我不禁怀疑各种DSL复杂度的累加可能进而演变成更大的问题。此外，许多(即便不是大多数)DSL都希望「成为」通用编程语言。

HD 您提到C++有许多建构是故意维持模棱两可，以符合不同硬件迥然的定义。您认为互通性的发展，是否可能消除某些建置模棱两可的状态？

BS 「模棱两可」是个错误的用词。有太多东西都是未定义 (Undefined) 或由实现环境决定(Implementation-Defined)。我怀疑如果我可以从头开始重新定义 C++，就不会有未定义的行为产生，也会有较少由实现环境决定的部分。不过，我可没有时光机器，所以当然不可能现在就挑出一组解决方法，立刻解决上亿行程序代码的问题。

方法论和最佳实践

HD 您常使用和教授哪些处理序方法论？

BS 确定主要应用程序概念、确定有用的链接库、建立新库来支持应用程序概念、尽早尝试各种想法、尽早集成、尽早并经常测试、使用文档和教程教材作为设计工具，并且从小型程序逐渐发展为大型程序(迭代式开发)。显然我刚才侧重的是相对较小的项目。

HD 您是否认为语言和开发方法论之间有任何交集或相似处？

BS 是的，将库设计视为一种设计或开发技术的话，我认为是这样的。通过库构建来关注越来越高级（更接近应用程序）的功能，这将对语言提出了要求。我不想过分夸大这一点，但是我认为您不能拥有用于（例如）COBOL、C、Java、C++ 以及 Python 的单个开发方法，而又期望从每种语言获得更多的支持。

HD 您对于建立软件有哪些个人原则？

BS 注重关键概念、它们的接口、资源（内存、文件、锁等等）的管理和错误处理。为类设计良好的不变体和“资源获取即初始化”(RAII)都是关键技术。

HD 有许多人都在讨论「敏捷度 (Agile)」。「敏捷度」对您而言有何意义？C++是否具有敏捷度？

BS 我从不用这个词；因为太模糊了。C++当然支持敏捷度，不管这个词代表什么意思。

展望未来

HD 编程语言要如何逐渐演进，以支持进阶功能 (例如模板、动态事件以及代码自动生成)，同时又保持可让初学者容易上手的特性？

BS 我也不知道。我并不认为这个问题有固定的答案。如果新功能支持更有效的技术，就是重要的功能。但是，稳定性至关重要：C和C++之所以能够屹立不摇的原因，就是标准委员会致力于保护旧程序代码(通常约有十年之久)维持有效，且能让新功能顺利地整合。要这样做并不容易，新功能的推出不一定都会成功。需要时，委员会成员通常会忽略与初学者相关的问题。有些为 C++0x 所设计的主要功能，例如统一初始化、auto关键词 (从其初始化表达式推断出变量型别)，以及诸如检查模板参数需求等概念，就是要让非专业人士更易于使用这个语言。

HD 您认为语言元数据将成为未来程序设计语言的主要基础吗？

BS 不。我个人并不赞同在关键的地方运用元数据。

HD 如果CPU开始上升为多核，您是否预见未来并行处理方面会有根本上的变化？C++0x会如何解决并发性挑战？

BS C++0x有提供基本功能：适用于多线程的机器模型、一组可构造库的低阶基本功能，以及线程和锁的库API。我很希望能看到更多这方面的发展(或许在未来几年间就会有)，尤其是以线程池、未来功能和消息队列为基础的更简单、更高阶的并发模型。我们需要找出自动化或近自动化的方式，将运算作业散布到多颗处理器上，并于这些处理器上有效执行本机活动。这个领域有许多工作正在进行(C++就有很多进展)，但尚未成为主要模型。范例包括Texas A&M大学的STAPL，以及Intel的TBB。

HD 您对于通用运算图形处理单元(General-Purpose Computing On Graphics Processing Units，GPGPU)有何看法？

BS 很吸引人，但我并没有实践经验，所以无法提供意见，我只能说这是需要高度的技巧才能运用的特殊用途处理器。

HD 您是否认为高效能运算 (HPC)对于程序设计人员而言终将透明化？此外，这究竟应该是编程语言的目标，亦或是库或framework的目标？

BS 部分透明；我不认为并发性可以或应该完全透明。对于初学者而言，错误处理可能会非常困难，具体取决于处理器的可用性、有无共享内存、分布与否以及延迟。在适当的地方接近透明现在是并将一直是新语言、新语言功能以及（我最喜欢的）新库的目标。仅当底层语言提供了作为机器模型所需的基本保证以及一组非常底层的原语(primitive)，后者才可行。C++0x 将会做到这一点。

HD C++0x的设计进展如何？

BS 即将完成！至少我是这么希望，不过一切都要等到票选结束才能确定，愈接近尾声，大家也将会愈紧张。目前的计划是要票选出完整的新标准，并于六月供公众评论，这样12到18个月后就能产生新的正式标准。显然我可以针对这个主题出一本书了：如何订立标准，这有哪些指导原则，而其中究竟涵盖了哪些内容？其实我几乎是完成了一本书；请参阅我的 HOPL 报告《Evolving a language in and for the real world:C++ 1991-2006》(您可以从research.att.com/~bs/hopl-almost-final.pdf 下载)，以及我的网页上所有标题中有「C++0x」的相关文章。若您酷爱找碴，可以在网络上搜寻「WG21」，即可找出所有ISO C++标准委员会的报告(包括所有提案)。至少您应该可以了解到，这的确是个浩大的工程。要改进常用的程序设计语言十分困难，尤其是已经用于开发许多工具、语言及应用程序的系统编程语言。您也可以在在线和我的C++网页上，找到由我和其它人制作的一些视频资料。

书籍和电话

HD 请问您最近都在阅读哪些书籍？

BS 就技术书籍方面，我重读了Hennessy和Patterson撰写的计算机体系结构方面的书，同时也在收集一些可帮助大家撰写优良程序代码的报告和文章(为了我所教授的一门课)。寻找这类文章远比我想象中困难；学术论文都太过专精，而非学术论文通常又太过哗众取宠而实际作用又不大(欢迎推荐)。当然，我还要阅读一系列与C++标准化相关的文件。我正准备重新整理Knuth的书籍，但有人拿走了第三册，所以得过阵子再进行了。工作之余，我正在重新阅读一些O'Brian's Aubrey和Maturi的系列书籍。我也试着更新自己对于科学的理解，因此目前刚看完Richard Dawkins。我最近也才读完Rodger的<<Command of the Ocean:A Naval History of Britain>>，1649-1815 (因此会去看 O'Brian)。