约翰·巴克斯与 FORTRAN：使软件能够扩展的语言

为什么 FORTRAN 影响深远

在1950年代早期，计算机稀少且昂贵，通常由政府、大学和大型企业使用。尽管性能在当时很强，但编程过程却极其低效。许多程序直接用机器码或汇编语言编写，每条指令都要与硬件的微小操作集一一对应。公式的一点改动可能意味着要重写大量代码，而一个小错误就可能在等待数小时后导致整个运行崩溃。

约翰·巴克斯与 IBM 的激进设想

约翰·巴克斯（John Backus）是 IBM 的一名工程师，他早已目睹低级编码在时间上的巨大浪费。他带领一支小团队做出一个激进的尝试：让程序员以更接近问题本身的方式编写数学密集型指令，然后让编译器把这些高层表达翻译成高效的机器码。

该项目成为 FORTRAN（“Formula Translation”的缩写），目标用户是 IBM 的科学客户——那些做数值工作的群体，而非日常文档处理人员。承诺很直接：写更少代码、出错更少，并且仍能在像 IBM 704 这样的机器上高效运行。

最大的问题：会足够快吗？

当时许多程序员认为高级语言只是奢侈品。他们认为任何“接近英语”的表达都会比精心调优的汇编慢得多——慢到无法用便利性来补偿。计算机价格昂贵、算力被严格配给时，性能不是“锦上添花”，而是全部理由。

所以 FORTRAN 不只是新的语法，而是一场赌注：自动化能否匹配专家的手艺——编译器能否产出足够好的代码，从而赢得科学家和工程师对每个周期的重视。

本文将覆盖的内容

FORTRAN 的故事既是技术突破，也是文化转变。接下来我们会回顾高层语言出现前的编程状态、巴克斯团队如何构建能与手写代码竞争的编译器，以及这一成功为何改变了软件的经济学——并奠定了现代团队至今仍在沿用的模式。

高级语言出现前：仅有汇编的现实

在 FORTRAN 出现之前，“编程”通常意味着用计算机自身的词汇写指令，或仅稍作美化的形式。

机器码与汇编是常态

早期计算机执行机器码：数值操作码与内存地址。由于这几乎无法管理到大规模，程序员使用汇编语言，用简短的助记符代替许多数值。但汇编仍然是对硬件的薄包装。你描述的不是用数学术语表达想要的东西，而是逐步、寄存器级地拼凑出如何做。

对科学计算而言，这意味着手动管理循环、内存布局与中间值。即便公式有小改动，也可能需要重写程序的多个部分，因为一切都通过地址和跳转互相连结。

痛点：耗时、错误与绑定

汇编编程既慢又脆弱。常见问题包括：

• 耗时： 编写和调试所耗时间远超过实际数学计算本身。
• 易错的细节： 一个错误地址、错过进位或一个越界跳转都可能让结果失效。
• 与硬件强绑定： 程序与机器模型（如 IBM 704）紧密耦合，迁移到另一台系统可能意味着从头开始。

更快迭代为何重要

科学家和工程师并不只是做一次计算——他们不断改进模型、重跑仿真、探索“如果……会怎样”的场景。当每次更新都意味着数日或数周的重写与测试，实验步伐会骤然放缓。

这就显现出一种新的成本：程序员的时间。硬件昂贵，但熟练人力也同样昂贵。到1950年代中期，瓶颈往往不是机器速度，而是人让机器可靠地完成有用工作的时间。

约翰·巴克斯与 IBM 对新编程方式的押注

巴克斯并非一开始就注定为“计算机先驱”。经历辗转的早年职业与在美军的服役后，他在1950年代初进入 IBM，当时计算机仍然稀少，主要靠手工编程。巴克斯以两点迅速脱颖而出：对枯燥工作的实际不耐与组织雄心工程团队的能力。

IBM 的目标：让 704 发挥价值

IBM 面临一个问题与机遇并存的机器：IBM 704。它在当时很强大，配备了浮点运算等对数学任务重要的特性。但技术与科学客户（工程师、研究人员、政府实验室）在写和调试汇编语言上花费巨大时间。如果编程保持这种低效，再好的机器也会闲置。

IBM 的赌注简单却冒险：让 704 更容易编程，同时不放弃速度。

围绕编译器组建的团队，而非口号

巴克斯带领的团队把 FORTRAN 当作两件不可分割的工程：语言（人能写）的设计，与能把语言翻译成高速机器码的编译器。真正的赌注在于后者。许多专家认为“自动编程”永远无法替代手工调优的汇编。

当时“高级”意味着什么

