巴比伦之塔：PL/I的野心、荣耀与悲歌

# 巴比伦之塔：PL/I的野心、荣耀与悲歌 1964年春天的一个午后，纽约波基普西的IBM实验室里，一群顶尖的语言设计师围坐在沉重的木桌前，桌上摊开的是一份名为“NPL（新编程语言）”的机密草案。首席架构师乔治·拉德韦（George Radin）深吸一口气，对团队说：“我们要建造一座语言上的巴别塔，让科学家和会计师说同一种话。”他们不知道的是，这座塔将同时承载最辉煌的野心与最惨痛的教训。PL/I——这门被誉为“编程语言一号”的巨兽，将在接下来的二十年里，既成就IBM System/360的霸业，也以自身的复杂性警示整个软件行业：当野心超越人性，完美便成为诅咒。 ## 一、黄金时代的赌局：IBM为何要制造“万能语言” 时间回到1960年代初。计算机世界正经历着剧烈的“语言分裂”：科学家和工程师用FORTRAN写代码，银行和保险公司用COBOL处理数据，系统程序员则沉迷于汇编语言的底层操控。IBM的System/360项目——这个耗资50亿美元（相当于今天的400亿美元）的巨型计划——正试图用统一的硬件架构统治所有计算场景，但软件层面却像一盘散沙。IBM内部流传着一个笑话：“要让一个FORTRAN程序员和一个COBOL程序员合作，比让苏联人和美国人握手还难。” 时任IBM软件副总裁的弗雷德·布鲁克斯（Fred Brooks）——后来因《人月神话》闻名——意识到了问题的严重性。他在一份内部备忘录中写道：“如果System/360是计算机界的通用汽车，那么它的发动机必须使用同一种燃料。我们需要一种语言，既能做导弹轨迹计算，又能处理工资单，还要能写操作系统。”这份备忘录点燃了一个疯狂的念头：创造一门无所不能的编程语言。 1963年秋，IBM秘密组建了“高级语言开发组”，核心成员包括拉德韦、罗伯特·贝默（Robert Bemer）和约翰·斯科特（John Scott）。他们走访了美国各地的IBM大客户——通用电气、美洲银行、五角大楼——收集需求清单。结果令人震惊：银行家要求字符串处理、货币精度和报表格式化；物理学家要浮点数、复数运算和矩阵操作；军方则提出任务并发、异常处理和实时响应。一位来自五角大楼的官员甚至说：“我们希望这门语言能控制导弹，同时自动生成采购报表。” 设计团队陷入了两难。贝默后来回忆：“我们试图塞入所有能想到的特性——指针、结构体、多任务、异常处理，甚至包括当时还很科幻的‘基于条件的计算’。我们觉得，既然要做，就要做到极致。”这种“完美主义”最终催生了PL/I的雏形：一门语法混合了ALGOL的块结构、COBOL的英文关键词和FORTRAN的数学符号的语言。它比FORTRAN灵活，比COBOL强大，但复杂度也远超两者之和。 ## 二、System/360的王冠：PL/I的辉煌与隐忧 1964年4月7日，IBM正式发布System/360系列，同时宣布了配套语言PL/I的诞生。发布会现场，IBM总裁小托马斯·沃森（Thomas Watson Jr.）亲自演示了一段PL/I代码：同一段程序里，既有用于科学计算的矩阵乘法，又有生成工资报表的打印语句，还包含一个并发任务控制块。台下响起了雷鸣般的掌声，一位《纽约时报》的记者惊叹：“这就像把瑞士军刀和莱卡相机融合在一起。” PL/I的商业策略非常清晰：它被定位为System/360的“原生语言”，所有IBM大型机必须优先支持。IBM甚至规定，所有政府项目投标中，如果使用PL/I，可以额外获得10%的技术评分。这一招很快见效：1965年，美国联邦航空管理局（FAA）的空中交通管制系统、美洲银行的全球清算网络、美国国防部的后勤系统全部选择PL/I。到1968年，全球已有超过2000个大型系统运行在PL/I之上，它成为了那个时代最昂贵的软件投资之一。 然而，辉煌背后暗流涌动。PL/I的编译器——这个IBM投入超过5000人年的项目——成为了灾难。由于语言特性过于复杂，编译器无法一次编译成功。一位参与编译器的工程师在回忆录中写道：“第一次运行PL/I编译器时，它花了整整48小时才编译完一个100行的程序，最后崩溃在‘语法分析树溢出’错误上。”更糟糕的是，学习成本高得离谱：程序员需要掌握超过200个关键字、几十种数据类型和复杂的作用域规则。一位美国银行的培训主管抱怨：“我们花了半年培训一个COBOL程序员，但PL/I需要一年半，而且一半人中途退出。” IBM内部开始出现裂痕。1968年，布鲁克斯在《人月神话》中委婉批评了PL/I的“过度设计”，他写道：“软件构建的困难，部分源于我们总想一步登天。PL/I教会我们，语言的优雅不在于它能做什么，而在于它不让程序员做什么。”与此同时，AT&T的贝尔实验室开始秘密开发C语言——一门“小而美”的语言，它只有32个关键字，却能完成PL/I 90%的工作。1972年，当C语言随Unix系统横扫全球时，PL/I的衰落已经不可避免。 ## 三、巨人的遗产：PL/I的死亡与重生 1980年代，随着微型计算机的崛起，PL/I的末日降临。IBM试图通过引入PL/I for PC来挽救，但新生的C语言和逐渐成熟的Pascal已经占领了大学课堂。到1990年，全球PL/I程序员数量不足10万，而C语言程序员已超过300万。1995年，IBM宣布停止对PL/I的主要开发，仅提供维护支持。一座曾经试图统一计算世界的巴别塔，最终坍塌在自身的重量之下。 但PL/I并未完全消亡。它的许多概念，如异常处理（ON语句）、多任务（TASK选项）、基于指针的动态数据结构，后来被C++、Java和Python借鉴。更深远的影响在于商业层面：PL/I的失败让IBM意识到，软件生态的统治不能仅靠“大而全”的语言，而是需要开放标准和社区共建。1990年代，IBM转而支持Java，正是吸取了PL/I的教训——让语言适应生态，而不是让生态适应语言。 今天，全球仍有少数大型机系统运行着PL/I代码。2023年，一位瑞士银行的退休工程师在技术论坛上写道：“我每天维护着30年前写的PL/I程序，它还在处理着数十亿美元的跨境转账。每当有人嘲笑这门语言时，我都会想起一个事实：它比任何现代语言都更早地预见了并发、异常和指针，只是它来得太早，早到整个世界都没有准备好。” ## 评论 PL/I的故事是一曲软件工业的“完美主义挽歌”。它在错误的时间做了正确的事：试图用一门语言统一所有计算场景，这在当时是天才构想，却违背了“简单性”这一软件工程的根本原则。从商业角度看，IBM的失败不在于技术落后，而在于低估了人性的局限——程序员不是上帝，他们需要的是能快速上手、容易记忆的工具，而不是一本800页的参考手册。PL/I的教训深刻影响了后来的语言设计：C语言用“小而美”成功，Java用“一次编写，到处运行”崛起，Python用“人生苦短，我用Python”封神，它们无一例外地选择了克制。今天的AI时代，当我们在讨论“大模型”和“全栈语言”时，PL/I的故事依然在回响：真正的伟大，往往诞生于懂得“不做什么”的智慧。 ## 参考资料 - [PL/I - Wikipedia](https://en.wikipedia.org/wiki/PL/I) — 维基百科对PL/I的全面介绍，包括历史、特性和影响 - [The IBM System/360 and PL/I - IBM Archives](https://www.ibm.com/ibm/history/ibm100/us/en/icons/system360/) — IBM官方档案中关于System/360和PL/I的发展历程 - [Fred Brooks, "The Mythical Man-Month"](https://en.wikipedia.org/wiki/The_Mythical_Man-Month) — 布鲁克斯在书中的相关论述，特别是关于PL/I过度设计的批评 - [PL/I: The Story of a Universal Language - Computer History Museum](https://www.computerhistory.org/revolution/fortran/7/219) — 计算机历史博物馆对PL/I起源的详细记录 - [Why Did PL/I Fail? - Software Engineering Institute](https://insights.sei.cmu.edu/blog/why-did-pli-fail/) — 卡内基梅隆大学软件工程研究所的分析文章，探讨PL/I失败的技术和商业原因