C++之父Bjarne Stroustrup：程序员在数学上付出的努力，永远也不会白费

Posted 2022-04-26 CSDN资讯

【CSDN 编者按】1979年诞生的C++已迈入“不惑之年”，如今却依旧在主流编程语言中占据重要一席。但今天，我们不再赘言C++的成功史，而将目光转向C++背后的英雄——C++之父Bjarne Stroustrup。在本篇文章中，让我们跟着软件开发商Evrone的采访，共享Bjarne Stroustrup四十余年程序人生中所蕴藏的大量经验财富。

作者 | Evrone，已获作者翻译授权      译者 | 弯月

出品 | 《新程序员》编辑部

作为最初只是出于改进C语言、增加部分基于面向对象编程功能的C++，它的成功令C++之父Bjarne Stroustrup自身都感到意外：“C++的成功令人惊讶。”

不过，也是因为C++一直广受开发者喜爱，Bjarne Stroustrup多年来始终坚持在开发一线——目前71岁的他仍在积极参与C++开发工作。经常有受益于C++的开发者说，C++改变了他们，但殊不知，C++改变的，还有Bjarne Stroustrup自己。

（图片来自 Bjarne Stroustrup 个人主页）

C++ 对 C++ 之父的影响

Evrone：您创建了一门高效且快速的编程语言，这无疑改变了我们的世界。请问对您个人而言，在创建这门语言的工作中是否也发生了变化？

Bjarne：我从未想过这个问题，不过我认为这个问题可以从两个角度进行回答：哪些方面长期保持不变，又有哪些方面发生了巨大变化。

从很久以前开始，我就对历史、哲学等许多领域都抱有广泛兴趣，多年来也一直保持不变，我认为这对C++的发展具有重要意义。因此，相较于深入研究学术，我更想要建立更多东西，这也给我对工程领域的看法带来了一定“偏见”。我看重性能、低成本和可靠性，再加上我很重视反馈、不断进步以及对现实世界问题的理解，最终造就了C++。

多年来，在我工作中持续稳步发展的一个方面就是教育。当我试图解释自己的想法时，我逐渐意识到：不能只是做出来，你必须教人们如何使用它。这也是C++一直存在的问题。通常，我的个人看法会被其他人的声音所淹没，这些人往往有着更简单的愿景并提出更大的主张。在20世纪80年代和90年代，我们经常会听到“我们没办法迅速培养教师”之类的抱怨，所以C++的教学常常采用一种在我看来很糟糕的方式，也难怪有些人会对C++抱有非常负面的看法。

如果我能早点知道自己一生中的大部分时间都在说写英语，那么我一定会在英语上更加努力。这些年来，我需要面对并解决许多问题，这些问题种类繁多且范围广泛，在这过程中我对它们也有了很多见解。许多困难的问题都与组织、管理和教育有关。与技术教育相比，广泛的阅读令我更加受益匪浅。我明白了良好的语言设计需要高度谦逊，因为我们不了解的东西太多：这个世界在不断变化，我们的问题在不断变化，而我们自身也在变化。

洞悉行业当前现象及趋势见解

Evrone：强大的C++元编程系统有时会被滥用，开发人员会想方设法将任务从运行时转移到编译时。在您看来，有没有什么可行的解决方法？

Bjarne：每一种新颖且强大的功能或技术都会被过度使用和错误使用，对此我想不到有什么好办法。不过这也会带来一定好处，因为过度使用会让我们认识到弱点，并设法解决。

举个例子，C++模板元编程非常有用，因此许多人愿意忽略它的不足及其负面消息去使用它。后来，我们从中总结了大量经验，利用编译时求值的函数（constexpr和consteval）和概念来弥补相关不足，大大简化了手动编写的大部分代码。

Evrone：业界流传着一个“笑话”，即任何架构问题都可以通过引入新的抽象层来解决，结果却导致抽象层太多。我们看到很多C++代码都有大量的抽象类，那么作为C++创始人，您认为如何才能让每个抽象类都发挥积极作用？