高级语言并不只是“漂亮的语法”。它意味着可以以更贴近问题的数学与逻辑写出公式、循环和结构化指令——然后信任编译器生成能与熟练程序员手工优化相媲美的代码。正是这种信任，IBM 与巴克斯试图赢得。

FORTRAN 的承诺（以及人们的怀疑）

FORTRAN 的核心承诺看似简单却很激进：与你告诉机器“如何”做每一步不同，你可以写出更接近数学的语句。

工程师可以写“对许多值计算这个公式”而不是手动列出加载、加法、存储和跳转的序列。希望是：编程更像是表达想法，而不是用文字布线控制面板。

“编译”的通俗解释

FORTRAN 并不直接在计算机上运行。一个独立程序——编译器——把 FORTRAN 源代码翻成机器的低级指令。

可以把它想成一位技术会议的熟练译员：你用人能看懂的语言表达，译员把它改写成听众能立刻执行的低级语言。

设计目标：可读、快速、实用

巴克斯团队追求一种罕见的组合：

• 可读性： 代码贴近代数与常见的科学记法。
• 速度： 生成的程序要能接近手写汇编的运行速度。
• 实用性： 提供数值工作真正需要的特性，而非学术上的花哨。

最后一点很重要。FORTRAN 并不想面面俱到——它的目标是用更少的错误完成真实计算。

人们为何怀疑

怀疑声非常强烈。许多程序员认为性能需要完全控制，“自动”翻译注定低效。另一些人担心调试：如果编译器生成最终指令，如何知道机器到底在做什么？

明确的目标用户

FORTRAN 的首批用户是工程师和科学家——他们有方程要运行、模型要测试、结果要产出。对他们来说，承诺不是新奇，而是省时、减少抄写错误，并能让程序被更多人阅读与维护，而不仅仅是一小撮汇编专家的“祭司”技能。

编译器挑战：把类英语代码变成高效代码

FORTRAN 不只是新的写法——它要求一种新的翻译方式。这个翻译任务落到编译器身上，其成败将决定 FORTRAN 是革命还是过眼云烟。

什么是编译器（通俗比喻）

把编译器想成一位技术会议上的高水平口译：你说“计算这个方程，对每个值重复”，但听众只懂严格的低级词汇。一个平庸的译员可能能把意思传达清楚，但译文笨拙冗余、绕来绕去。一个优秀的译员既保留含义又保留效率，产出听众能马上执行的内容。

FORTRAN 需要这样的优秀译员。

为什么编译器质量比语言优雅更重要

早期程序员选用 FORTRAN 不是看语法美不美，而是看它能否“值回票价”：用更少的编码时间而不支付运行时代价。在像 IBM 704 这样的昂贵机器上，浪费 CPU 时间就是浪费金钱——在科学工作中，慢代码可能意味着结果来晚了就毫无意义。

所以真正的产品不是语言规范本身，而是编译器生成的结果。如果编译后程序运行接近手写汇编，团队就能合理地转用；如果不能，无论语言看起来多么“好看”，都会被放弃。

关键技术难点：把公式编成高效机器码

FORTRAN 的卖点（以数学写数学）也让编译变得困难。编译器必须：

• 正确解析代数表达式（包括运算优先级）；
• 决定何时把值保留在寄存器而非内存；
• 在安全前提下重新排序计算以减少指令；
• 生成紧凑的循环，避免浪费周期。

可能扼杀采纳的怀疑

许多工程师觉得高级代码本质上会更慢。巴克斯团队必须用证据打消这种怀疑：编译后的程序要有竞争力、可预测且值得信赖。没有性能信誉，FORTRAN 只会被看作学术上的方便，而非完成真实工作的工具。

优化：赢得用户的秘密武器

FORTRAN 的重磅承诺不仅是让你更快写代码，而是编译后的程序仍能高效运行。这点重要，因为早期采用者不是业余爱好者，而是以机器小时和交付结果计量价值的工程师与科学家。

什么是“优化”（通俗说法）

优化是编译器替你做额外工作。你用清晰、贴近数学的语句编写代码，编译器悄悄把它改写成使用更少指令、更少内存访问、在 IBM 704 上更省时间的版本。

重要的是目标不是“聪明秀技”，而是可预测的高效——让人们相信用 FORTRAN 编写不会因为慢而受到惩罚。

用户能实际感受到的优化

FORTRAN 编译器应用了与直觉一致的改进：

• 避免重复工作： 如果循环内某值不变，就只计算一次。
• 更聪明地使用寄存器： 把常用值放在离 CPU 更近的地方，而不是频繁从内存取出。
• 清理代数步骤： 简化表达式以减少机器执行的操作数。
• 更好的循环处理： 减少不必要的跳转和管理，使紧密循环更快。

