在编程世界的“神课”谱系里，有一场演讲的地位极其特殊：它几乎不讲任何代码细节，却在近三十年里被无数程序员、语言设计者和工程管理者反复引用——Guy L. Steele Jr. 在 OOPSLA 1998 大会上的主题演讲 《Growing a Language》（生长一门语言）。
它的开场是一场“行为艺术”：这位参与创造 Scheme、主编过 Java 语言规范的大师，给自己立了一条残酷规矩——接下来一段时间只许说单音节英文词。每想用一个多音节词，他必须先用已经“买下”的短词，把这个长词当众定义出来。观众在最初十几分钟里看着他笨拙地“词穷”，然后恍然大悟：他不是在玩文字游戏，他是在让所有人亲口尝一尝——当你手里的语言不够用时，那种寸步难行是什么滋味。
这条视频值得读三层：一层是语言设计的底层哲学（语言为什么必须能“生长”）；一层是真实的历史验证（Java 泛型迟到的十年，完美兑现了这场演讲的预言）；还有一层是每个工程师都能带走的实操方法——如何在团队里“养词表”，让代码自己长出领域语言。
| 项目 | 内容 |
|---|---|
| 原题 | Growing a Language |
| 中文译名 | 《生长一门语言》 |
| 演讲人 | Guy L. Steele Jr.（Scheme 联合创造者、《Common Lisp the Language》作者、Java 语言规范主编之一） |
| 场合 | OOPSLA 1998 大会主题演讲（面向对象编程、系统、语言与应用国际会议） |
| 年份 | 1998 年秋 |
| 时长 | 约 50 分钟 |
| 观看方式 | YouTube 检索 "Guy Steele Growing a Language" 可见多个完整录像版本 |
| 数据注记 | 本次写作环境无法联网核验具体上传频道与播放量，此类实时数据略去，请以 YouTube 检索结果为准 |
说明：这是一场 1998 年的老演讲，但它是编程语言设计领域公认的“必读神课”，Steele 本人在 1999 年将其整理成同名论文，发表于学术期刊《Higher-Order and Symbolic Computation》，全文可查。本文围绕该演讲展开深度解读。
Steele 上台后久久不说一个“长词”。他要表达"language"（三音节）这个概念时，只能绕着弯子说"a way to say things"。想要"define"？先定义"de-fine"是什么。这种笨拙是精心设计的：如果你使用的语言里没有某个词，你就必须用已有的词把它造出来——造词是要付利息的。
观众很快意识到，这不正是程序员每天面对的处境吗？你的编程语言、你的代码库、你的团队黑话，就是你全部的“词表”。词表不够用的时候，你要么忍受啰嗦和重复，要么自己造词——而一门语言是否允许你优雅地造词，恰恰是 Steele 想谈的全部。
这个开场的高明之处在于：他没有先给论点再举例，他让论点直接发生在观众身上。这是教学设计的顶级示范——媒介即讯息。
装置铺完后，Steele 抛出正题：编程语言本质上是一套“词”（词汇/抽象）的组合系统。变量、函数、类型、宏，都是不同粒度的“词”。程序员的工作，就是把业务里的概念翻译成语言里现成的词；当现成的词不够用，就去定义新词——写一个函数，建一个抽象，造一种 DSL。
于是他给出全场的核心主张：一门好的语言，必须把“生长能力”设计进去。语言设计者不可能预知所有领域——你无法在设计时就知道用户明天要写的是游戏、报表还是操作系统。既然预见不了，唯一不会过时的设计，就是把“加新词的能力”本身做成一等公民，让用户能把语言生长得贴合自己的领域。
他反复强调一个动词的分量：是 grow（生长），不是 design（一次性设计）。设计是设计者的事，生长是所有使用者的事。
1998 年的 Java 正当红，但 Steele ——作为 Java 语言规范的编著者之一——当众拆自家的台：Java 当时没有泛型（generics）。
他想演示写一个“能装任何类型元素的容器”或者“能排序任何类型数组”的函数，结果处处碰壁：你只能声明装 Object 的容器，取出来时手动强制转型；装错了类型，编译器一声不吭，错误拖到运行时才炸。更难堪的是，这些泛型设施用户自己加不上去——Java 的语言机制没有给使用者留下生长点。设计小组没来得及做的功能，全世界的程序员只能干等。
这里有一层辛辣的讽刺：连 Steele 这种级别的设计者，在自己参编的语言面前也是“用户”。他用亲身处境证明：当语言不能生长时，用户是被动的；设计者的远见是有上限的，而上限迟早会卡住你的喉咙。
（耐人寻味的巧合是：就在同一届 OOPSLA '98 上，Bracha、Odersky、Stoutamire、Wadler 发表了 GJ 论文《Making the Future Safe for the Past》，正是这套“把泛型加进 Java”的方案，日后成为 Java 5 泛型的蓝本——2004 年，Java 终于长出了这个“新词”，距 Steele 的演讲整整六年。）
什么样的机制能让语言生长？Steele 带观众快速巡视了几个谱系：
#define 只做文本替换，长得出来，但长得歪歪扭扭——Greenspun 第十定律吐槽的正是这种状态：任何足够复杂的 C 程序里，都藏着一个临时拼凑、未经规范、bug 丛生的半个 Common Lisp。演讲后半段，他还展示了自己的新构想（这次演讲其实是他日后主导 Fortress 语言的序曲）：高性能计算领域需要的数学记法，应当由“可生长的语言”来承载，而不是等标准委员会十年磨一剑。
演讲的结尾，Steele 引用了 Fred Brooks《人月神话》里那段著名的话——程序员如同诗人，工作的对象几乎就是纯粹的思想材料，他凭借想象力，在空气中建造城堡，而他的材料是如此轻盈，如此易于修改和重构。
然后他补上了自己的落点：要让更多人能把思想变成程序，就要让更多人拥有造词、用词、分享词的能力。语言生长从来不是一个人的事——一个新词（一个抽象、一个库、一种记法）只有在共同体中流通起来，被文档、被标准、被社区公认，才算真正“长进”了语言。
这也是整场演讲最容易被忽略的一层：它表面谈语言设计，底色却是工程师共同体的知识治理——你生长出来的词，能不能让别人也用起来？
1. Scheme 与“Lambda 论文”（1975-1979）。Steele 与 Gerald Jay Sussman 于 1975 年在 MIT 人工智能实验室创造 Scheme（见当年的 AI Memo 349《SCHEME: An Interpreter for Extended Lambda Calculus》）。随后两人写下著名的“Lambda 论文”系列，其中《Lambda: The Ultimate GOTO》（1977）论证了过程调用本质上可以编译成跳转，直接催生了 Steele 1978 年的硕士论文 Rabbit——一个把 Scheme 编译成高效机器码的编译器。“用户的代码可以成为语言的一部分”，这条信念从那时就埋下了。
2. Java 泛型史实。演讲对 Java 缺泛型的批评有严格的事实支撑：GJ 编译器方案（OOPSLA '98 发表）被 Sun 采纳演化，Java 5 于 2004 年正式引入泛型（采用类型擦除实现）；核心作者 Gilad Bracha 后续推动了相关规范化，Martin Odersky 则转身创造了 Scala（2003 年前后发布）——把“生长性”推向极致的另一条路。Steele 的预言不是蒙的，是被官方路线图逐条兑现的。
3. 宏系统的理论问题。“生长机制”并非免费午餐。1986 年 Kohlbecker、Friedman、Duba、Haynes 发表的《Hygienic Macro Expansion in Lisp》提出了“卫生宏”概念，解决了宏展开时的变量捕获问题——这正是后来 Scheme 标准采纳 hygienic macro 的理论基础。演讲 enthusiasm 背后，学术界对宏的“卫生难题”早有系统性回应。
4. 思想谱系的两翼。Steele 的主张站在一条长线的延长线上：Alan Kay 的 Smalltalk/Dynabook 构想（软件应当由可组合的消息单元构成）、Richard Gabriel 的《Worse is Better》（1991，简单的、可生长的设计往往胜过完备的设计）。而它的对立面同样源远流长：Rich Hickey 在 Strange Loop 2011 的《Simple Made Easy》里正告世人—— indiscriminate 的“组合”与“生长”会让复杂度暗中复合（complecting），简单才是稀缺品。理解这场演讲最好的方式，是把它放回这场持续至今的“生长派 vs 简单派”论战之中。
5. 与领域驱动设计的暗合。Eric Evans 2003 年的《Domain-Driven Design》提出“统一语言（Ubiquitous Language）”：团队必须把业务词汇沉淀成代码与对话共用的词表。这与 Steele 的“养词”哲学在软件工程层面互为镜像——一个管语言设计，一个管代码库治理。
证据充分的部分：
存在争议或需打折的部分：
1. 学语言，先摸清它的“生长点”。 下次学一门新语言，别只背语法，先回答四个问题：它能加新词吗（函数/类型/宏）？新词能和旧词无缝共存吗（还是隔一层怪异的仪式）？工具链认得新词吗（补全、跳转、重构还灵吗）？团队里其他人读得懂你的新词吗？这四问比“哪个语言排行榜第一”有价值得多。
2. 把领域词表“养”进代码库。 Steele 的哲学落到日常工程，就是 DDD 说的统一语言：让业务里的概念直接长成代码里的名字。电商系统里的“拆单”、风控里的“穿透”，如果一个概念在需求文档、飞书讨论和代码里是同一个函数名，你的代码库就成了一门“会自己生长的语言”；反之，文档说一回事、代码是另一回事，词表的汇率每天都在崩。造词之后别忘了分享——没有文档和评审共识的“新词”，只是个人方言。
3. 选型时，看“生长的治理”而不只看功能列表。 评估一门语言/框架，看三件事：扩展机制是否一等公民（宏、泛型、插件协议）；社区有没有成熟的“长词流程”（PEP、RFC、提案文化）；以及——被所有人忽略的——有没有修剪机制（淘汰提案、废弃流程）。只会长不剪的语言和团队，最后都会被自己的词表压垮。
flowchart TD
A[困境：词不够用] --> B[装置：只说单音节词]
B --> C[主张：语言要能生长]
C --> D[机制：宏、泛型、元编程]
C --> E[反例：Java缺泛型之痛]
D --> F[代价：工具链与可读性]
E --> G[验证：2004泛型落地]
F --> H[平衡：增长也要修剪治理]
G --> H
H --> I[启示：在共同体里养词表]
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。