Bjarne：这就是David Wheeler的“计算第一定律”，他是我的论文导师，也是一个了不起的人，我从他身上学到了很多。

你说的这个“笑话”反映了现实，人们确实喜欢将真正的逻辑隐藏在多层接口之后，还会使用大量的间接方式，但这可能会导致代码量和运行时间增加一到两个数量级。因此，现代C++的大多数功能就是为了让人们编写的接口能被编译器优化成更简单的机器代码，尽量减少使用无谓的间接方式。

Evrone：随着DeepMind的AlphaCode神经网络的问世，越来越多媒体声称这种神经网络很快就会取代程序员。您认为这种说法有依据吗？

Bjarne：我不太确定。我也很怀疑人工智能是否真的能够取代我最关心的编程类程序员，但我认为可靠性和最佳性能不太容易被标准化和平均化。AI不是我的强项，但TensorFlow和类似的库都有C++的身影，这也就意味着——不论好坏，起码我已经尽了自己的一份力。

Evrone：在过去十年中，我们看到许多语法糖（对语言的编译结果和功能没有实际影响、却能更方便程序员使用该语言的语法）被添加到主流语言中。似乎通过“臃肿的语法”为开发人员提供更好的工具已成为一种趋势，您对此如何看待？

Bjarne：只要能减轻程序员的负担，即便是“臃肿的语法”也无伤大雅，我更愿称之为“让简单的任务变得更简单”。我认为，关键思想是让程序员能直接在代码中表达基本思想。例如，用C语言风格的循环来表达容器上的简单循环没有任何优点或好处，最好使用range-for或算法。在大多数情况下，这些方法都能直接表达意图，只有在特殊情况下才需要考虑复杂的循环变量，例如在访问容器的元素时，不是挨个访问，而是隔一个访问一个。想法越直接，编写、阅读和维护代码就越容易，并且通常优化也越简单。

因此，我不认为“应该只有一种表达方式”是一种理想的做法，这种思想会导致有些情况很难表达，而有些情况确实需要大费周折才能表达出来。此外，经过长年累月的优化，语言本身也会发生变化。从这些角度来看，编程语言与自然语言并没有什么不同。

开发人员该如何突破困境？
 

Evrone：如今人们普遍认为，使用现代框架比应用数学知识更重要，您能在这方面给程序员一些建议吗？

Bjarne：程序员在数学上付出的努力永远也不会白费。数学是训练我们大脑的最佳方法之一，尤其是与计算相结合时，我们很快就会意识到自己的错误；数学也教会了我们一丝不苟，不要轻信过于简单或错误的想法。

在很多领域中，数学知识都是必不可少的，例如科学计算、某些图形形式和许多金融软件。但对大多数人来说，数学的关键领域是概率和统计：你的代码速度够快吗？能扩展吗？某些事件的发生概率是多大？影响是什么？

当然，也有许多应用程序不需要数学，但在构建基础设施或大规模部署应用程序时，容量和能耗的成本不容忽视，此时数学知识的不足就可能会带来危害。

Evrone：有时作为开发人员，面对手头的编程任务，我们总是找不到合适的解决方案。您有没有遇到过类似情况，可否分享一些处理这类困境的建议？

Bjarne：当然遇到过。在面对新奇或重大难题时，每个人都需要付出巨大的努力，可能几小时、几天甚至更长时间，我们可能还会陷入困境，感到无助和沮丧。

这个时候，我们需要从逻辑层面来看问题。仔细想想你的目标是什么，或许是因为你努力的方向不正确，或许是因为你提出的要求不合理。也可以偶尔休息一下，想想别的事情，我一般会去跑步。放松下来以后，脑海中就会浮现一些有用的想法。

