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