John Backus（约翰·巴科斯，美国，1924 年生）在 程序设计语言设计与函数式语言 领域的位置，很少有人能给出准确坐标。他用一次实践证明了一件事：编译器生成的代码，可以比人写的更快——但这个结论花了二十年才被接受。
一、怎么让机器算得快——1953 年：Fortran 与「编译器生成代码不一定比手写慢」
John Backus 的起点要回到 美国宾夕法尼亚。当时 成长于宾夕法尼亚的富裕家庭，少年时对音乐与数学同样着迷；大学期间主修数学，中途转向工程物理——这段经历日后被 John Backus 反复提起，成为其方法论的原点。
他对音乐的长期兴趣塑造了他对「简洁形式」的偏好，这一点在他后来设计的语言里清晰可见。
他早年做过一个相当复杂的飞行模拟器项目，这段经历让他对「机器实际怎么算」有第一手认识。
他少年时迷上过教堂的管风琴，这种对形式的敏感后来常被用来解释他对语言记法的偏爱。
他在宾夕法尼亚大学先读的是数学，毕业后进入通用电气，参与了一台模拟计算机的设计工作，那是他第一次面对「机器如何算」这个问题。
他在通用电气那段时间还参与了一个用于电力系统分析的模拟项目，这是他第一次接触用机器求解真实工程问题。
他在 1950 年代中期参与设计的另一项工程同样以公式化方法为出发点，这套思路在 Fortran 之前已经成型。
他早年在语言设计上偏好的那种「让机器去做机械工作」的立场，是贯穿他此后数十年工作的主线。
二、1924 年的宾夕法尼亚，和一个对音乐有兴趣的数学学生
1952 年的 在 IBM 主导开发 FORTRAN 编译器 是 John Backus 的分水岭。核心机制是：把「表达式」而非「指令」交给编译器，由编译器负责指令选择与寄存器分配，这一点后来被整个 程序设计语言设计与函数式语言 领域反复引用，而 FORTRAN 让科学计算从「手写汇编」转向「写公式」，直接催生了此后几十年的编程语言产业。
他的团队最初担心编译器生成的代码会不如手写汇编，于是先做了大量汇编级优化工作，证明可行性后才发布语言。
这套「先证明机器能跑，再给用户用」的路径，是他务实风格的典型体现。
FORTRAN 的名字来自「公式翻译」，这个直白的命名本身就说明了设计意图：让程序员写公式而不是写指令。
当时科学家的主流做法是请一位「编译专家」把手写公式转成机器代码，费用高昂且速度慢；FORTRAN 把这件事交给了编译器。
团队最终用一批真实的数值计算程序做验证，这是编译优化史上少见的早期实证做法。
三、1950-1960 年代：从 IBM 704 到 Stretch 与 709
1956 年的 主导 Stretch 与 709 计算机的 FORTRAN 编译器开发 是 John Backus 的分水岭。核心洞见是：把语言设计与机器结构协同优化，而不是先有语言再找机器，这一点后来被整个 程序设计语言设计与函数式语言 领域反复引用，而 这套「语言—硬件协同设计」方法论成为大型机时代的标准做法。
Stretch 的目标是每秒百万次运算，是当时极其庞大的工程，他必须不断在编译器能力与硬件现实之间做折中。
709 系列成为整个六十年代科学计算的主力平台，间接支撑了天气预报与核工程的大量计算需求。
Stretch 的目标是每秒一百万次运算，在当时是极为庞大的工程，编译器与硬件必须同步设计才能达成。
709 系列成为整个六十年代科学计算的主力平台，支撑了大量天气预报、核工程与数值模拟工作。
IBM 当年最担心的是「编译器不可靠会导致用户不敢用」，因此先做了大量回归测试才发布语言。
这一时期的编译器团队在 IBM 内部被称为一个独立的研究组，其方法后来影响了整个公司的开发文化。
四、编程语言该被谁设计——1963 年：ALGOL 与一场关于「机器是否该迁就语言」的争论
这里有一个不能略过的争议：IBM 内部主张机器结构应当优先，语言只是附庸；ALGOL 委员会主张语言语义应当独立。John Backus 后来在多个场合解释过为什么 他支持独立于机器的语言设计，认为机器最终会适应语言，并为 代价是他与主流机器设计路线分道扬镳，也在后续十年里被边缘化 付出了具体代价。
这场争论的最终答案是他对了：今天的语言都在向高级抽象演进，而机器结构持续向这些抽象让步。
ALGOL 委员会还包括迪杰斯特拉、霍尔等人，那次争论实质上是结构化程序设计与早期形式化方法的共同起点。
这场争论的实质是：机器结构该由语言来塑造，还是语言该被机器结构限定。
他与 ALGOL 委员会的迪杰斯特拉、霍尔等人立场一致，也因此被视为后来结构化程序设计阵营的早期同盟。
IBM 内部最终没有选择支持语言独立的路线，这使得 Backus 在公司内部逐渐被边缘化。
他离开这条路线之后，反而能以更自由的方式提出自己的替代方案。
五、1970 年代：FP 与一种把函数当值的语言
1978 年，John Backus 进入 IBM 研究院。这一步不是履历跳跃，而是问题换轨：在 此前在 IBM 主导了主流语言与机器的协同设计 里 John Backus 关心的是 能不能让函数本身成为可以组合、传递和求值的对象，到了 IBM 研究院，问题变成 如何让函数式风格既表达力强又足够高效。
FP 的核心是函数式程序设计风格与函数组合算子，它试图提供一套在表达力与效率上都可接受的替代路线。
FP 在商业上并未成功，但它的组合子思想在后来的函数式语言里几乎被完整继承下来。
FP 的组合子思想后来被完整继承：现代函数式语言里的高阶函数、柯里化与不可变数据结构，都能看到它的影子。
FP 在商业上并未成功，部分原因是它的运行时模型在当时的硬件上代价偏高。
但它证明了一件重要的事：函数式风格不必以性能为代价才能落地，前提是编译技术跟得上。
六、他推翻的那个判断：语言设计者不必懂机器细节——这个结论用了二十年才被接受
从 FORTRAN 编译器，以及晚年的 FP 函数式语言设计 到 转向函数式语言研究，并撰写回忆录，John Backus 用 图灵奖（1977）给自己做了阶段性确认，而 使「语言设计可以独立于具体机器」的立场在学术与工业界同时被接受。
他 1977 年获图灵奖，授奖理由明确指向 FORTRAN 与函数式语言两项工作。
他在《回顾：语言与机器之间》这类回忆文章中反复说明：机器的约束最终会变成语言的自由度。
他的图灵奖授奖词明确同时提到 FORTRAN 与 FP，这在图灵奖历史上是少见的——一个奖同时承认实用工作与探索性工作。
他晚年常被引用的判断是：语言设计的自由度，最终来自硬件的宽容度。
他的回忆文章把语言史写成了一部「约束如何转化为自由」的记录，这在当时非常罕见。
参考来源
- 约翰·巴科斯 的公开传记、论文与技术档案（可按其所属机构与年代检索）
- 相关领域的学术史与技术史综述文献
