HOPL 是 History of Programming Languages（编程语言历史）的缩写，是 ACM 旗下的一个会议，约每十五年举办一次。
这是我父的第三篇 HOPL 论文，发表于 2021 年。中文译本 出自 Boolan 之手，不胜感激。
使用包含 (值,错误码) 对的类会带来巨大的成本。除了检测错误码的成本外，许多 ABI（应用程序二进制接口）甚至不使用寄存器来传递小的结构体，所以 (值,错误码) 对不仅传递了更多的信息（是通常数量的两倍），而且也使传递的性能有数量级的降低。可悲的是，在许多 ABI 中，尤其那些针对嵌入式系统的 ABI（专为 C 代码设计），这个问题直到今天（2020 年）依然存在。
这些年来，异常处理的性能相对较慢，是因为我们在优化非异常方面花费了大量精力。
具有讽刺意味的是，那些坚定支持异常规约的人转而去帮助设计 Java 了。
HOPL 是 History of Programming Languages（编程语言历史）的缩写，是 ACM 旗下的一个会议，约每十五年举办一次。
这是我父的第三篇 HOPL 论文，发表于 2021 年。中文译本 出自 Boolan 之手，不胜感激。
Concepts—我父最大的执念，也算是我父的滑铁卢了吧……大约是十年前吧，就看过我父亲自上阵“路演” Concepts 主题的 PPT。念念不忘，必有回响。终于还是标准化了。
这是一篇夹在 C++14 和 C++17 时间线中间的大幅文章，远不到 C++20 内容出场的时候，可见我父的急不可耐……我的看法？我是一个反模版者（注意不是反泛化），语法笨重，强制的实现可见，乱七八糟的错误信息。一群四六不懂的 TMP 至高无上鼓吹者直接让我把这种理性的反对变成了冲动的反感。所以这么些年我都没怎么系统地学习过模版。
Concepts 当然是出于善意，能解决“乱七八糟的错误信息”问题，在正向使用模版的时候也能对编译器做出正确的指示。但是！不管是优柔寡断或是市场的原因，引入新特性的同时依然保留了旧的、坏的实现路径，恰恰是我父前文提到的 N+1 问题：为了解决前边 N 种方案存在的问题引入了第 N+1 种方案。隔代的 C++ 程序员们该怎么沟通、共事？（此刻，我突然理解了那些依然坚持使用 C++98 的程序员们。）而且 Concepts 引入的长长的前缀语法抵消了 auto 所做的简化努力，语法笨重的问题反弹了。
为时晚矣……模版依然是特定人群（专家？）、特定领域（开源？）的小众选择。
HOPL 是 History of Programming Languages（编程语言历史）的缩写，是 ACM 旗下的一个会议，约每十五年举办一次。
这是我父的第三篇 HOPL 论文，发表于 2021 年。中文译本 出自 Boolan 之手，不胜感激。
有一种流传广泛的谬见，就是程序员希望他们的语言是简单的。 当你不得不学习一门新的语言、不得不设计一门编程课程、或是在学术论文中描述一门语言时，追求简单显然是实情。 对于这样的用途，让语言干净地体现一些明确的原则是一个明显的优势，也是理想情况。 当开发人员的焦点从学习转移到交付和维护重要的应用程序时，他们的需求从简单转移到全面的支持、稳定性（兼容性）和熟悉度。人们总是混淆熟悉度和简单，如果可以选择的话，他们更倾向于熟悉度而不是简单。
这也是我在前有 C 后有 Rust 的情况下继续跟踪并学习 C++ 新标准的原因：已经上了贼船了，没办法。