--- id: "sMllOlxVgD0" title: "贝尔实验室、顶尖程序员与 C 语言为何胜出" channel: "Ryan Peterman" host: ["Ryan Peterman"] guests: ["Brian Kernighan"] date: "2026-10-26" updated: "2026-10-27" duration: "1:28:38" duration_seconds: 5318 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=sMllOlxVgD0" canonical: "https://pod-exp.pages.dev/sMllOlxVgD0/" transcript_jsonl: "https://pod-exp.pages.dev/sMllOlxVgD0/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["开源软件","数学与科学","科技趋势"] series: [] --- # 贝尔实验室、顶尖程序员与 C 语言为何胜出 > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** Brian Kernighan 回忆了 AT&T 贝尔实验室的研究文化、宽松管理和长远投入如何带来 Unix、C 等成果，也讲述 Ken Thompson、Doug McIlroy、Dick Hamming 等同事的故事。他解释 C 与 Unix 的相互促进、awk 的诞生、技术表达与教学经验，并讨论大语言模型对计算教育、编程乐趣和职业选择的影响。最后，他建议年轻人多尝试、保持好奇，让“有准备的头脑”更容易遇到机会。 ## [0:01] 开场 · YouTube **Ryan Peterman：** 于是，三周之内，他就给自己造出了编辑器、汇编器和操作系统。就这样，全部都是他一个人做的。 **Brian Kernighan：** 没错，完全是一个人做的。 **Ryan Peterman：** 这位是 Brian Kernighan，贝尔实验室前技术人员、《C 程序设计语言》原版合著者，也是让“Hello, World!”广为人知的人。我问了他许多关于在贝尔实验室工作是什么感受的问题。 **Brian Kernighan：** 没有截止日期，没有项目，也没有别人给你设定的目标、指标之类的东西。 **Ryan Peterman：** 当时有个 secrets 文件被提交进代码仓库，所以你和所有同事的密码其实都在里面？ **Brian Kernighan：** 是啊。 **Ryan Peterman：** 我看到你写过，你觉得大语言模型总体上是负面影响还是正面影响？ **Brian Kernighan：** 那我今天该得罪谁呢？ ## [0:43] 贝尔实验室是什么，以及他如何入职 · YouTube **Ryan Peterman：** 下面是完整节目。能不能介绍一下贝尔实验室是什么，以及你当年是怎么得到那份工作的？ **Brian Kernighan：** 贝尔实验室大致是 AT&T 的研究部门。它成立于 1923 年——我记得大概是 1923 年或 1925 年。那时 AT&T 正在扩张，吞并了全国许多地方电话公司。他们意识到需要更深入地理解相关技术，才能改善服务，于是成立了一个研究机构，叫贝尔电话实验室。最初在纽约西街。那里的人做各种与改善电话服务有关的工作。 大约在 1963 年，也就是 60 年代初，他们把整个机构搬到了新泽西州北部的默里希尔，离萨米特等地不远，距纽约市向西约 25 英里。那是个规模很大的机构：大概 3000 人在一组彼此相连的楼里工作，研究领域五花八门，包括物理、半导体物理、器件、化学、光纤等等。还有偏理论的数学研究；随着大家逐渐意识到计算会以某种方式成为未来的一部分，计算机及相关研究也越来越多。 1966 年夏天，我还是普林斯顿的研究生，不过在剑桥的麻省理工学院拿到了一份实习，在 MAC 项目组工作，基本上就是 Multics 项目。我用科比和同事们开发的最早的分时系统 CTSS，为刚刚起步的 Multics 系统开发软件。这很有意思，我很喜欢。至于自己做的东西是否真正有用，我不太确定。 接下来一年，我又在默里希尔的贝尔实验室实习。当时我大约是普林斯顿第三年研究生。我在那里度过了很愉快的夏天，实际上是和 Doug McIlroy 一起工作。夏天结束后我回到学校，继续拖着不做论文——我想研究生大概都会这样。1968 年夏天我又去实习，这次和 Shan Lynn 合作。我们研究的是导师提出的图划分问题，最后想出了一个在部分情形下表现不错的算法。我还找出了几个可以处理得很好的特殊情况。之后我很快写完论文，终于脱身了。 ## [4:44] 贝尔实验室是什么，以及他如何入职 · YouTube **Brian Kernighan：** 我想，我能进贝尔实验室，部分是靠某种校友人脉：普林斯顿有人认识贝尔实验室的人，因为两家机构之间往来很多。MIT 那边也有帮助。前一年去实习的一位同学表现出色，他们大概因此觉得普林斯顿来的学生应该也不错。我也很感谢那位同学。 **Ryan Peterman：** 如今贝尔实验室已经是传奇。当时社会上怎么看它？如果你问同辈“你觉得贝尔实验室怎么样”，他们会怎么说？ **Brian Kernighan：** 我猜这要看领域，但大多数人大概会觉得：“那是个很棒的地方。”在物理科学领域，它无疑是强者。晶体管就是在那里诞生的，通信领域的许多成果也出自那里，包括信息论和纠错码。这些关键技术进展都来自贝尔实验室。 贝尔实验室是科学共同体的一部分。那里的人在同样的期刊发表论文、参加同样的会议，也和大学里的同行合作。它当时确实深深融入科学界。主要是物理科学，不过也扩展到其他相关领域。数学家也都非常出色，而且多半是应用数学家，而不是理论数学家。 ## [6:36] 为什么贝尔实验室诞生了那么多发明 · YouTube **Ryan Peterman：** 你刚才说的这些成果，对人类的价值大得惊人，比如晶体管。为什么这么多成果会出自一家研究机构，而它又隶属于一家今天并不以这些创新闻名的公司？ **Brian Kernighan：** AT&T 为贝尔实验室的各种贡献提供了资金。我认为其中的运作方式是，AT&T 为全国几乎所有地区提供电话服务——也许覆盖 80%，总之是很大一部分，因此收入相当有保障。不过它受监管，是所谓“受监管的公共垄断企业”。资费由许多州和联邦机构设定、限制或至少审查，所以公司能做的事情有限。作为交换，它在电话业务投资上能获得大致有保障的回报；同时，它也必须给几乎所有人提供电话服务，即便你住在很偏远的地方。 他们可以从这笔相当稳定的收入里抽出一小部分——我随便举个数字，1% 或 2%——来资助研究，从而改善服务。这就是基本的财务安排。另一个关键是稳定：收入可以预测，研究经费就能持续。AT&T 几乎没有竞争，可以从长远角度做事。有人想花一两年、三年研究一个点子，也可以放手去做。即使你的点子、我的点子都不怎么样，别人也可能有好点子。把这些尝试累积起来，几乎总能产出有用的东西。 **Ryan Peterman：** 你觉得是什么让贝尔实验室特别有吸引力，能把那么多优秀人才招来？ **Brian Kernighan：** 对我来说肯定有偶然和运气的成分：恰好在对的时间、对的地方，也跟着一些为我铺路的人走。物理学家从好大学毕业后，可能去政府实验室、IBM，或者贝尔实验室。贝尔实验室在这个领域声誉卓著，而且名副其实。物理、化学、材料科学等领域的人都会考虑那里。数学相关领域也一样，尤其是通信数学和通信系统。香农、哈明、博德、奈奎斯特以及更早的一批人都在那里。它声誉极好，而且属于科学共同体的一部分；不是去到一个与世隔绝的地方，从此消失。 计算领域后来也有一些相同优势，只是当时还不清楚谁会成为这个领域的代表人物。那时候计算机还很年轻；我 1969 年去贝尔实验室时，计算机科学尚未发展成成熟领域。 ## [10:37] 为什么贝尔实验室诞生了那么多发明 · YouTube **Ryan Peterman：** 你提到的许多人都是我读书时课本里的英雄。当时你觉得他们只是团队里的领头人物，还没成为传奇计算机科学家吗？ **Brian Kernighan：** 这很难说，甚至“计算机科学家”到底指什么都不太清楚。我讲个故事吧。1967 年夏天，我第一次去贝尔实验室实习。我有一间比我们现在坐的房间稍小一点的办公室；作为实习生，我不知怎么还意外地分到了一间独立办公室，这种事很少发生。第一天上午大约 11 点，我正坐在那里发愁，不知道该干什么。一位年长的先生经过门口，说：“你好，我叫 Dick，一起去吃午饭吧。”我说好，就跟他去了。我们聊得挺愉快，但我不记得聊了什么，也没记住他的姓。他离开后，我回到办公室，看到隔壁门牌上写着 Dick Hamming。哈明写过我前一个学期学数值分析时用的教材，也提出过纠错码。他就在隔壁，人特别好。他算计算机科学家吗？有点沾边吧。他后来获得了第三个图灵奖，不过具体是那年夏天还是下一年，我得查一下。 早期计算领域还没有自己的学术体系和奖励机制。**Ryan Peterman：**我采访 Leslie Lamport 时，他说自己求学早期计算机科学还没成形，也没有数学和物理那么受尊重，因为它是新兴学科。 **Brian Kernighan：** 普林斯顿也是这样。我 1964 年来读研究生，学的是电气工程。我对计算感兴趣，也想着做人工智能，但那时我什么都不懂，想法天真得不得了。我想跟 Arthur Samuels 合作，他做过一些有意思的计算机下棋研究；来了以后才发现自己并不适合。 电气工程系里有一批地位稳固、备受尊敬的学者，做传统电气工程、信息论、通信、固态物理等研究。同时还有一群对计算感兴趣的年轻人，刚从别处拿到学位，想研究计算。我不知道他们后来有没有人获得终身教职，因为年长的学者并不真正理解这个新领域。举个例子，John Hopcroft 曾做过我一年的技术导师，不过很快就发现我不是理论研究者。**Ryan Peterman：**（笑） **Brian Kernighan：** John 后来拿了图灵奖，还当过康奈尔大学工程学院院长，人很好。不过在那个时期，他在这里也未必能获得终身教职，因为计算科学当时实在太新了。 ## [14:15] 贝尔实验室的一天 · YouTube **Ryan Peterman：** 贝尔实验室以管理宽松、让工程师自己做事而闻名。那里的工程师一天是什么样？ **Brian Kernighan：** 首先，我们大概没人会称自己为“工程师”。我们做各自的事情，但“工程师”这个词不太合适，因为我们其实不是在做工程。**Ryan Peterman：**职位叫“技术人员”（Member of Technical Staff）。**Brian Kernighan：**对，基本上人人都用这个职称。 通常你想几点来就几点来，可能早上 8 点，也可能下午两三点。你坐在自己的独立办公室里，门开着，琢磨手上的事。也许在写程序，也许在证明定理——后者不是我做的。人们会经过你的办公室，进来聊一聊；你们可能在黑板上讨论技术，也可能只是挥着手比划、聊些别的。你会沿着很长的主走廊走到另一头的咖啡机，途中遇到各种人。时不时还有技术讲座，可能每周一次或两次，有时由内部同事主讲，有时请外面的人来。 某种意义上，这和大学不太一样，除了那里没有学生，因此你可以全职做研究。好处是你能做自己的研究，和同辈一起工作。我可以和 Ken Thompson 或 Dennis Ritchie 争论，他们就是我的同辈；我不需要带学生。但反过来说，我也得不到和聪明年轻人交流所带来的好处——当然，我刚加入时，自己被看作那个聪明的年轻新人。所以没有学生是有利有弊的。 **Ryan Peterman：** 工业界通常有截止日期、经理之类的。是什么让研究人员不会三点来、五点走，什么成果也不做？ **Brian Kernighan：** 没有什么机制会立刻阻止这种事。没有截止日期，没有项目，也没有别人给你设定目标。判断你有没有做事的办法是每年写一张纸，概述你做了什么。我们把它叫作“我真了不起报告”（I Am Great Report）。随后一二级管理者会聚在一起，看自己手下的报告：底层也许三十人，再往上一层六七个人，像一棵小树。他们讨论大家工作的价值，然后大致排出次序，判断谁比谁做得好，或者哪些人差不多。如果有人几年都没做出什么，会被看出来；但如果有人投入某件事却没成功，或者还在进行中但看起来有希望，那也没关系。这就是我之前说的长远眼光，不是问你上周甚至上季度做了什么，而是看两三年里的工作；评估者也不会被季度业绩牵着走。 ## [18:15] 贝尔实验室的一天 · YouTube **Brian Kernighan：** 做评审的管理者和我们一样，仍然活跃在技术一线，技术知识也很扎实。这个评估过程会逐层重复，直到大家都得到评价或排序。可以把前半段看作抽象的“功绩评估”——谁比谁做得好；接下来则是现实的功绩评估：加薪池总共这么多钱，你拿多少、我拿多少？ **Ryan Peterman：** 所以有奖金吗？**Brian Kernighan：**不是奖金之类的，只是有一笔加薪预算，总额是 x%，于是你拿 x 减去一点，我拿 x 加上一点。每年评一次，大致就是这样。 过程很审慎，管理层也很协作。如果你我各自带团队，不会只想着“我的人比你的人强”，而会提醒对方：“你忘了提 Susie 做的那件很棒的事，别漏掉她。”你会由真正理解工作、目标和追求也与你相近的人来评估；大家的目标就是把事情做好。 **Ryan Peterman：** 听起来，技术背景是这套制度的重要部分。为什么？ **Brian Kernighan：** 如果有人做出了新程序、证明了新定理或开发了新工艺，而你不够懂技术，就很难分辨里面有没有真正有用的内容。我可以把话说得天花乱坠，尤其是对不熟悉本领域的人——比如 MBA（这么说显然有失公允）。但评审你工作的人对整个领域非常了解，所以能看出什么是好成果，什么还不够好，甚至什么可能永远都不会变好。 **Ryan Peterman：** 如今“技术人员”这个职称几乎成了贝尔实验室的品牌，暗示头衔不重要、大家平等，重点是技术工作。当时头衔重要吗？文化是什么样？ **Brian Kernighan：** 头衔不重要，大家直呼名字，没有“博士”“教授”之类的称呼。严格说，“技术人员”也不是所有人的职位，实验室还有技术员、助理技术人员等支持岗位；我说的是 MTS 这一层，大致相当于现在学术界的首席研究员。计算领域里，我通常没有人协助我做研究；物理学家则可能有团队帮忙做实验，处理材料沉积等实际操作。管理体系里也有部门主管、一级经理、主任、二级经理、执行主任、副总裁，但总体很扁平。大多数人不想升职，因为那会被看成个人技术生涯的终结，让人离开自己真正喜欢的工作。 ## [22:17] 贝尔实验室的一天 · YouTube **Brian Kernighan：** 升职是要躲开的事，不是要追求的事。我说的是所谓黄金年代，大致从 60 年代末、70 年代到 80 年代初。之后情况确实变了。 **Ryan Peterman：** 你和同辈会考虑职业发展吗，还是根本不在乎？ **Brian Kernighan：** 我从没考虑过自己的职业发展。我过得很开心，周围又有很多优秀的人。至于下属的发展，我做过几年一级管理者、部门主管。我不记得当时这方面的说法有多明确，但大概有一种理念：你应该关心部门里的人。最重要的是理解他们在做什么，这样评估工作时才能公平；也能看出不同项目之间互相启发的机会，给反馈，比如“你确定这样能行吗？”或“注意一下这个问题”，帮助他们走向成功，但不替他们做决定。没人会明确告诉你“必须做这个”。顶多会有一种温和的引力，把你带向有用或有趣的方向。 **Ryan Peterman：** 你当部门主管时，有没有人跟你说自己想成长、想往上走，或者有人推着你发展？ **Brian Kernighan：** 我记得有少数人想做管理者。这不常见，不过也没什么不好。研究管理的组织架构很扁平，晋升可能要等很久。真想做管理，通常会转去开发部门，那里的规矩和工作方式很不一样。至少有几个人对晋升感兴趣，他们去了开发类岗位，承担更传统的管理职责，包括照顾下属。研究部门更像一群猫，你很难把它们管住。（笑） **Ryan Peterman：** 那你怎么会在这样的环境里当上经理？大家看起来都在避免这件事。 **Brian Kernighan：** 我一点也不想做。有几次别人劝我去研究部门的其他组织当经理，我都客气地拒绝了，因为我觉得自己所在的小组很特别——大概确实如此。后来有人问我愿不愿意在自己所在的组织当经理，我也不太热情，但还是答应了。他们有很多说法：反正迟早要做，何不现在做；现在不做可能就没机会了——这话前后矛盾（笑）；或者你不做，就会让一个不如你的人去做。最后我大约在 1981 年还是答应了。 ## [26:17] 贝尔实验室的一天 · YouTube **Brian Kernighan：** 那时我已经在那里工作了大约 12 年。这是我第一次升职。还可以，但没那么有趣了：我得负责大约 10 个人，理解他们各自差异很大的工作，能向别人介绍这些工作，还要参加更多会议。总体还不错，但不是我最喜欢的工作部分。 **Ryan Peterman：** 你当时怎么知道自己的小组很特别？现在回头看，贝雅恩向你汇报，Dennis Ritchie 和 Ken Thompson 就在附近；你也提到 McIlroy 和 Hamming。那时你怎么意识到这群人不一般？ **Brian Kernighan：** 我并不是预见到他们的工作未来会变得多么重要，而是很清楚他们非常聪明，做的事情有意思、也切合实际。我们大多数人都会用同事做出来的东西，尤其是 Unix 相关成果：那就是我们的计算环境。我们用他们开发的语言和工具，因此能直接感受到谁做的事情真正影响了我。至于预测长远影响，我们并不擅长；至少我不擅长判断谁最终会拿图灵奖。 ## [27:55] 他共事过的杰出人物 · YouTube **Ryan Peterman：** 你和许多传奇人物一起工作过。有没有谁让你印象特别深，或者让你觉得他的技术实力简直无人能及？ **Brian Kernighan：** 这样的人有好几个。最明显的是 Ken Thompson。我见过的程序员里，他无疑是最出色的，无人能比。 故事是这样的：Unix 的第一个版本是在一台老旧的 PDP-7 上开发的。那台机器已经过时，只有大约 8K 个 18 位字，规模小得可怜。他一直在摆弄驱动磁盘的程序，思考怎样调度磁盘操作才能更快。后来他妻子带着他们年幼的儿子去加州三周，他觉得自己可以趁机做点事。于是三周之内，他就给自己造出了编辑器、汇编器和操作系统。就这样。（笑）**Ryan Peterman：**一个人做的？**Brian Kernighan：**对，完全是一个人。 **Ryan Peterman：** 我以前写程序时，会去 Stack Overflow 查代码怎么写，再动手。他没有互联网资源时，是怎么做到的？ **Brian Kernighan：** 因为他比你我加起来都聪明得多。（笑）那是 1969 年，这些资源还不存在。他大概用汇编语言写代码，不是高级语言。可能先在另一台有文本编辑器的机器上写，再做成纸带，拿到那台小机器上装载，看看结果如何。 **Ryan Peterman：** 天哪。**Brian Kernighan：**这已经是很久以前的事了，但三周后他就有了能运行的操作系统。 **Ryan Peterman：** 这说明他在自己的领域里出色得超乎寻常。实验室还有很多这样的人。你提过 Doug McIlroy，他是你第一次实习时名义上的主管，研究存储分配器之类的东西。他给了你一个任务，你很快就跑去做别的了。（笑）你整个夏天做的都不是那件事，他也不介意；最后还给了你次年再来的机会。他几乎做什么都极其出色。Ken Thompson 说 Doug 是他见过最聪明的人。（笑）这已经远在我之上了。 Doug 特别擅长评估、试验和批评别人的工作，而且批评得很有建设性。他是我博士论文的第二位审阅人，大幅改善了我的写作和论文内容；他一辈子都在做这种事，现在仍然如此。他自己也写了许多实用软件，包括 Unix 的 sort 和 diff 程序，以及其他工具。他还做语言设计和开发，写过最早的一批 PL/I 编译器之一，并提出了宏的概念，贡献数不胜数。 他也是 Ken Thompson 所在部门的主管。Doug 不会告诉 Ken 该做什么，但他懂得欣赏工作，也能非常有效地从技术角度批评它。他会提出“这样做不是更好吗？”或者“这个不太行”之类的问题，推动工作变得更好。从我 1967 年第一次认识他，到他大约在 90 年代中期退休，他一直发挥着这种作用。 ## [31:55] 他共事过的杰出人物 · YouTube **Ryan Peterman：** 你刚才提到部门主管，这让我想起我查资料时读到的一件事，可能说的是 Hamming：你共事过一位部门主管，却没有下属？ **Brian Kernighan：** 那是 Hamming。**Ryan Peterman：**对。我第一次见 Dick Hamming 时一直不明白这件事。他是部门主管，办公室地上铺着地毯，电话簿里好像也这么标着。我当时天真地以为部门主管这个职位代表身份地位，后来发现完全不是这么回事。 **Brian Kernighan：** 不过他确实费了不少力气才争取到部门主管这个职位，所以他获得了相应的地位或影响力，却没有下属。这安排挺有效的：在组织里，如果级别不够高，别人可能会忽略你；相比普通 MTS，部门主管的话大概更难被忽视。**Ryan Peterman：**所以他拿到了影响力，不必做那些繁琐的行政工作。**Brian Kernighan：**对。他不是没付出过。他大概 1946 年就来到实验室，在计算领域做了很多早期工作。他是最早意识到计算机将来会成为各类研究重要组成部分的人之一。他曾预言，总有一天超过一半的研究工作会由计算机完成，而不是在实体实验室里进行；当时大家当然都笑他。 ## [33:51] 解释 Unix 的 AT&T 影片 · YouTube **Ryan Peterman：** 我在 YouTube 上看到 AT&T 公司自己发布的一部影片，叫《Unix：让计算机更易用》。你也在片中，是最先出场的人之一，翘着腿坐在桌上解释。那是怎么回事？ **Brian Kernighan：** AT&T 拍过很多这种宣传片。和其他宣传片一样，它想让不了解你的人相信你是一家很了不起的机构，正在为公众谋福利之类的。他们请了一位专业电影人，我记得他叫 Eric Belove，不过年代久远了。他会像我们现在这样和人聊天，让对方展开讲自己的工作，然后剪辑成一部让 AT&T 感觉良好的影片。 我猜影片拍于 70 年代末或 80 年代初。当时 Unix 刚开始在外界出现，是个引人注目的新事物。AT&T 想表达公司如何用计算机改善人们的生活或业务。所以我在那部片子里，可能也在其他几部片子里，负责向完全不懂技术的观众解释这是什么、有什么用、为什么新颖有趣。 **Ryan Peterman：** 我看了这部影片的评论，点赞最多的一些评论说，片里所有人——不是贬义地说——看起来都像计算机怪人。 **Brian Kernighan：** 我们那时确实还是……**Ryan Peterman：**但评论也说你表达得很清楚，能把技术讲明白。我想知道，怎样才能把技术工作讲得清楚？ **Brian Kernighan：** 一部分是设身处地地想想听众。他们对你讲的东西一无所知，你要用恰当的比喻、例子以及其他办法，让他们理解。能得到反馈也很重要。在教学环境里，你能看出听众是否听懂；如果没懂，就可以调整。拍电影难得多，因为观众要到之后才会看到，甚至可能根本看不到。 那时 AT&T 或贝尔实验室会接待贵宾参观，带他们逛实验室，展示有趣的研究成果。这种展示有时被称为“狗与小马秀”，现在这个说法可能已经过时了。Mike Lesk 和我会轮流负责 Unix 演示。某位大人物会由相应级别的实验室管理人员陪同，坐在小房间的沙发上，我就给他们展示 Unix 的妙处。哪些算妙处呢？我也说不好。其中一点是程序可以组合起来：一个程序的输出可以接到另一个程序的输入，再把好几个程序串起来。 ## [37:52] 解释 Unix 的 AT&T 影片 · YouTube **Brian Kernighan：** 我有一个标准演示，是检查文档里的拼写错误。可以把文档中的词提取出来、转成小写、排序，再和另一个词典文件比较。文档里出现但词典里没有的词，可能就是拼写错误。整套流程是一条由六七个程序组成的长管道。那时文字处理软件还没普及，大家看了会觉得挺惊奇。 有一天，一位来访者叫 William Colby，是 CIA 局长。（笑）他身边跟着一个人，手提箱真的用链子铐在手臂上。（笑）陪同 Colby 的还有 Bill Baker，我记得他当时可能是贝尔实验室总裁，同时也是外国情报顾问委员会负责人，本人也算是个情报界人物。他们坐在那里看演示。我以前做过很多次拼写检查演示，知道老机器跑起来太慢。于是前一晚我先把结果存进文件，给 Colby 看的是一个 shell 脚本：先 sleep 两秒，再 cat 出预先生成的结果。Colby 对此印象很深。所以说，别轻信演示里看到的东西。（笑） **Ryan Peterman：** 那只手提箱里是什么？炸弹还是枪？**Brian Kernighan：**肯定是核密码吧？我也不知道。（笑）**Ryan Peterman：**那位先生和手提箱的身份没有公开说明。 ## [39:47] C 为什么影响深远 · YouTube **Ryan Peterman：** 你合著过一本很有名的书，讲 C 语言。C 出自贝尔实验室，你又离它很近。现在回头看，你觉得 C 为什么影响这么大？ **Brian Kernighan：** 我觉得它在效率和表达能力之间找到了一个很好的平衡。C 大约在 1972 年诞生，那时的计算机性能很弱，内存也不多。C 最初运行的那台机器，我记得总共只有 24 KB 内存。你得给编译器、操作系统和文件留出空间；磁盘我记得也只有半兆字节，非常局促。 C 足够简单，你能看出它会怎样翻译成 PDP-11 这类机器的底层指令。语言本身不大，编译过程也容易理解，编译器相对容易实现。同时它又足够有表现力，让你能很有效地表达需要做的事情。能同时做到这两点很难。我认为 C 能成功这么久，一个原因就是它仍然兼具效率和表达能力。当然，现在很多用途都有其他更合适的语言。 C 有些功能当时做不到，因为资源不够。复杂的运行时功能很难实现，运行时检查也会占用代码空间——你的程序总共才 74 KB，怎么办？所以很多功能被省掉了。C 最初的目标是实现操作系统，写操作系统本来就不需要某些高级功能。对当时的需求来说，它确实是非常好的匹配。 之后 Unix 和 C 形成了共生关系。Unix 比当时的商业操作系统好得多，更易用、更高效，也更有趣，所以大家愿意用；他们又用 C 写程序，开发各种有意思的工具。这就形成了良性循环。 **Ryan Peterman：** （广告）OpenAI、Anthropic 和 Cursor 都在用 WorkOS，让工作更轻松。WorkOS 是一个 API 平台，只需几行代码，就能为应用添加 SSO、SCIM、RBAC 等企业功能。这些功能是把产品卖给其他公司时需要的，但通常不是你正在构建的核心部分。现在他们还增加了对 AI agent 的支持。比如 Agents 的 AuthKit 能为每个 agent 配置独立身份和短时有效、带作用域的令牌，而不是长期有效的 API key。出问题时可以撤销某个会话及其下的全部权限。另一个功能 Airlock 是授权层，agent 的每个动作都会按你用普通英语写下的规则检查，既不会一律放行，也不会让 agent 不受监督。最后，Pipes 能把 agent 接入 300 多种第三方工具，你不必自己管理令牌。如果你在构建面向企业销售的软件或 AI agent，WorkOS 能用几行代码补齐这些能力。访问 workos.com 了解详情并开始使用。感谢他们赞助本节目。 ## [43:25] awk 是如何诞生的 · YouTube **Ryan Peterman：** 我大学学 Unix 时，接触到许多工具：你提到的 Doug 写的 diff，还有其他一些工具，比如 grep，当然也有 awk。我记得很早就学过它。这个工具的由来是什么？你们为什么要做它？大约是在 70 年代中期，也就是 1976 或 1977 年吧？ **Brian Kernighan：** Al Aho 和我认识很多年了。他在普林斯顿读过书，我们本科都在多伦多大学，只不过他总比我高一年。他对正则表达式很感兴趣，也就是用来识别有趣文本模式的表达方式。我自己曾不太成功地尝试做一种文本编辑器，让人既能处理文字，也能处理数字。Peter Weinberger 对数据库一类的东西感兴趣。我们聊来聊去，想出了一种结合大家兴趣的语言：Al 的正则表达式、Peter 对数据库和报表生成语言 RPG 的兴趣，还有我希望字符串和数字都能在工具里占有同等地位的想法。 我们想了一阵子，记忆没错的话，先构思了语言设计，然后 Peter 花了一个周末把它做出来。Peter 是非常出色的程序员，而且当时已有现成工具：可以用 Steve Johnson 写的 Yacc 定义语法，用 Mike Lesk 写的 Lex 词法分析器生成器处理词法。这样做一种语言就比从头开始容易多了，很多部分都已经有人替你准备好了。Al 也有从 Egrep 发展来的正则表达式代码。一个非常聪明的程序员花一个长周末左右，就能做出一门语言。 之后我们慢慢改进它。大概五到十年后，Peter 不再积极维护，我就接手了。 **Ryan Peterman：** 很多大家习以为常的 Unix 工具，背后的故事是不是通常这样：你们自己用 Unix，发现想把输出接给 diff，或者想查找某个东西，就动手做出来？ **Brian Kernighan：** 我觉得很多工具确实是这样来的。不是先猜别人可能需要什么，而是问“我需要什么？”某件事开始让我烦恼，觉得如果有个更好的工具或语言就能改进。很多小工具都是如此：我不想手工做，现有程序又不太合适，那就做个新的，而且通常不难。 比如 Steve Feldman 写的 make。有人告诉我：“我的程序没跑起来，我不知道为什么。”原来是忘了重新编译其中一个文件。于是他想，能不能把这件事自动化？这也是一个周末项目。没过几天就有一群人在用了；接着他发现，第一版设计里的错误已经很难修了。我觉得这些工具都有类似的问题。现在回头看 awk 也有一些地方会让人想：“天啊，当初应该做得更好。” ## [47:28] awk 是如何诞生的 · YouTube **Ryan Peterman：** 很多工具的名字一看就懂，比如 diff；awk 是作者名字的首字母。但 grep 是很有名的工具，它的名字怎么来的？ **Brian Kernighan：** Ken Thompson 很会讲这个故事。大意是，在 Unix 系统最早的真正文本编辑器 ed 里，有个命令叫 g，意思是对所有匹配某个正则表达式的行执行指定命令。它的语法实际上是 `g/正则表达式/s/p`，也就是打印所有匹配这个模式的行。grep 这个名字就由此而来。 ## [48:41] 他最怀念贝尔实验室的什么 · YouTube **Ryan Peterman：** 我们聊了很多贝尔实验室，你也提到它的黄金年代。回头看在那里工作的时光，你最怀念什么？ **Brian Kernighan：** 我怀念那里的人。虽然我现在还和不少人保持联系，但那真是一群很棒、很友善的人，聪明、好相处，点子也多。另一种可能无法原样重现的，是当时有各种新事情可做的环境。那是一个遍地“低垂果实”的时代。当然现在也可能有类似的机会，只是我不在那片果园里，也不够了解情况。也许如今某些 AI 领域就是道德意义上的同类机会。 贝尔实验室后来逐渐变成了一家更传统的公司。AT&T 陷入困难、反复拆分，业务也不断缩小，贝尔实验室这群研究各种领域、彼此紧密协作的人也缩小并变得分散，资金不再那么充裕，甚至不得不做一些不想做的事情，比如筹钱。这部分我一点也不怀念。 **Ryan Peterman：** 你以前教过一堂课，有段视频深埋在 YouTube 上，拍到你上课时修胡子。你还记得吗？为什么在课堂上整理胡子？ **Brian Kernighan：** 我记得。你可以问问当时在课上的 David。那是在哈佛，应该是 1996 年 9 月左右，是我第一次教 CS50 时的第一堂课。我以前从没教过这么大的班。那门课原本由计算机系的 Margot Seltzer 教，她当时休假，问我愿不愿意代课。我想，可能这辈子只有这一次机会在哈佛教书，何不试试？ Margot 有个开场节目，用来说明为什么很难把指令讲清楚，让计算机照着做。她会让学生指挥她做花生酱果酱三明治；要是指令不清楚，果酱可能抹在桌上，花生酱抹到头上。我不太吃这种三明治，就想有什么类似的例子。后来想到自己一把乱糟糟的胡子，于是带了一套修胡子的工具，从剪刀到电动绿篱机都有，让学生试着指挥我用这些工具修胡子。我不记得最后发生了什么；我想那台绿篱机确实插着电，所以得特别小心。 **Ryan Peterman：** 那是你第一次教大课？**Brian Kernighan：**对，457 人。**Ryan Peterman：**面对这么多人演讲会紧张吗？ **Brian Kernighan：** 我读研究生时确实很怵公开演讲。我刚到贝尔实验室不久，或许还是实习期间，记不清了，隔壁的 Vic Fatsky 跟我说：“我们有一群物理学家要学 Fortran，你愿意教他们吗？”我就去了。教学经验彻底帮我克服了对公开演讲的恐惧。在去哈佛之前，我在贝尔实验室也做过一些兼职教学。 ## [52:42] 他最怀念贝尔实验室的什么 · YouTube **Brian Kernighan：** 哈佛那次的班级规模远远超过我之前教过的任何班，至少大了一个数量级。但到了那个阶段，听众人数已经不是最重要的；演讲更像一场剧场表演。David M. 在这方面比我懂得多，他很擅长。 **Ryan Peterman：** 如果有学生害怕公开演讲，来向你请教，你会怎么建议？ **Brian Kernighan：** 我觉得就得去做。先进入一个必须和人交流的环境，开始时面对小群体，再慢慢面对更大的群体。没有比亲自上场、强迫自己走出去更好的办法。我现在已经不会担心这类事了。会议演讲也有点像，但教学更好，因为更亲近。即使有 400 多人，你也更容易判断自己讲得是否清楚、他们有没有听懂。可以把他们想成朋友，稍微虚化视线，这样看起来像是在直视大家，其实没有；或者找一个看起来有回应的听众盯着看。这些办法都有帮助。练久了就成了习惯，也就不担心了。 ## [54:10] 大语言模型会损害计算机科学教育吗 · YouTube **Ryan Peterman：** 你偶尔还在普林斯顿讲课。最近教育似乎正在因大语言模型和 AI 而变化，学生现在能前所未有地轻易获得答案。你觉得大语言模型对教育总体是负面还是正面？ **Brian Kernighan：** 现在还太早，无法判断。我能看到两方面都有不少影响。一个具体例子是，我听这里很多人提到，学生不来教师答疑时间了。他们大概从自己喜欢的大语言模型那里得到答案，所以不太来和教授、课程讲师或研究生助教交流。我觉得这总体是损失。面对面交流的信息量远高于和 Claude 之类的模型对话；人与人的接触也有很多好处。学生来和教师聊过，教师就认识他，之后可能会说：“你知道吗，这里有个机会”或“有人在找工作”。这种关系不是一笔一笔交易，而是有助于未来的人际联系。所以我很遗憾答疑时间减少了。 计算机科学专业的招生人数也在下降。专业学生少了，班级规模也就小了——虽然并非所有人都转走了，有些人只是去了别的系，但仍在选我们的课。班级小一点，师生接触更多，我觉得这是好事。 **Ryan Peterman：** 你觉得人数下降了多少？ **Brian Kernighan：** 我不知道。普林斯顿的变化可能更剧烈，但我不知道原因。2026 年春季毕业的那届，计算机科学专业学生略多于 200 人。两年后毕业的那届可能不到一半。**Ryan Peterman：**不到一半？**Brian Kernighan：**对。**Ryan Peterman：**哇。**Brian Kernighan：**甚至可能只有三分之一。由于学生选择专业的时间有先后，我们还不确定。如果以前有 200 人，我猜现在大概是 80 或 90 人左右——只是猜测。更多人去了电气与计算机工程、机械工程、航空航天工程；我认为这些领域更偏硬件，不太可能被大语言模型取代。（笑）所以学生正用脚投票。我完全能理解，不过他们可能反应过度了，我也不确定。只看大众媒体的话，好像我们已经不需要程序员了。我觉得这说法过于简单，但这不是我需要操心的事；我有工作，而学生担心毕业后该做什么，这完全合理。 **Ryan Peterman：** 普林斯顿学生总数大致固定？**Brian Kernighan：**完全固定。**Ryan Peterman：**但选择计算机科学的人比例不同了。**Brian Kernighan：**是的。我不知道近几年学生具体都去了哪些专业，但现在看起来主要是电气与计算机工程、机械和航空航天工程，可能是因为机器人方向。 ## [58:12] 大语言模型会损害计算机科学教育吗 · YouTube **Ryan Peterman：** 我看到你在电影《美丽心灵》里当过临时演员。那是部很棒的电影，采访前我还在里面仔细找你。你是怎么参与的？出演这么大制作是什么感觉？ **Brian Kernighan：** 那特别有意思。电影有不少场景要在普林斯顿拍，所以他们举行了演员招募。当时我和妻子刚搬到普林斯顿不久，具体年份记不清了，大概是 2001 年左右。许多人在一间大教室里参加招募，听他们介绍要拍什么。随后有个人走来指着我说：“你。”他没选我妻子，我觉得这简直不可思议。后来我接到邀请，要去拍诺贝尔奖颁奖典礼的场景。 你可以在影片里找到我。我告诉你怎么认：首先，所有人都没戴眼镜，因为镜片会反光；其次，我穿着黑领结礼服——我这辈子从没穿过这种衣服，因为那是诺贝尔奖颁奖典礼。拍摄地点是纽瓦克表演艺术中心，我以前从没去过。拍了大约 22 个小时。我们早上五点左右到，穿戴整齐，然后反复拍摄，中间有很多等待时间，工作人员会重新调整摄影机之类的。整个过程很有意思，而且我拿到了报酬。虽然不是工会标准工资，但确实拿到了一点钱。我去麦当劳翻汉堡都能赚得更多。（笑）电影后来上映了，效果还行。最棒的是，我的 Erdos-Bacon 数是 5。 **Ryan Peterman：** Erdos-Bacon 数。这个数字表示你和相关人物之间隔了多远？ **Brian Kernighan：** 对。我的 Erdos 数是 3，因为可以沿着几条路径，经过几个人、三步之内连到他。我的 Bacon 数是 2，因为我和某人一起出演过电影，而那个人又和 Kevin Bacon 一起演过电影。大致就是这个意思。之后我还见过 John Nash 好几次。 **Ryan Peterman：** 不是演员，是那位真实的 John Nash？**Brian Kernighan：**对，真正的 John Nash。他有点内向，不过人很好。让我紧张的一次是，我在数学系内部的一群人面前讲自己做过的某项研究，讲了大约十分钟，正讲得起劲。我不怕观众，讲得很开心。John Nash 走了进来，我立刻感觉全身绷紧。（笑）他后来问了个问题，我不记得问的是什么，不过我缓过来了。这是少数让我觉得公开演讲有点压力的时刻。 ## [1:01:46] Go 仓库里那条 1972 年的提交 · YouTube **Ryan Peterman：** 还有个有趣的事，我不知道是不是真的：Go 编程语言的 Git 仓库里，第一条提交据说来自你，时间是 1972 年。可是 Go 语言是 2008 年才开始的。 **Brian Kernighan：** 对，我完全不知道这是怎么回事。**Ryan Peterman：**你从没见过？**Brian Kernighan：**这是我第一次听说。 **Ryan Peterman：** 我查到 Go 仓库的第一条提交，据说里面是个 Hello World 示例。**Brian Kernighan：**哦，是 B 语言里的 Hello World 程序？**Ryan Peterman：**对，不知道为什么就是 B 语言。之后 1974 年有一次提交把它改成 C，再之后又有人把它改成 NC。所以也许 Robert 把你那份 Hello World 程序复制过去，用它开始了 Go 仓库。我那时肯定没用 Git；我想大约十年前才开始用。 **Ryan Peterman：** 那时用什么？当时已经有版本控制了吗？ **Brian Kernighan：** 版本控制大约在 70 年代中期出现。有个软件开发人员做的工具，我想叫 SCCS（源代码控制系统），在贝尔实验室内部广泛使用，外面可能也有人用。之后 Robert Tichy 做了 RCS，也就是修订控制系统，是类似的工具；再后来有 CVS，可能是 Concurrent Versions System（并发版本系统）之类的，然后还有其他工具，最后有 Git。版本控制是个很早的想法，但 1972 年还没有。那时 Unix 也不存在，所以那个 B 程序肯定是在别的系统上运行的。（笑） ## [1:03:43] Grace Emlen：那位虚构的贝尔实验室员工 · YouTube **Ryan Peterman：** 有意思，那大概会一直是个谜。也许我以后采访 Robert 时可以问问他。你的回忆录里感谢了 Grace Emlen。我又查了查，找到一份贝尔实验室校友去向名单，上面写 Grace Emlen 搬进了证人保护计划。这是怎么回事？ **Brian Kernighan：** 有一段时期，具体日期我忘了，贝尔实验室要求员工佩戴徽章，这样你在走廊里走动时，别人就能知道你是员工而不是游客。大家不太愿意戴徽章，于是出现了一场悄悄的反抗。其中一种做法是制作假的员工徽章。 Grace Emlen 是个虚构人物。我想大概是 Fred Gramp 创造的，取名和“Gremlin”（小精灵）有关，所以叫 Grace。我们一度还把她写进公司的各种正式记录里。这个小精灵身高大概这么高，戴着徽章坐在 Unix 机房里。其他人也有古怪徽章，我有一个印着米老鼠的。我可能还把它放在办公桌里，以前经常戴。反正没人会仔细看徽章，只会看到一团模糊的图案，知道你戴着徽章就行。我戴着它到处走，有次还戴着去见 Bill Gates，我想他也没注意到。（笑）大家就是不喜欢官僚作风，尽管要求戴徽章可能本身是合理的。 **Ryan Peterman：** 当时的徽章系统是数字化的吗？**Brian Kernighan：**不是，就是纸片。或者说是塑料卡片，前面可以塞一张自己做的纸。还有一件事：我在网上某个很老的代码仓库里发现了一个提交进去的密码文件。里面的内容是加密的，但使用的是旧的数据加密标准，可以用现代机器暴力破解。也就是说，你和所有同事的密码实际上……（笑） **Ryan Peterman：** 我看到你的密码了，我猜可以公开：就是斜杠、句号、逗号，斜杠、句号、逗号。**Brian Kernighan：**很容易快速敲出来。真有意思，我之前没见过。Eric Schmidt 曾发邮件给我们几个人：“嘿，你们看过这个吗？”（笑）看看密码挺有意思。我猜你说得对，可能是 DES，或者某种二战时期的机器，比如 Hagelin 密码机，它的原理被用在那个加密程序里。替我们说句话吧：那时的机器能力有限，而且大家会想“反正为什么需要密码呢”，所以没太把这件事放在心上。再说那个密码文件，我想是从伯克利来的一盘磁带。一定是有人把贝尔实验室研究版 Unix 的密码文件复制到了某个伯克利系统上，但我不知道它是怎么过去的。 ## [1:07:39] 他为什么写这么多书 · YouTube **Ryan Peterman：** 快到结尾了。你职业生涯里写了很多书，非常多产。《C 程序设计语言》只是其中一本。你为什么这么喜欢写书？ **Brian Kernighan：** 我觉得写书很有趣。这和你之前问的事情有关：试着把东西讲给非专家听。我觉得这种沟通很有回报，也很有价值。或许这是一种远距离影响他人的方式。教学有点像零售：你和一群人待在同一个房间里；写书则像批发：你不会见到大多数读者，但如果运气好，他们能从书里学到东西。 写书也能让自己学会那些知识。我想还有一点是，写过一本之后就会继续写。我记得很久以前和 Don Knuth 聊天，他说有人一本书都没写过，有人写过一本书，也有人写过很多本书。我大概属于第三类。 **Ryan Peterman：** 对我来说也挺有趣，所以我还在写。现在是你的商业宣传时间。**Brian Kernighan：**那你最近的新书是什么？ **Brian Kernighan：** 过去一年左右我写了一本计算领域重要思想的历史书，MIT Press 计划在一月出版。（笑）宣传结束。**Ryan Peterman：**那是回忆录吗？哦，还没出版。**Brian Kernighan：**对，还没出版。你摄像头下面有封面。**Ryan Peterman：**哦，《Shifts》。**Brian Kernighan：**没错。现在亚马逊上已经能找到，但要到一月左右才正式出版。 这本书讲的是计算领域发生过的一些重要变化。别的领域可能会把它叫作范式转移，类似 Thomas Kuhn 提出的概念，但也不完全一样。比如从模拟到数字就是巨大变化：你现在做的这些摄像头工作，用胶片根本做不到。还有存储程序计算机的概念：做一台通用设备，只要给它不同指令，就能完成各种任务，这很了不起。再有集成电路，从晶体管一路发展到今天的 IC。没有这些技术，你现在做的事情、我们所有的计算机都不可能实现。编程语言也在进步，让我们越来越容易告诉计算机该做什么。 最后一个巨大的范式变化与之前不同，因为我们正身处其中，而且它非常显眼：AI 和大语言模型发展飞快，影响到所有人，所有人都注意到了。我的妻子不是计算机领域的人，但她也想了解人工智能和大语言模型是什么、意味着什么、未来会怎样。我觉得这场变化极其难以预测，我们正处于其中，每个人都知道它的存在。好，我已经把书的概要讲给你听了，快去买吧。（笑） ## [1:11:40] 他为什么写这么多书 · YouTube **Ryan Peterman：** AI 现在能写代码，很多热爱计算、热爱敲代码的人，看到手写代码之类的事情变得过时，可能会觉得有点难过。你职业生涯里肯定也经历过一些东西被淘汰，比如打孔卡。那时你是什么感受？ **Brian Kernighan：** 我一点也不怀念打孔卡！（笑）我的博士论文就是用打孔卡完成的，一共装了三箱。我后来意识到，写论文时我得扛着大约 30 磅重的卡片到处走。所以有些东西我确实不怀念。 另一些东西你会怀念，那种智力挑战、解谜的乐趣，比如亲手写一段代码。我现在教一门 C 编程课，重新回到早期的感觉。我很久没怎么写 C 了，重新上手、重新思考和学习“指针到底是怎么回事”，还挺有趣的。我猜大多数人不会怀念内存管理，因为那很痛苦；但解决问题、让程序跑起来的挑战和乐趣仍然存在。 用 Python 写程序也有同样的乐趣和挑战。可是如果你提示 Claude 或其他模型替你生成，乐趣还在吗？我觉得不在。即使程序生成出来，你还得判断它能不能运行、是不是最有效地解决了问题、到底是不是你真正想要的，还是你应该提出不同需求。这些判断都建立在你知道自己在做什么的基础上。 我最近主要用 Claude，也用过其他工具生成 SQL，因为我不是 SQL 专家。我在高等研究院有位同事，她有数据库，但完全不是程序员，想有效地查询数据库。因此我需要把自然语言问题转成 SQL。比如我可以说“把所有符合某个条件的项目都给我”，让大语言模型写 SQL，再对数据库运行。但我怎么知道它给的是正确查询？我不是 SQL 专家；如果我们已经知道答案，也就不需要查询了。我还在琢磨这件事。我的观察是，九成情况下它能生成完全合适的查询，另外一成会给出彻底错误的答案，而我不知道哪次是哪一种。 **Ryan Peterman：** 听起来你需要领域知识，否则就无法判断结果。 **Brian Kernighan：** 大概需要的还是一直以来都需要的领域知识。你还得有办法验证自己的工作。没人能独自精通到足以测试大型程序，所以你可能又得用 AI 来生成测试；但随后还得判断测试是否写得恰当，于是就出现“检查检查者，再检查检查检查者”的无穷递归。（笑） 我说得可能过于简单了，我自己也不是高级用户。我认识很多人——就像你说的那位同事——几乎把过去做的所有事都外包给大语言模型。我不知道他们因此放弃了什么。一方面他们得到了很多，按代码实现功能的效率可能提高了十倍； ## [1:15:40] 他为什么写这么多书 · YouTube **Brian Kernighan：** 另一方面，他们可能有 10% 的脑细胞没有得到充分锻炼。我也不知道。现在还早，今天说的话，过一周或一个月可能就不对了。 至少在我们这里，学生担心的是毕业后会怎样：“我想当软件工程师，这份工作还存在吗？”答案可能是有，但和两三年前已经不同；等他们明年毕业时又会变。我们当教师的要怎样帮他们应对？应该教什么？怎样让他们养成合适的思维习惯，能在这个崭新的世界里发展？简短的回答是：我也不知道。 **Ryan Peterman：** 我觉得世界上恐怕没人知道。如果像你说的那样，模型现在还不完美，有很多细微之处会犯错；但假如它们完美了，几乎什么都能做，计算机科学专业的学生会怎么样？ **Brian Kernighan：** 你这个问题先假设了模型会变得完美，我怀疑它们不会完美，虽然它们可能比现在好得多。大概仍然需要有人判断它们是否足够可靠。人们使用模型的方式会改变，就像现在已经很少有人写汇编语言，我们信任编译器；事实上，如果用更高级的语言，也不会写太多 C。这可能是抽象层级的又一次提升，但仍然需要人来引导它，判断什么方向合理。 另一方面，有了这些工具，人们可以构建更有趣的东西。我有一位几年前毕业的学生，创办了一家很成功、也很有意思的公司，用 AI 和大语言模型做自然语言翻译，主要用于用户交互之类的场景。我觉得他的公司会非常成功，工作也很有趣。模型越进步，他就越能把正在做的事情做得更好，为客户提供更好的服务。我认为类似的情况还会不断出现。 **Ryan Peterman：** C 出现时，人们会不会哀悼汇编语言？ **Brian Kernighan：** 我觉得更早一些，大概是在 Fortran 出现时。看看 John Backus 和他在 IBM 的团队大约 1956、1957 年开发 Fortran 时说过的话。他很担心人们不会接受这个新工具，因为它生成的代码不如人手写的汇编高效。于是设计 Fortran 时，他有意不追求优雅之类的东西，而是把翻译效率放在优先位置。这确实是个真实的顾虑。后来某个时候，编译器开始找到人们自己没想到的优化，Backus 才觉得这东西也许能成功。 此后，我想确实有人会怀念编写汇编程序所需的技巧，但大多数人只想得到结果。 ## [1:19:40] 他为什么写这么多书 · YouTube **Brian Kernighan：** Fortran 在很多方面都比汇编语言好得多，也容易学。物理学家或化学家可以学会 Fortran，但不会去学某种机器的汇编语言，比如 IBM 7090 的汇编。而且程序一旦写好，就能移植到许多不同机器上。 ## [1:19:59] 他最喜欢和最不喜欢的编程语言 · YouTube **Ryan Peterman：** 纵观你的职业生涯，你接触和教授过许多编程语言。有没有哪种是你最喜欢或最不喜欢的？ **Brian Kernighan：** 如果说我日常会做什么，我写的程序通常不大，所以会用 awk。可能有点奇怪，不过我至少熟悉它。要是写大一点的程序，我几乎肯定会选 Python；很多用途下它是很好的折中，效率对我做的事情完全够用，表达能力也足够。 有时候我会回去用 C，比如要改某个旧程序，或者像现在这样教 C。所以我最终用的语言就这么几种，不多。有没有我不想用的语言？那我今天该得罪谁呢？（笑） 我过去上课时会用尽可能多的语言写同一个程序，已经很多年没这么做了。程序很简单：输入长度不一的文本行，再输出每行不超过大约 60 个字符的版本。这是浏览器自动重排文字的一种简化版。我用能找到的各种语言写过它，至少有二十多种，在课堂上拿来比较：哪些运行更快，哪些代码更短、更容易看懂？awk 相当快，而且代码总是最短，大约 15 行就能完成。C 总是最快，但更难写，因为要处理内存管理，字符串操作也笨拙。Perl、Python、PHP、YAML 等脚本语言表现各异，Perl 通常最快。一些号称更强大的语言反而更慢，Java 比脚本语言还慢，有点奇怪。C++ 没有我想象中那么快。最慢的一端是 Haskell：我花了好几周才写出 Haskell 版本，而从没用过的 Lua，我看了手册后半小时左右就写好了。后来一位 Haskell 专家看了我的程序，说应该导入一个专门处理字符的库，导入后运行就快了。 **Ryan Peterman：** 为什么写 Haskell 花了那么久？ **Brian Kernighan：** 它需要一种不同的思考方式，我就是没弄懂。我想问题部分在于：输入是一种形式，输出是另一种形式，输入行长度各异，而你要输出固定长度的行。这种输入和输出之间的节奏差异，按我理解，不太适合 Haskell。这不是在批评 Haskell；很多人喜欢它，只是我不是其中之一。 **Ryan Peterman：** 我在网上看到你近几年给 awk 仓库加了 Unicode 支持。这让我想知道，是什么让你一直想写代码？ **Brian Kernighan：** 因为好玩。这也是我们刚才谈到的智力挑战。特别是 awk，我希望它能处理 Unicode——准确说是 UTF-8，因为现在世界上大量文本都是 Unicode。它原来不能很好地处理这些内容，所以我做了修改。 ## [1:24:01] 他最喜欢和最不喜欢的编程语言 · YouTube **Brian Kernighan：** 我当时也有 CSV 格式的数据，awk 处理这类数据很笨拙，所以我加了一种机制，让它能正确处理 CSV。这些改动大概都源自几年前写《awk》第二版时的需要。到了今天，如果一个工具连 Unicode 都处理不了，那会很难堪。 ## [1:24:28] 给学生和年轻人的建议 · YouTube **Ryan Peterman：** 年轻人常常在寻找自己的热情，或想找到真正想投入的事情。你似乎很早就在编程里找到了兴趣，也天然享受编程本身。如果学生或年轻人问你：“我该做什么，才能找到自己真正热爱的事情？”你会怎么回答？ **Brian Kernighan：** 这是个好问题。我想你应该尽可能多尝试不同的事情，希望有一样能打动你。找到人生伴侣不也是这样吗？你不会一直坐在房间里想，而是去参加聚会，或者用 Tinder 之类的应用。我也不知道，总之要做些事，让自己进入可能发现想找之物的环境。这当然不是完美的方法，但如果你什么也不做、不尝试不同的事情，可能就不会偶然发现它。 很久以前，Dick Hamming 对我说过：Nancy Reagan 曾经说“只说不”（反毒宣传），而 Hamming 说“只说好”——当然不是说对毒品说好。（笑）他的意思是，如果有人带来一个机会，你觉得“我不确定，不过可以试试看”，只要保持常识，这种态度处理许多事情都很合理。很难知道什么适合谁，对一个人有效的办法不一定对另一个人有用。所以如果你从我这里听到职业或人生建议，还是要谨慎看待。 **Ryan Peterman：** 最后一个问题。经历了这么多，也回顾了你的职业生涯，如果能回到过去，把现在知道的事情告诉当时的自己，你会说什么？ **Brian Kernighan：** 看看我做过的事，我觉得自己像一颗掉进高尔顿板里的弹珠。你知道那种装置：顶端放下一颗弹珠，下面排着一堆钉子，弹珠碰到钉子后会向左或向右，最后从底部某处掉出来。重复很多次，弹珠会形成正态分布。我就像掉进高尔顿板的那颗球，最后从底下某个位置出来。但我每次碰到钉子会往哪边走，自己也不知道。很多事情都是偶然。 不过有个我觉得确实有用的观察——很多想法来自我和 Dick Hamming 的交流；但说出那句话的是 Louis Pasteur：“机会只偏爱有准备的头脑。”你思考过、好奇过、尝试过一些事情、认识过一些人，准备得越多，其中某件事就越可能把你带到正确方向。 **Ryan Peterman：** 也就是说，在那块板上，准备好的头脑会稍微影响结果，让它更可能朝好的方向走？**Brian Kernighan：**是的，我觉得如此。 **Ryan Peterman：** 好，我的问题就到这里。非常感谢你抽时间接受采访，真的很感谢。**Brian Kernighan：**不客气，也谢谢你们收看。 ## [1:27:43] 片尾 · YouTube **Ryan Peterman：** 不客气。也谢谢大家收看本期播客。如果你喜欢节目、希望节目继续成长，请留言或点赞。如果你希望我邀请哪些人来做嘉宾，也欢迎留言。Barbara Liskov、Mike Stonebraker、Mark Brooker 都是有人留言推荐后我才邀请来的。 另外，除了播客，我还在做一款我一直希望存在的人体工学键盘。先给你们看一眼原型：它是分体键盘，有左右两部分。现在这个还不是最终外壳。不过我们已经在 Kickstarter 上线，发布后八小时就达成了目标。如果你是早期支持者之一，我真的很感谢。现在我们开始了漫长的模具制作过程。如果你还想买，可以在 Kickstarter 上继续认捐；我会把链接放在简介里。 再次感谢你收看本期播客，我们下期再见。