这些并不要求程序员关心指令时间或内存地址——但恰恰是汇编程序员关心的细节。

为什么这打动了汇编程序员

汇编有个有力论点：“我手工能把它做得更快。”怀疑者认为高级语言会产生臃肿、浪费的机器码。

巴克斯团队把怀疑当作产品需求：优化不是可选项，而是证明抽象不等于放弃性能的证据。

声誉效应

一旦大家知道 FORTRAN 程序在许多真实负载上能与手写汇编竞争，采用速度就加快了。编译器成为一种值得信赖的队友：清晰地表达意图，让编译器去处理细节，同时仍尊重硬件性能。

FORTRAN 让哪些事情更容易：循环、子程序与数组

FORTRAN 不只是“看起来更好”。它把几项实用思想打包好，这些恰好契合科学家和工程师的日常工作：重复计算、复用方法、以及以可预测方式存放大量数字。

更贴近数学的循环

科学程序充满“做 N 次”的任务：求和、时间步进、迭代求解或对许多数据点应用同一公式。在汇编中，重复常常意味着手写跳转逻辑——容易出错且难以阅读。

FORTRAN 的 DO 循环让意图一目了然：

      SUM = 0.0
      DO 10 I = 1, 100
         SUM = SUM + X(I)
 10   CONTINUE

程序员不必手动管理多个跳转和计数器，可以声明范围并专注于公式本身。

子程序用于复用（和团队协作）

工程工作具有重复性：矩阵乘、单位换算、多项式评估、读取标准数据格式。子程序让团队编写一次可信的例程并在多处调用，减少复制粘贴——这是传播错误的快速方式。

更重要的是，子程序鼓励把大程序拆成更小的部分，便于别人审阅、测试和改进。

数组：科学数据的自然形态

测量、向量、表格、网格与矩阵是科学计算的核心。数组给程序员提供直接表示这些结构的方式，而不用到处操作独立变量或手动做地址算术。

更少的“神秘跳转”，更少的错误

以汇编为主的控制流依赖大量有条件与无条件跳转。一个错误的标签目标可能悄然破坏结果。通过提供结构化的构造（如循环和命名子程序），FORTRAN 减少了纠结的跳转逻辑，使程序更易验证并在变更时更不脆弱。

从研究到实际应用：FORTRAN 的落地场景

FORTRAN 之所以能广泛成功，是因为它被那些解决昂贵且时间敏感问题的人反复使用。一个语言可以被推崇（甚至影响深远）而不改变日常工作；FORTRAN 改变了日常工作，因为团队信任它到愿意把真实的期限和预算押在它上面。

最先的大用户：科学与工程

早期采用者是那些以计算为生死线的群体：航空航天项目、物理实验室、气象与气候研究，以及做结构与电气计算的工程部门。这些不是玩具例子，而是小幅提高生产力就意味着能做更多实验、更多设计迭代，并减少隐藏在手工汇编中的错误。

FORTRAN 非常契合这些问题的形态：数组表示矩阵与网格，循环处理重复数值步骤，子程序帮助把数学密集的代码组织成可管理的模块。

程序共享变得现实

汇编程序与特定机器高度耦合，且写法难以为外人阅读或修改。FORTRAN 并不能魔法般地让程序跨所有机器可移植，但它确实让程序更可理解。这使得在组织内部甚至组织间流通代码变得可行，而不再需要原作者逐条“翻译”。

复用不再只是口号

当程序员可以在更高层次表达计算时，维护一套可信赖例程库变得有意义。团队可以复用数值方法、输入/输出模式和领域特定计算，而不必担心改一行就把一切打碎。这种转变——把代码视为值得维护与复用的资产——推动编程从一次性手艺走向可重复的工作模式。

FORTRAN 的长远影响：塑造后续语言的理念

FORTRAN 不仅让一台机器更易编程，它确立了一套关于语言应当做什么与编译器能做什么的期望，在两者仍具争议的时期具有里程碑意义。

把编译器技术视为特性，而非事后考虑

FORTRAN 成功的关键教训之一是：语言设计与编译器设计密不可分。早期批评者不仅怀疑“类英语”代码，也怀疑编译器能否把它翻译成高效的机器指令。FORTRAN 团队的答案是大量投资于编译与优化；这种思路在后来的语言项目中不断回响。

许多后续系统——从科学语言到主流语言——都承袭了这样一种心态：更好的编译技术能释放更好的语言，让程序员用更安全的抽象、更清晰的语法和更高的生产力，而不牺牲性能。

将优化视为一种期待

