1992年视角下的计算机编程困境：从编译器到方法论的范式转移

背景

这篇文章源自 Hacker News 社区，作者是 Mark Dominus（陶敏修），一位在 Perl 社区和编译器领域颇具影响力的资深开发者。文章最初发表于 2026 年 6 月 18 日，但内容回顾的是作者于 1992 年撰写的一篇旧文。

1992 年是软件工程发展史上的一个关键转折点。此时，个人计算机正在普及，C 语言及其编译器（如 GCC 的早期版本）已经相当成熟，而面向对象编程（OOP）的概念（如 C++ 和 Smalltalk）正在从学术走向工业界主流。然而，随着软件复杂度的指数级增长，开发者们开始意识到，仅仅依靠硬件算力的提升和编译器的优化，已经无法解决日益严重的“软件危机”。Mark Dominus 通过回顾 IBM 在 20 世纪 70 年代中期对 FORTRAN 编译器的迭代历史，敏锐地指出了当时编程领域的一个核心悖论：工具变得极其强大，但编程本身依然是一门“黑魔法”。

核心内容

文章以 IBM 在 20 世纪 70 年代中期对 FORTRAN 编译器的两次重大投入为引子，展开了一场关于编程本质的深刻反思。

1. IBM 的 FORTRAN 编译器迭代史

在 20 世纪 70 年代中期，IBM 内部的大部分编程工作依赖于 FORTRAN 语言。当时，IBM 拥有名为 FORTRAN G 的编译器，该编译器性能优异，能够将 FORTRAN 代码高效地转换为机器指令，且生成的代码执行效率很高。

尽管 FORTRAN G 已经足够好用，IBM 仍然决定投入巨资研发新一代编译器。这在当时被视为一个大胆甚至令人惊讶的决定，因为编译器本身是极其复杂的软件系统，编写难度极高。然而，IBM 依然投入了数百万美元和数百个“程序员年”（programmer-years，即人年的量化单位），最终推出了 FORTRAN H 编译器。FORTRAN H 不仅速度快、效率高，还具备许多优秀的新特性，成为了 IBM 长期使用的经典编译器。

2. 编译器技术的民主化

作者指出，从 1992 年的视角回看，编译器编写技术在过去十五年中取得了巨大进步。我们对编译器技术和如何编写编译器有了深刻的理解。如今，编译器已经不再难以编写，其难度降低到了什么程度呢？甚至大三的计算机科学本科生，都有能力在一个学期内写出一个及格的编译器。

3. 核心悖论：为什么没有“超级 FORTRAN I”？

基于上述背景，作者提出了一个尖锐的问题：既然我们在生产编译器方面的能力比十五年前提升了数千倍，甚至一名本科生就能在四个月内写出一个合格的编译器，那么为什么 IBM 没有投入同样的资源去开发一个比 FORTRAN H 好上数千倍的“超级 FORTRAN I”编译器呢？

4. 答案：瓶颈已转移

IBM 没有这样做的原因在于，编译器程序的质量不再是限制我们编写计算机程序能力的瓶颈因素。

程序员面临的主要问题，已经不再取决于编译器有多好，而是转向了**方法论（method）和语言（language）**层面的问题：

• 我们尚未真正掌握如何编程，以及如何管理我们的程序。
• 我们不清楚自己想要表达什么，也不知道该如何表达。
• 我们缺乏能够准确表达“我们希望计算机做什么”的优秀计算机语言。
• 我们缺乏正确的编程思维模式。

简而言之，IBM 不 bother（费心）去开发一个超级 FORTRAN 编译器，是因为无论它多么优秀，它本质上仍然是 FORTRAN。FORTRAN 作为一种语言范式，其局限性在于它无法解决更高层面的软件工程问题。

5. 结论：编程仍是“黑魔法”

作者总结道，计算机编程仍然是一门“黑魔法”（black art）。这门学科诞生不到五十年，没有人能称之为真正的大师。我们制造出了远超我们使用能力的工具。这暗示了当时的软件行业正处于一个尴尬的阶段：硬件和底层工具链已经足够强大，但上层的应用逻辑、架构设计和抽象能力却远远滞后。

关键要点

• 编译器技术的成熟与普及：相比 1970 年代，1990 年代的编译器技术门槛大幅降低，甚至成为本科教学的一部分，这意味着编译器不再是稀缺资源或技术壁垒。
• 边际效应递减：在编译器优化上投入巨额资源（如 IBM 开发 FORTRAN H）带来的收益，在 1992 年看来已不足以抵消其成本，因为编译器性能的提升不再是软件质量的主要制约因素。
• 瓶颈转移至抽象层：编程的核心痛点从“如何高效地将代码转换为机器码”转移到了“如何正确地抽象问题、设计语言和管理复杂性”。
• 方法论的缺失：当时的软件工程缺乏成熟的方法论和表达工具，导致程序员无法有效地将意图转化为代码。
• 编程的本质困境：尽管工具日益强大，但编程本身仍未摆脱“黑魔法”的属性，缺乏系统性的科学基础，更多依赖个人经验和直觉。

意义与影响

Mark Dominus 在 1992 年的这篇短文，精准地预言了随后三十年软件行业的发展轨迹，其洞察力在今天看来依然振聋发聩。

1. 对现代编程语言发展的解释 这篇文章解释了为什么过去三十年间，我们看到了 Python、Ruby、JavaScript、Go、Rust 等大量新编程语言的涌现。开发者们不再满足于优化 C 或 FORTRAN 的编译器，而是试图通过新的语法、类型系统和抽象机制来解决“如何更好地表达意图”的问题。例如，Rust 试图解决内存安全与抽象表达的矛盾，Go 试图简化并发编程的表达。

2. 对软件工程方法论的启示 文章指出的“方法论和语言”问题，直接推动了敏捷开发、DevOps、领域驱动设计（DDD）等现代软件工程实践的兴起。这些实践本质上都是在尝试解决“如何管理程序”和“如何思考编程”的问题，而不仅仅是关注代码的执行效率。

3. 对 AI 编程时代的映射 在今天的 AI 编程时代（如 GitHub Copilot、Llama 等模型的应用），这一观点具有新的意义。AI 极大地降低了编写编译器底层逻辑或生成样板代码的门槛，这类似于当年编译器变得“容易编写”的阶段。然而，正如 Dominus 所言，如果缺乏正确的问题定义和方法论，AI 生成的代码依然可能无法解决复杂的业务逻辑和管理问题。AI 并没有自动解决“我们不知道自己想说什么”或“不知道如何表达”的根本困境，它只是将“黑魔法”的一部分自动化了，但核心的架构设计和意图表达依然高度依赖人类程序员的智慧。

4. 对技术投资的警示 对于企业和开发者而言，这篇文章提醒我们：在工具链上过度优化（如追求极致的编译器优化）可能存在边际效益递减的风险。相比之下，投资于提升代码的可读性、可维护性、抽象能力以及团队的方法论建设，往往能带来更大的长期回报。

总之，Mark Dominus 在 1992 年的反思，不仅是对过去三十年软件工程的总结，更是对未来技术演进方向的深刻洞察。它提醒我们，无论工具多么先进，编程的核心始终是关于思维、表达和抽象的艺术，而非仅仅是关于机器指令的效率。