巴别塔的诅咒：PL/I，那个试图吞下整个软件世界的巨兽

# 巴别塔的诅咒：PL/I，那个试图吞下整个软件世界的巨兽 1964年，在IBM位于纽约州波基普西的实验室里，一群顶尖的计算机科学家正在酝酿一个近乎狂妄的计划：创造一种“终极编程语言”——它既能像FORTRAN一样进行复杂的科学计算，又能像COBOL一样处理繁琐的商业数据，甚至还要具备当时闻所未闻的并发处理、异常管理和递归能力。这种语言被称为PL/I（Programming Language One），名字本身就暗示着它的野心：这是“第一种”也是“唯一一种”语言。然而，这个试图统一软件世界的巴别塔，最终却成了软件史上最著名的“大而全”的警示碑。 ## 巨人的野心：当FORTRAN与COBOL的战争需要终结者 1960年代初的软件世界，是一个语言割据的“战国时代”。IBM的System/360大型机即将问世，这台机器承载着IBM“一统江山”的硬件野心——用一个统一的架构覆盖从科学计算到商业处理的全部需求。但软件层面却是一片混乱：科学家们坚守FORTRAN，认为它是数学精度的化身；商业程序员们死抱COBOL，因为它的数据描述能力无可替代。两种语言的拥护者互相鄙视，FORTRAN程序员嘲笑COBOL“像写英文作文一样啰嗦”，而COBOL程序员则反击FORTRAN“连个像样的文件系统都没有”。 IBM的工程师们面临一个致命问题：如果System/360需要同时支持两种完全不同的语言，那它的操作系统和编译器将变得极其臃肿。更糟糕的是，许多企业客户既需要科学计算（如工程设计）又需要商业处理（如工资核算），他们不得不在两种语言之间切换，数据格式不兼容，程序员培训成本高昂。 1963年，IBM的“高级语言开发委员会”在纽约召开了一次秘密会议。会议的核心人物是乔治·拉德（George Radin），一位35岁的语言设计师，他提出了一个大胆的想法：“为什么不让一种语言同时拥有FORTRAN的算术能力和COBOL的数据结构？”拉德在会议上举起一杯水，比喻道：“FORTRAN和COBOL就像水和油，它们无法融合是因为设计者从一开始就没打算让它们共存。但如果我们从零开始设计一种语言，让科学计算和商业处理成为它的两个原生特性呢？” 这个想法立刻引发了激烈争论。反对者认为这无异于“发明永动机”——语言设计的核心原则是“小而美”，FORTRAN和COBOL的专精正是它们的优势。但拉德所在的支持派得到了IBM高层的大力支持，因为System/360的市场策略需要软件层面的“大一统”。1964年，IBM正式启动了PL/I项目，拉德担任首席架构师，团队还包括后来发明了“指针”概念的约翰·巴克斯（John Backus，FORTRAN之父）的同事。 ## 技术狂想曲：当“万能”成为诅咒 PL/I的设计过程，是一场不折不扣的技术狂想。拉德和他的团队像一群贪心的收藏家，把当时所有已知的编程概念一股脑塞进语言里：FORTRAN的浮点运算、COBOL的记录和文件系统、ALGOL的块结构和递归、甚至还有从操作系统借鉴的并发任务和异常处理。他们甚至超前地加入了“多任务”和“基于条件的异常处理”——这在1964年是革命性的，因为当时的操作系统本身都还没有成熟的并发模型。 但问题很快暴露出来。为了兼顾“科学”和“商业”，PL/I的设计者不得不在各个层面做出妥协。例如，FORTRAN的默认数据类型是浮点数，COBOL的默认数据类型是定点数，PL/I决定让程序员同时拥有两者，但数据类型转换规则变得异常复杂：一个“+”（加法运算符）在不同上下文中可能意味着浮点加法、定点加法、甚至字符串拼接。更致命的是，PL/I的“默认规则”极其隐晦——如果程序员忘记声明变量类型，编译器会根据变量名的第一个字母自动推断（类似FORTRAN），但这个推断规则又受制于“上下文敏感”的复杂设计。 这种“万能”设计的代价是巨大的。PL/I的编译器体积是FORTRAN编译器的五倍以上，编译速度慢得像“在沼泽里拖车”。更糟糕的是，由于语法和语义过于复杂，编译器很难生成高效的机器代码。一位IBM工程师在内部备忘录中写道：“PL/I的编译器就像一头怀孕的大象——它什么都想干，但每一步都走得摇摇晃晃。” 1966年，PL/I的第一个正式版本随System/360发布，市场反响却出乎IBM的意料。大型企业客户对PL/I的“全能”表示欢迎，因为这意味着他们可以用一种语言培训所有程序员。但科学计算社区却嗤之以鼻：FORTRAN程序员抱怨PL/I的浮点运算速度慢了30%，而商业社区则批评PL/I的数据描述能力不如COBOL直观。更尴尬的是，PL/I的异常处理机制虽然先进，但大多数程序员根本不会用——他们只会用“ON ERROR”捕获所有错误，然后草草退出程序。 转折点出现在1968年。美国国防部（DoD）正在寻找一种用于“嵌入式系统”的通用语言，PL/I凭借其并发和异常处理能力被纳入候选。但经过评估，DoD的专家发现PL/I的可靠性存在严重问题：由于“默认规则”过于灵活，一段看似正确的PL/I代码可能在特定输入下触发意想不到的类型转换，导致程序崩溃。一位DoD的评审员尖锐地评论：“PL/I不是一种语言，它是一个陷阱。” ## 遗产：巴别塔的碎片如何照亮未来 尽管PL/I从未取代FORTRAN和COBOL，但它在System/360大型机生态中取得了实质性的成功。到1970年代，超过30%的System/360用户使用了PL/I，尤其是在需要混合科学计算和商业处理的领域——比如航空公司的订票系统（需要同时处理座位算法和财务数据）和银行的风险模型（需要复杂的数值模拟和事务处理）。IBM甚至专门为PL/I开发了“优化编译器”，使其在某些场景下的性能接近FORTRAN。 但PL/I的真正遗产，在于它播下的技术种子。它的“多任务”概念直接影响了后来的Ada语言（美国国防部的官方语言），而它的“基于条件的异常处理”则被C++和Java继承。更重要的是，PL/I的失败让软件界深刻认识到“大而全”的危险——1980年代诞生的C++和1990年代的Java，虽然也试图融合多种范式，但始终坚持“渐进式扩展”的原则，而不是像PL/I那样试图一口吃成胖子。 1990年代，随着个人电脑和UNIX系统的兴起，PL/I逐渐退出了主流。但直到2023年，IBM的大型机Z/OS仍然支持PL/I，一些银行和保险公司仍在运行用PL/I编写的遗产系统。这些代码就像时间胶囊，记录着一个时代的技术野心。 ## 评论 PL/I的传奇，本质上是一场“技术乐观主义”的悲剧。1960年代的计算机科学家们相信，只要设计足够“完整”，一种语言就能解决所有问题。这种思维源于硬件领域的“通用计算机”理念——既然一台机器可以执行任何程序，那么一种语言也应该能表达任何逻辑。但他们忽略了一个关键事实：软件的复杂性不是线性的，而是指数级的。每增加一个特性，不仅会成倍增加编译器的复杂度，还会引入无数预料之外的交互。PL/I的教训至今仍具现实意义：在软件设计中，“少即是多”不是一句口号，而是一条铁律。今天的微服务架构、Rust语言的所有权模型、甚至Go语言的简洁语法，都可以看作是对PL/I“巴别塔”的逆向反思——真正的强大，来自克制的设计。 ## 参考资料 - [PL/I - Wikipedia](https://en.wikipedia.org/wiki/PL/I) — PL/I的历史、设计哲学和技术细节 - [The PL/I Programming Language: A History](https://www.ibm.com/docs/en/zos/2.5.0?topic=pli-history) — IBM官方文档对PL/I发展的回顾 - [George Radin and the Design of PL/I](https://www.computerhistory.org/collections/catalog/102657998) — 计算机历史博物馆对PL/I首席架构师的访谈 - [PL/I: The Language That Tried to Be Everything](https://www.techrepublic.com/article/pli-the-language-that-tried-to-be-everything/) — TechRepublic对PL/I技术遗产的分析 - [The Rise and Fall of PL/I](https://www.softwarepreservation.org/projects/PL_I/) — 软件保护协会对PL/I的历史文件存档