FORTRAN 使得“编译器应该生成具有竞争力的代码”成为常识，尤其在数值工作负载上虽不见得所有后续语言都追求相同的性能目标，但基线期待改变了：高级不等于慢。

这推动了编译器研究与实践向诸如循环分析、计算重组与寄存器管理等优化技术发展，这些也成为后续几十年编译器构造课程与实践的标准话题。

可移植性与标准化：先慢后必然

早期 FORTRAN 与 IBM 硬件紧密相关，可移植性并非一开始的主要卖点。但随着 FORTRAN 在机构与机器间传播，重写科学代码的成本变得明显。长期来看，历史共识认为 FORTRAN 是推动行业走向语言标准化的一股重要力量。

结果不是瞬间达成的，也并不完美——但它奠定了一个先例：能跨越单一厂商或机器代的语言需要稳定的定义，而不仅仅是良好的实现。

局限与批评：FORTRAN 未能解决的一切

FORTRAN 解决了一个痛点——在不被汇编淹没的情况下编写复杂计算——但它并没有把编程变得“简单”。早期用户发现高级语言能去除一类麻烦，同时暴露出新的问题。

可读性与性能的权衡并非白送的午餐

FORTRAN 性能的声誉伴随着代码形态上的折衷。程序常常需要围绕编译器能优化的模式来书写，而不是最易理解的方式。

举例来说：科学家可能要把一个清晰的计算拆成若干步骤或重排语句，仅仅因为这样跑得更快。结果是性能不错，但新同事可能难以理解代码。

在硬件多样的世界里，便携性有限

FORTRAN 常被赞为帮助程序在不同机器间迁移，但一开始“可移植”带有附注。计算机在字长、I/O 设备，甚至基本数值行为上有差异。团队有时为不同系统保留程序的不同版本，或在需要特殊功能时插入机器相关代码。

举个简单例子：从穿孔卡、磁带或类似打印机的设备读取数据，可能需要不同的处理方式，即便数学计算完全相同。

语言并未消除复杂性

FORTRAN 为科学计算而生，并非为一切用途。它没有提供后来语言那样组织大型代码库的强工具。调试仍可能缓慢且令人沮丧，早期编译器有时给出的错误信息会令人回到“汇编世界”，只是换了种措辞。

一个至今仍熟悉的争论

FORTRAN 引发的讨论至今仍在：应该优先追求极致速度，还是更清晰的代码与更高层次的抽象？最佳答案取决于场景，过去是如此，现在亦然。FORTRAN 证明了抽象能带来收益，但也教会我们一个持久的道理：每层便利都有边界，团队必须权衡可接受的取舍。

给现代软件团队的启示

FORTRAN 的成功在于把开发者时间视为稀缺资源。巴克斯与 IBM 不仅发明了更友好的语法，他们证明了对工具的投入可以开启全新的软件类别。

生产力胜过“耍聪明”

FORTRAN 的主张很简单：写更少的行数，交付更正确的程序。现代团队经常需要重述这一点。一周的时间用于建立更安全的 API、更清晰的模块界限或自动化痛苦流程，往往比为一个可能无关紧要的热循环榨出 3% 性能更有价值。

赢得对抽象的信任

人们怀疑 FORTRAN 是因为抽象看起来像放弃控制。编译器通过交付接近手工汇编的性能改变了这种看法。

现代对应物是对框架、托管运行时和云服务的信任——但这种信任需要被赢得，而不是被默认假定。当抽象失效时，团队会退回到“手动模式”。应对之道与1957年相同：可测量的性能、透明的行为和可预测的故障模式。

工具能改变可能性

FORTRAN 不只是语言，它是使高级编程在规模上可行的编译器工程。今天的对应物包括：

• 能优化并发出警告的编译器与解释器；
• 提高代码审查效率的静态分析器和格式化工具；
• 把变更变成常规而非危机的测试与持续集成。

还有一类新的工具，延续了最初 FORTRAN 的押注：把工作从人手中移到“类似编译器”的系统中。比如类“Vibe-coding”平台（如 Koder.ai）通过聊天式描述让代理生成并迭代真实应用（例如 Web 上的 React、后端的 Go + PostgreSQL、移动端的 Flutter）。在实践中，规划模式、快照与回滚等特性试图提供与 FORTRAN 当年要证明的相同价值：更高层次的意图而不丢失可操作控制。

好的工具不仅防止错误，还能扩展雄心，让更小的团队构建更大的系统。

总结

巴克斯的持久影响在于：当围绕代码的系统——语言、编译器与实践——能帮助人们更快、更有信心地工作时，软件就能实现规模化。这仍然是现代工程团队的基本策略。