巴别塔的诅咒：PL/I如何用一台计算机统一代码世界的野心与悲歌

# 巴别塔的诅咒：PL/I如何用一台计算机统一代码世界的野心与悲歌 1964年深秋，IBM纽约实验室的灯光彻夜不熄。首席架构师乔治·雷德蒙德（George Radin）将一份蓝图画在桌上——要创造一种语言，既能替物理学家计算导弹弹道，又能为银行家处理流水账单，甚至能同时运行在性能相差万倍的System/360各型号上。这个被命名为“PL/I”的计划，承载着IBM在1965年用软件统一整个计算世界的野心。然而，当这个“全能巨人”走向市场时，它既带来了前所未有的技术突破，也埋下了软件史上最昂贵的“过度设计”教训。 ## 大一统的迷思：当科学计算与商业处理被迫联姻 20世纪60年代初，计算机世界正陷入一场“语言内战”。FORTRAN统治着实验室和国防系统，工程师们用它的浮点运算求解微分方程；COBOL则牢牢把持着银行与保险公司的账房，会计们用它的数据记录处理百万级交易。IBM的System/360系列计算机，作为历史上第一个兼容不同性能等级的大型机家族，需要一种“通用语言”来降低软件开发成本。IBM高级副总裁鲍勃·埃文斯（Bob O. Evans）在1963年的内部备忘录中写道：“我们的客户正在为三种语言、三种编译器、三种培训体系支付双倍费用。必须结束这种混乱。” 但技术团队内部爆发了激烈争论。FORTRAN之父约翰·巴克斯（John Backus）警告：“把科学计算的指针和商业处理的字符串放在同一门语言里，就像让爱因斯坦和会计共享同一个大脑。”而负责商业系统的C. A. R. 霍尔（C. A. R. Hoare）则坚持：“银行系统需要精确到分币的十进制运算，FORTRAN的浮点误差会引发财务灾难。”最终，IBM总裁小托马斯·沃森（Thomas J. Watson Jr.）拍板：创造一门“绝对通用”的语言，它必须同时支持浮点数与十进制数、静态数组与动态字符串、同步与异步任务、甚至异常处理与存储管理。 这个决策注定了PL/I的基因里就带有“大爆炸”的印记。1964年春天，设计团队在纽约波基普西的实验室闭关六个月，雷德蒙德每天收到来自全球IBM用户组的200多封需求信。一位来自美国银行的程序员写道：“请让语言能直接操作磁带文件。”而洛斯阿拉莫斯国家实验室的物理学家则要求：“必须能在运行时改变数组维度。”这些相互矛盾的需求被全部塞进语言规范，导致PL/I的官方手册在1965年发布时厚达400页，包含超过60个关键字——是FORTRAN的3倍，COBOL的2倍。 ## 技术狂想曲：语言特性超前时代二十年 1965年4月，IBM在纽约希尔顿酒店正式发布PL/I。演示现场，一位工程师用一段代码同时完成了矩阵乘法、字符串拼接、并发任务调度和文件I/O操作。台下爆发的掌声中，没有人意识到，这段代码需要System/360的最高端型号（内存256KB）才能流畅运行，而当时绝大多数客户的机器只有32KB内存。 PL/I的技术突破堪称“未来主义”：它引入了**静态存储与动态存储混合管理**，程序员能用`ALLOCATE`语句在运行时创建数据结构，这比C语言的`malloc`早了整整7年；它首创了**结构化异常处理**，用`ON CONDITION`语句捕获运行时错误，比Java的`try-catch`早30年；它还支持**任务并行**，用`CALL`语句启动异步子程序，这在单核处理器时代显得荒诞而超前。更令人惊叹的是，PL/I的编译器由IBM的“编译技术之父”弗兰·艾伦（Fran Allen）团队设计，首次实现了“全局优化”——编译器能自动将循环展开、寄存器分配、甚至将科学计算的浮点运算转换为商业系统的十进制运算。 但技术的辉煌掩盖不了现实的残酷。1966年，美国最大的保险公司大都会人寿（MetLife）率先部署PL/I系统。他们的首席技术官在三个月后愤怒地致信IBM：“我们的COBOL程序编译只需5分钟，而PL/I版本用了47分钟。更可怕的是，运行时内存占用是原来的4倍。”这并非孤例。为了兼容System/360从最低端（每秒处理3万条指令）到最高端（每秒处理330万条指令）的机器，PL/I编译器必须生成极其复杂的适配代码。IBM的测试报告显示，同一段PL/I代码在低端机器上运行效率仅为汇编语言的15%，而在高端机器上也只能达到40%。 1968年，IBM内部爆发了著名的“PL/I危机”。在System/360操作系统OS/360的开发中，项目经理弗雷德里克·布鲁克斯（Frederick Brooks）发现，团队用PL/I编写的代码占据了70%的调试时间，而仅贡献了20%的代码量。布鲁克斯后来在《人月神话》中痛陈：“PL/I就像一个拥有100个按钮的仪表盘，每个按钮都精巧无比，但没有飞行员知道该按哪个。”IBM最终不得不允许OS/360的核心模块继续使用汇编语言，PL/I则退居“可选语言”的地位。 ## 技术遗产：超前者的宿命与后来者的阶梯 PL/I的商业失败在1970年代已成定局。IBM在1974年停止了对PL/I的主动推广，转而支持更轻量的PL/I子集语言（如PL/M用于微处理器）。但它的技术遗产却以更隐蔽的方式渗透进整个软件行业。1979年，美国国防部在开发Ada语言时，直接借鉴了PL/I的异常处理机制和任务并行模型。1985年，C++的创始人比雅尼·斯特劳斯特鲁普承认，PL/I的“结构体与指针结合”思想启发了C++的类设计。甚至Java的“checked exception”（受检异常）也能在PL/I的`ON CONDITION`中找到原型。 直到今天，全球仍有数千个PL/I程序在航空订票系统、银行核心账务系统和政府社保系统中运行。2019年，美国联邦航空管理局（FAA）的旧系统升级招标中，仍然要求投标方必须支持PL/I代码的维护——因为这些用1960年代语言编写的程序，每天还在处理着全美70%的航班调度。IBM在2022年发布的z/OS 2.5版本中，依然提供了PL/I的运行时环境，只不过编译器已经变成了基于LLVM的现代实现。 PL/I的故事揭示了一个残酷的技术真理：**在软件工程中，“全能”往往意味着“全不能”**。它试图用一门语言解决所有问题，却忽略了不同领域对编译速度、内存占用、开发效率的差异化需求。当FORTRAN和COBOL通过专注特定领域获得了长寿，PL/I却因为追求“绝对通用”而陷入性能泥潭。更讽刺的是，它超前引入的特性——并发、异常、动态内存——直到多核处理器和互联网时代才找到真正的用武之地，但那时已是C++和Java的天下。 ## 评论 PL/I的兴衰是软件史上最昂贵的“技术债”案例。IBM当时拥有垄断性的硬件平台（System/360市场占有率超过70%），却错误地认为软件设计可以像硬件一样“向下兼容一切”。这种“技术帝国主义”思维让PL/I成为一门被设计委员会“创造”出来的语言，而非从实际需求中“生长”出来的工具。它教会我们：**优秀的软件设计不是罗列所有功能，而是精准地“不做什么”**。当雷德蒙德团队把浮点运算、字符串处理、并发任务等特性统统塞进一门语言时，他们实际上是在用代码复制IBM硬件产品的“大统一”哲学——但软件不同于硬件，它需要更精细的抽象层级和更明确的适用边界。PL/I的遗产是矛盾的：它让后来的语言学会了“模块化”和“可扩展性”，却用自己的失败证明了“通用性”的极限。在今天的微服务与领域驱动设计时代，这个教训依然振聋发聩——试图用一把钥匙打开所有门的野心，最终只会把自己锁在门外。 ## 参考资料 - [PL/I - Wikipedia](https://en.wikipedia.org/wiki/PL/I) — PL/I的完整历史、语法特性和发展脉络 - [The IBM System/360 and PL/I: A Marriage of Convenience](https://www.ibm.com/ibm/history/ibm100/us/en/icons/system360/) — IBM官方对System/360与PL/I关系的回顾 - [Fred Brooks, "The Mythical Man-Month" (1975)](https://en.wikipedia.org/wiki/The_Mythical_Man-Month) — 布鲁克斯对PL/I在OS/360开发中问题的经典分析 - [George Radin, "The Early History of PL/I" (1978)](https://dl.acm.org/doi/10.1145/800025.1198366) — PL/I首席架构师的回忆录，收录于ACM SIGPLAN历史会议 - [Fran Allen, "The History of Compiler Optimization" (2004)](https://www.computer.org/csdl/magazine/an/2004/04/a4020/13rRUy5B3kD) — 艾伦谈PL/I编译器的全局优化技术突破