Evrone：业务环境时常要求我们在实现新功能时严格遵守最后期限。在您看来，开发人员要如何在代码质量和开发速度之间保持平衡？

Bjarne：这很大程度上依赖于管理结构和技术文化。我的个人意见（主要基于贝尔实验室的工作经历）是，如果你的组织内人才济济，就不必要求所有人都为下一个截止日期而努力。你需要一些关键人物为未来做策划、开展实验、构建下一个重要系统的第一个版本及后续版本。我认为，一个好的组织需要构建稳定的产品线，其中绝大部分都应在已部署并进入维护阶段的产品上进行革命性变更。不过显然，这种做法与常见的削减成本和发布颠覆性系统的思想背道而驰。

Evrone：许多人将您视为自己的导师，那么在您看来，一位优秀的导师应具备哪些品质？

Bjarne：愿意倾听并认真理解问题。在提供建议时要保持一定的谦虚，因为一般情况下，我们的理解都是不完整的。除此之外，优秀的导师必须给出具体建议，而不是一通模棱两可的废话。如果有人认真向你请教问题，你就应该给出严肃的答案助其进步。但老实说，提供建议也是一件很难的事。

不过教学相长，这也是我们进步的主要动力，一位优秀的导师会从学生身上学到很多东西。

预告C++的未来发展
 

Evrone：您能透漏一下在C++未来的版本中会出现哪些变化吗？

Bjarne：首先，社区必须适应C++20全新、强大并简化的特性，它在C++11的基础之上推出了很多提升。C++20有很多语言特性，还有标准库组件之类的，但在这里，我只介绍其中两个语言特性。

• 模块：我们可以认为，import Mod可以访问由module Mod导出（exported）的接口。这种方式更加整洁，与之相比，#include则会泄漏实现细节和宏。此外，模块的编译速度也得到了大幅提升。例如，简单编译一段import std代码的速度比#import<iostream>快十倍（注意：std包含所有标准库，而<iostream>不到其10%）。std模块目前仍处于试验阶段，但经投票已被纳入C++23。

• 概念：在C++20之前，所有模板都是不受约束的，也就是说，它们没有定义接口以供开发人员和工具查看模板的参数要求，但C++20中提出了“概念（Concepts）”弥补这一缺点。我们一直希望实现这种受约束的模板参数，只不过以前我不知道如何在不限制灵活性或增加运行时开销的情况下实现这个想法。现在我们可以检查模板的使用情况，在出错时得到改进后的错误消息，也可以重载函数模板，甚至提升某些方面的性能。

至于之后的版本，受疫情影响，很多功能的开发都被推迟了。我们希望能够在C++23中推出一些重要的功能，但很可惜，我最喜欢的一些功能未能如愿进入C++23。在这里，我只透露三点。

• 静态反射：我们需要一种机制来根据程序中的类型在编译时生成代码，这不仅可以为我们提供运行时反射的灵活性，而且无需时间或空间成本。例如，我们可以针对一组固定类型，很容易地生成优化过的JSON阅读器。在这方面，我们已经付出了巨大努力。

• 模式匹配：在许多函数式编程语言中，根据表达式与一组类型或备选值的匹配程度来选择操作，是表达备选操作最方便的方法之一。我们可以在C++中实现相同的功能，且在此过程中无需使用switch语句。我们有一个非常完整的设计和一个实验性的实现，所以我非常期待C++26。

• 并发模型：多年来，我们一直在研究一个通用的并发模型，可惜我们发现的总是明显不太适合的用例，因此我们不得不再三推迟。但我希望C++26能有所突破。

最后，有一点需要记住：单凭一个功能并不能让编程变得方便、安全且高效。我们需要在类型系统中创建大量特性，同时，我们又不能破坏现有的数十亿行C++代码，因为兼容性和稳定性是非常重要的特性。

原文地址：https://evrone.com/bjarne-stroustrup-interview

本文为 CSDN 翻译，转载请注明来源出处