Bjarne Stroustrup报告语言的演变
副标题#e#
目次
对语言的观点
语言成长趋势
要领和最佳实践
展望 将来
书籍和电话
偶然， 进化中的奔腾会迅速改进并重塑整个工程规模。 在软件开拓规模，C++ 编程语言的降生就激发了此类奔腾。这种奔腾并非此语言自己所固 有的。在 C++ 之前即已存在面向工具的语言（如 Simula67和Smalltalk）。但由于 C++ 是在 C 编程语言的基本上构建的（而且可编译现有的 C 措施），因此它可将面向工具思 维的精华带入主流。
C++ 在软件设计和开拓方面提供了大量的灵感，从设计模式 到元编程莫不如此。而且由于其可在硬件平台间移植并具备更底层的暗示，跟着硬件变得 更快更小，C++ 必定会成国家栋梁。
我最近有幸采访了C++ 的发现者 Bjarne Stroustrup，其间谈及了多个话题：从他对语言的观点、行业的普遍成长趋势到他小我私家阅 读的书目。个中很多问题都是读者们通过我的博客所提出的，在此特向那些提出问题的人 员暗示感激。虽然，更感激 Bjarne。
对语言的观点
Howard Dierking 为 什么编程语言与人们之间有如此深的关联—以至各类语言都有了本身的“追星 族”？
Bjarne Stroustrup 这个问题最好是问问心理学家、社会学家，甚至 是经济学家，而不是一个计较机科学家！我意料由于我们用来表达思想的语言已成为自身 的一部门，因此，假如您仅相识一门语言，则很难与其他语言的支持者举办相同。假如是 这样，看起来必需要能干更多的语言。我认为，假如您仅相识一门编程语言，就不行能成 为软件规模的专家。大概尚有经济方面的原因：尽打点解根基道理可不受编程语言种类的 限制，但很多实际能力则纷歧样。因此，假如我仅相识语言 X 以及其东西集，而您赞成 语言 Y 及其东西集，那么我们之间就会存在障碍。要想超过这一障碍同样需要把握多种 语言以及东西集（而且安稳把握根基道理）。遗憾地是，我所发起的办理方案并未思量到 大大都人没有几多空闲时间。那些狂热的粉丝是特例。
HD IDE 在软件开拓中应扮 演何种脚色？IDE 应如何对语言举办支持？
BS 我并不常常利用 IDE。我赞赏那些 可领略我的语言且回响迅速的 IDE 编辑器，可是也但愿正常事情时不必用到 IDE。假如 机能精采的 IDE 能得以普及，我大概会改变概念—即 IDE 实际成为语言的一部门 ，反之亦然（请拜见图 1）。我所但愿的代码可移植性在此会有用武之地。通过利用 C++ ，我但愿通过源文件中的源代码就能领略我的系统。有些 IDE 机制包括的转换或生成代 码很是未便于领略，我对此很不浏览。
Figure 1The IDE Designer as a Language
HD 您是否定为无用信息或 可读性是当今通用语言中所存在的一个问题？假如是这样，应该奈何办理呢？
BS 语法越简朴越好，但我意料当大大都人在谈到可读性时，对付实际文字的诉苦并不多，表 达内容的巨大性往往招来的诉苦更多。太多人都但愿能相识以任意语言编写的任何措施， 并但愿在线支持东西只提供少量辅佐就可以领略用于表达措施的所有布局和措施自己的所 有逻辑。我们可以将其与查察并利用自然语言的方法做个比拟。您是否但愿无需配景常识 即可领略莎士比亚的十四行诗？假如碰着原始古英语写的贝奥武夫又该怎么办呢？也许， 我们对付编程语言的期望过高了。对付任意特定的应用措施而言，假如任何语言所表达的 内容合用范畴很大，往往会被视为过于巨大，可是实际上语言必需要适应多种应用措施。 某一规模专用的语言只能合用于特例，可是此刻我们必需面临多种语言及其交互所带来的 巨大问题。
HD 通用语言应如何支持应用措施设计理念（如组件编程和处事编程） ？
BS 通用语言应支持编写可表达通例和特定于应用措施观念的库，支持东西构建 以及提供连策应用措施的差异部门所需的“粘合剂”。为此，语言需具有机动 性、富有表示力的系统、精采的基本机能以及恒久不变性。
#p#副标题#e#
HD 多重分配是否是件 功德？
BS 是的。传统的单一分配面向工具编程语言（如 Simula、C++、 Smalltalk、Java和C#）无法完美地表达详细范例要到运行时才知道的简朴操纵（如将数 字相乘或查找两个形状的交集）。生成代码（由双重分配、会见者模式等因素确定）很慢 而且不易维护。在运行时支持多重分配的语言（如 Dylan和CLOS）要好些，而在编译时支 持多重分配的语言（如 C++）有时结果更好。去年，我和我的一些学生一起宣布了一篇有 关如何向 C++ 清晰添加多重分配的研究论文。与我们看过的所有办理要领对比，利用多 重分配时生成的代码更短、更简朴、占用的内存更少，而且运行速度更快（请拜见图 2） 。固然对付 C++0x 而言，该事情太晚了。您可在 research.att.com/~bs/multimethods.pdf 中找到相关的文章。
Figure 2Multiple Dispatch via Multiple Inheritance
HD 您对此刻 C++ 中的协变/逆变是什么观点？您是否但愿在将来的语言版本中改变当前的行为？
#p#分页标题#e#
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 显示了一个不错的示例。）
BS 删除所有内容包含万象的选项从理论上是行得通的，但在实际中，前提条件是 我们必需对要表达的所有内容举办完整分类，以便确保针对性。譬喻，我从未看到过实际 有函数可对每个工具执行操纵；想要执行操纵，始终需要对所操纵的内容举办一些假定（ 我认为纯粹的转发函数是最靠近计数器示例的函数）。当前在 C++ 观念方面的事情（有 关泛型算法的约束/需求）可以提供辅佐，可是假如缺少一些实际的通例机制来表达 “是我确实不知道的内容”，就不能处理惩罚意外需求，我们也就无所作为。
HD 跟着松散范例语言又成为了风行趋势，我们是否应该从头思量匈牙利暗示法？
#p#分页标题#e#
BS 我不必定有这种趋势，尽量在总体事情中，适合松散范例语言的份额大概有所 增加。换句话说，固然松散范例语言的利用率增加得更快，静态范例语言的利用率也在增 加（我认为是这样）。可是毫不要利用匈牙利暗示法。那是个很糟糕的主意。源代码应该 反应措施的内在，而不是模仿范例系统。假如确实以为需要利用匈牙利暗示法，大概是使 用的语言与应用措施不搭配。
HD 在 2000 年，您做了一场讲座，题目是 “C++：用于新千年的新语言”，而且先容了Wrap<T> 这一观念。这基 本上就是面向方面的编程 (AOP)。您对 AOP 及其 Wrap<T> 模式（Pointcut、 Advice 等等）的形式化有何观点？
BS 我对付 AOP 的研究不多，因此不能给出一 个靠得住的谜底。我喜欢在语言中支持组合（尤其长短入侵式），而不是“不支持 ”和“通过某个东西支持”。我担忧的是超语言东西和非尺度东西链。 C++ 模板在非入侵式组合方面极其乐成 — 只需看看尺度模板库 (STL) 和一些嵌入 式系统编程中的利用环境就能相识这一点。要是举办组适时不必将观念强行放入刚性或预 先设计的条理中，那虽然不错。然而，对付某些开拓人员和维护人员而言，太难于打点了 。而且过分沉重。C++0x 将实验在不影响机动性和机能的环境下办理这一问题。
HD C++ 语言的某些特征大概会发生一些令人讨厌的意外功效（好比宏）。您但愿 C++ 或常见的风行语言能消除其他哪些意外功效？
BS 实际上，当我开始利用 C 时，我就知道宏很是令人头疼；可是与大大都人一样，我对它造成的贫苦和普遍的负面影 响照旧预计不敷。在 C 中普遍利用宏大概是十年前 C++ 开拓情况不尽人意的主要原因。 而且 C++ 中初始化工具要领还太多太杂乱；我但愿在 C++0x 中利用统一的机制来办理该 问题。我答复上一问题时提到过模板。它们使厥后的 C++（1985 年宣布）取得了庞大的 乐成，但对语言也有负面影响—同样，C++0x 中有一部门内容会专门办理这一问题 。
由于兼容性原因，C++ 无法办理我们在已往所发明的很多小问题和不大不小的 问题。譬喻，声明符语法没须要这么巨大，能说明任意线性暗示法就足够了。另外，很多 默认值也存在错误：结构函数不该默认为转换，名称不该默认为可从其他源文件会见等等 。不能节制链接措施一直是问题来源；出格是实现者好像喜欢以不兼容的形式提供雷同的 成果。
虽然也有意外的收获。个中最精彩的是，在与资源打点和错误处理惩罚（利用 异常）相关的技能中普遍利用了析构函数。我知道析构函数是个不错的主意，因为您总会 需要用到结构函数的逆向成果—可是，对付它们在公道利用 C++ 方面的重要性，我 还不太相识。
HD 您曾在本身的网站上说道：“我认为我们应该力争完善所 构建的应用措施，而不是完善语言自己。”在域特定语言 (DSL) 方面的成长是否就 会合浮现了您的这一说法？
BS 是的，这是很明晰的。它常常向这个偏向做实验。 有时甚至会到达预期的结果。
HD 您对付 DSL 的主要观点是什么？您设想 DSL 和 通用语言之间是奈何的一种干系？
BS 我担忧的是很多语言在设计、实现和引进时 声势浩荡，然后就鸣金收兵，没有任何显著的实效。在此期间—凡是是多年的恒久 开拓—新语言淹灭了大量资源，却根基没有回报。我曾写过一篇有关此现象的文章 ，名为“语义加强库语言的根基道理” (research.att.com/~bs/SELLrationale.pdf)。我赞成利用库（大概通过东西来支持）和 通用语言。
我认为 DSL 应是不得已而为之的步伐，而非首选要领。假如大概的话 ，DSL 应紧紧地根植于通用语言和尺度东西链之中。DSL 需要通用语言（可能至少是系统 编程语言）完成自身实现并实现其运行时基元。我认为最好是 DSL 有意识地与至少一门 通用语言不变共同利用，这样即可通过利用以通用语言编写的库来轻松地添加新成果。专 业人员自然应把握多门语言，可是我担忧各类 DSL 的巨大性搜集起来大概发生问题。并 且，很多 DSL 好像都“想”成为通用语言。
#p#分页标题#e#
HD 您提到过由于差异硬 件存在界说的多样性，所以 C++ 中的很多结构有意恍惚不清。您有没有发明互操纵性方 面已经做出了改造，让一些这样的结构变得明晰了？
BS 我认为“恍惚不清 ”这个词并禁绝确。太多对象都没有界说可能要在实现时才界说。我想假如能从新 从头界说 C++ 的话，它大概会没有未界说的行为，要在实现时界说的行为也会少很多。 可是，我没有逆转年华的呆板，也不能用此刻的一组决策毁掉亿万行代码。
要领 和最佳实践
HD 您较量喜欢利用和教授哪种进程要领？
BS 确定要害应用程 序观念，确定有用的库，构建新库以支持应用措施观念、尽早试验想法、尽早集成、尽早 且常常举办测试，将文档和教程资料用作设计东西，而且从小措施生成大措施（重复）。 显然我适才偏重的是相对较小的项目。
HD 您有没有发明语言和开拓要领之间存在 交错或密切干系？
BS 库设计被视为设计/开拓技能时，我认为是这样的。通过库 构建来存眷越来越高级（更靠近应用措施）的成果对语言提出了要求。我不想过度夸大这 一点，可是我认为您不能拥有用于（譬喻）COBOL、C、Java、C++ 以及 Python 的单个开 发要领，而又期望从每种语言得到更多的支持。
HD 在建设软件时，您小我私家有哪些 履历法例？
BS 注重要害观念、它们的接口、资源（内存、文件、锁定等等）的管 理和错误处理惩罚。为类设计精采的稳定体和“资源获取即初始化”(RAII) 是关 键技能。
HD 对付火速有各类说法。“火速”对您意味着什么？C++ 是 否支持火速？
BS 我不利用这个词，它太暗昧不清。C++ 虽然支持火速—无 论它暗示什么意思。
展望将来
HD 一种语言应如何成长才气既支持高级功 能（如模板、动态事件以及自我编写的代码），同时又能让新手领略这种语言？
BS 我不知道。我想并不存在一个通用的谜底。假如新成果支持更有效的技能，那 么它们就在语言中占有重要的职位。可是，不变性至关重要：C和C++ 保持效力的一个原 因是尺度委员会要求旧代码（凡是有十年的汗青）仍然有效且可顺畅地集成新成果。至少 可以说这并不太容易，而且引入新成果并不老是乐成。尺度委员会成员常常忽视新手因素 。为 C++0x 打算的一些要害成果（如统一初始化、自动要害字（从其初始化表达式揣度 出变量范例）以及如查抄模板参数要求等观念）应能使语言更易于被普通人员利用。
HD 您是否将语言元数据看作将来编程语言的重要基本？
BS 不，我小我私家非 常不喜欢大量利用元数据。
HD 假如 CPU 开始上升为多核，您是否定为并发性未 来会产生重大转变？C++0x 会如何办理并发性挑战？
BS C++0x 具备基本：合用于 多线程的呆板模子，用于构建库的一组基本基元以及线程和锁定库 API。我但愿看到（可 能在此后的几年里）更多这类坚硬的基本，尤其是更为简朴且级别更高的并发模子，它们 以线程池、成果和动静行列为基本。我们需要找到自动或近似自动的要领，将计较漫衍到 多个处理惩罚器并在这些处理惩罚器长举办局部处理惩罚。在这一规模中已有很多模子（很多是利用的 C++），但都还不是主要模子。示例包罗德克萨斯 A&M 大学的 STAPL 和英特尔的 TBB。
HD 您对图形处理惩罚单位 (GPGPU) 方面的通用计较有什么观点？
BS 非 常着急，但除了操作特定用途的处理惩罚器需要多种技术这一明明现象外，我并没有实际履历 可做出更多评论。
HD 您是否预见高机能计较 (HPC) 最终会对编程人员透明？此 外，它是否会成为语言、库或框架的方针？
BS 略微有些透明；我不认为并发性可 以或应该完全透明。对付初学者而言，错误处理惩罚大概会很是坚苦，详细取决于处理惩罚器的可 用性、有无共享内存、漫衍与否以及延迟。在适当的处所靠近透明此刻是并将一直是新语 言、新语言成果以及（我最喜欢的）新库的方针。仅当底层语言提供了作为呆板模子所需 的根基担保以及一组很是底层的基元，后者才可行。C++0x 将会做到这一点。
HD C++0x 的设计希望到什么水平了？
BS 顿时要最后落成了！至少我但愿如此 —在呈现最终功效前，谁都预料不到会出什么变革，越靠近完成，情绪越告急感动 。当前的打算是在六月选出完整的新尺度以供公家评论，12 到 18 个月后出台一个正式 的新尺度。我完全可以环绕这个主题写一本书：如何拟定尺度，指导目的应该是什么以及 个中详细有些什么？这些内容我根基都写到了，请参阅我的 HOPL 文章“在现实世 界中不绝改造语言：C++ 1991-2006”（位置为 research.att.com/~bs/hopl- almost-final.pdf）以及我主页文章中有关 C++0x 的所有内容。假如您的要求很高，可 在 Web 上查找“WG21”并搜索所有 ISO C++ 尺度委员会的文章（包罗所有建 议）。它至少可以让您确信个中包罗大量事情。改造一门利用遍及的编程语言很是坚苦， 假如语言处在很多东西、语言和应用措施的实施层就更坚苦。您还可以在网上和我的 C++ 页面上找到很多我和其他人提供的视频资料。
书籍和电话
HD 您今朝在看 什么书？
#p#分页标题#e#
BS 技能资料方面，我重读了Hennessy和Patterson 撰写的计较机体系结 构方面的书，还在尽力收集可以辅佐人们编写精彩代码的文章和书籍（我正在教的一门课 也能用到）。查找此类文章的难度超出了我的想象；学术文章过分专业化，而非学术文章 往往说得好听，实际浸染又不大（接待提供发起）。虽然，我还读些 C++ 尺度化方面的 文章。我原筹备重读 Knuth，但由于有人偷偷拿走了我的第 III 卷，所以只好再等等。 我还将再读一遍 O’Brian 的 Aubrey和Maturin 系列，就当是个消遣。为了加深对科 学的领略，今朝规划拜读 Richard Dawkins。我最近还读完了Rodger 的《Command of the Ocean:A Naval History of Britain, 1649-1815》（因此筹备读 O’Brian 的书 ）。
HD 您曾说过：“我已往经常但愿我的计较性能像电话一样容易利用； 此刻这个愿望终于实现了，我不消再操心研究电话用法了。”您有智能电话吗？它 的操纵更简朴了吗？
BS 我并不太热衷利用电话。我更喜欢面劈面的交换，假如无 法面劈面，用书面文字也行。即便最炫的电话也比不上一封说话完美的电子邮件。我利用 是一款很薄而且小巧玲珑的手机，可是它的大部成果我都用不上。声音质量和靠得住性也很 不尽人意。公正地讲，此刻的用户界面比我说出那番言论时要好得多了。
