正文
Bob 解答程序员的“35 岁危机”：
认为编程只适合年轻人的想法其实是个错觉，但确实是个很有影响力的错觉。这种错觉之所以存在，是因为过去 70 年里，对程序员的需求像坐火箭一样飙升。
其实我们这些“老程序员”都还在，只是数量上不那么显眼罢了。
出品 | 《新程序员》编辑部
想象一下，如果你这辈子写了五十多年代码，并且直到 71 岁还在编程，那你会如何看待现在这个 AI 编程爆火的时代？Robert C. Martin 被誉为世界著名编程大师，这位被全世界开发者称为“Bob 大叔”（Uncle Bob）的老头子是敏捷开发和设计模式的先驱，从 1970 年开始从事软件专业工作，从事相关工作超过 50 年。知名的“SOLID 五大原则”，即面向对象编程领域的五个设计原则，便出自他的手笔。Bob 大叔对 AI 的态度非常暧昧：从实用性的角度，他尖锐地吐槽“现在的 AI 就是只有半个大脑的初级程序员，而且永远不会真正成长”，因为 AI 能完成的任务相当有限；但即使年过耄耋，他对未来仍有着不小的期许：“等到我们在未来某个时候，创造出能像人类一样思考的机器，那时编程技能就会变得过时了。”作为全球闻名的软件开发大师，Bob 大叔的代表作《代码整洁之道》（Clean Code）曾定义了何谓“整洁代码”，讲述了一系列行之有效的操作实践。
最近，Bob 大叔的最新著作《函数式设计：原则、模式与实践》中文版出版，许多人不解于这位面向对象编程的领袖级人物为什么要“背叛”到“敌营”，而 Bob 大叔也是发挥一贯直来直往的性格，直接开“怼”：“近年来一些文章声称函数式编程与面向对象编程对立，面向对象编程已经过时。我不认同这种观点，因此决定写这本书。”
函数式编程不仅仅是“用函数编程”。函数式编程是没有赋值语句的编程。
一旦你尝试不用赋值语句编程，函数式编程的所有其他特性就水到渠成了。你要处理函数，就必须用递归，所有这些东西在你决定不用赋值的那一刻，就自然而然地形成了。所以说，函数式编程就是这么回事。
——《函数式设计》，Robert C. Martin
以上发言，皆出自 CSDN《新程序员》对 Bob 大叔的采访内容。我们和这位“敏捷开发的活化石”进行了一场深入交流，听他亲口讲述自己作为 17 位软件行业领军人物之一共同发表了 23 年前（2001 年）《敏捷宣言》的历史细节，还得知了这位有五十多年开发经历的资深程序员对 AI 编程的最新看法，刷新了许多人过往对 Bob 大叔的历史印象。下文将从 Bob 大叔对 1970 年的回忆开始，带读者们回到那个连万维网都仍未诞生的“程序员远古时期”。50+ 年的代码人生
《新程序员》：在采访开始之前，能否请您做一个简短的自我介绍？
Bob 大叔：好的，我叫 Bob Martin，有些人叫我 Bob 大叔（Uncle Bob），我做程序员已经有五十多年了。在我刚开始编程的那个年代，计算机的体积能塞下一个大房间，而且价格昂贵，高达数百万美元。
我使用过多种编程语言，包括汇编语言、COBOL、FORTRAN、PL/I、C、C++、Pascal、Java、C# 等。多年来，我参与开发了各种系统，从金融系统到嵌入式实时系统和过程控制系统。因此，可以说我在这个行业有着丰富的经验。
此外，我还撰写了几本书，包括《代码整洁之道》（Clean Code）、《架构整洁之道》（Clean Architecture），而今天我们讨论的这本书叫《函数式设计》（Functional Design）。
《新程序员》：除了写书之外，您在业余时间做些什么呢？顺便说一下，我经常看您的推特，发现您大约 50% 的推文是关于美国大选和特朗普的社会新闻，另外 50% 则是关于技术内容、编程以及您对代码的看法。
Bob 大叔：确实如此。在非大选年，我大约 90% 的推文是关于软件的。但由于今年是大选年，因此涉及其他话题的内容也比较多。当我不在写书或编程时，我会做很多事情。我喜欢骑自行车，经常骑车四处游览。我还是一名飞行员，经常驾驶自己的飞机四处遨游，这给我带来了很多乐趣。我有一个庞大的家庭，有四个孩子和十个孙辈，平时我会尽可能多地去看望他们，所以我的时间安排得非常充实。
《新程序员》：请把我们带回您编程生涯的起点，说一说您在 1970 年开始做程序员的故事。那时您 18 岁，学习的第一门语言是汇编和 COBOL，能否谈谈刚开始时的经历？
Bob 大叔：嗯，那时并没有很多大学课程。我当时对学校没有兴趣。那个年代，越南战争正激烈进行，校园里有很多骚乱和动荡。而且，我已经学到了很多计算机编程的知识，并学会了 COBOL 和 FORTRAN，甚至还会几种计算机的汇编语言。所以，我觉得完全没必要上大学。
至于编程生涯的起点，一切都始于我母亲在我 12 岁时买了一台小型塑料计算机。那个玩具有三个触发器和六个与门，需要通过转动一个小杠杆来操作它，内部的一些橡皮筋和杠杆会移动部件，让它进行简单的计算，比如从 0 计数到 7，或者从 7 计数回到 0。此外，还可以通过编程，让它对两个比特（bit）进行加法运算，生成一个和位和一个进位位，我甚至在上面编写了很多有趣的程序 —— 编程的过程是，通过将小管子插到插销上，这些管子会阻挡杆进入槽中，进而改变触发器的状态。
所以，我花了几个星期的时间学习如何让那台玩具计算机工作，通过这个过程，我成了一名程序员。从那以后，我一直都是程序员。
这是我的起点，之后，我父亲买了很多关于计算机和编程语言的书籍，尽可能多地为我提供信息。后来，在 16 岁时，我找到了一份编程工作，为 Honeywell 200 编写程序。这份工作持续了两三周，那时我还只是个少年，是在暑假期间做的，非常有趣。
大约两年后，在我 18 岁时，我找到了一份全职工作，主要为 IBM 360 编写汇编语言和 COBOL。不久之后，我开始用汇编语言为许多微型计算机编程。当时这些计算机是由 Varian 公司生产的，那时候许多公司都在制造微型计算机，但很少有公司成功，最后是数字设备公司（DEC）主导了这个领域。随后，我在编程 PDP 8 和 PDP 11 这些设备方面变得非常熟练，这些设备都是在 70 年代初期生产的。
《新程序员》：1970 年代真的是一个非常有意思的年代，那时万维网还没有发明，USENET 刚刚出现。您相当于世界上最早一批 USENET 用户，我还了解到“Bob 大叔”这个昵称最初是由一位同事在公司给您起的绰号。后来，您在 USENET 上误用了这个昵称作为签名，最终这个名字成功从绰号变成了真名。能否分享一下其中的故事？
Bob 大叔：我当时在一家名为“Clear Communication”的初创公司工作，这是我职业生涯的第四站，时间大约在 1987 至 1989 年间。在那里，有个同事给每个人起了个绰号，我的就是“Bob 大叔”。起初这让人有些不爽，因为他总是四处走动，不断用这个昵称呼唤我：“Bob 大叔，这个怎么弄？”“Bob 大叔，那个怎么办？”。
后来我离开了那家公司，成为了一名顾问，没有人再叫我“Bob 大叔”了。结果，我还挺想念这个称呼的，所以我犯了个错误，把它加到了电子邮件签名里。
当时我在 USENET 上非常活跃，经常在 comp.object 和 comp.lang.c++ 等新闻组上发文章，大家就开始注意到我的签名里的“Bob 大叔”。有一次我参加一个 C++ 会议，大概是 1990 年，有人从大厅对面指着我说：“看，那是 Bob 大叔！” 我当时心想，天啊，我犯了个错误，真应该把签名改了 —— 但后来我意识到，“Bob 大叔”其实会是个不错的品牌，于是就一直保留了它。
《新程序员》：USENET 可以算是您参与的第一个社交媒体。您和许多传奇开发者一样，很喜欢参与不同的社区或论坛，我曾在 Hash Note 上看到您发帖说：“我就是 Robert Martin，大家可以向我提问。” 当时许多开发者都积极向您提问并参与交流。现在，这种交流似乎变成了主要在推特上进行。
Bob 大叔：对，推特现在是我的主力社交媒体。另外我也使用 Facebook，但主要用于与家人和朋友保持联系。
《新程序员》：您最初被 C 和 C++ 所吸引，但也提到过自己出于兴趣尝试过 SNOBOL、FOCAL、ALCOM 和 BASIC 等语言。您认为还有哪些编程语言能被称之为“有趣”？特别是近年来出现的新编程语言中，有哪些会让您觉得是有趣的？
Bob 大叔：目前我觉得最有趣的语言是 Clojure，这是我投入了大量时间学习的语言。这让我有些惊讶，因为 Clojure 其实算是 Lisp 的一种方言，而我从未想过自己会去学习 Lisp。
在我的职业生涯的前三十年里，都从未考虑过学习 Lisp，因为我一度认为那是一种很糟糕的语言 —— 当然，那是因为我完全不了解它。直到有一天，我读了一本书，叫《计算机程序的结构与解释》，书中使用的语言是 Lisp，这立刻吸引了我。突然之间，我就成了 Lisp 的大粉丝。我想找到一种能在日常中使用 Lisp 的方式，于是我遇到了 Clojure。
Clojure 相当于一种可以运行在 JVM（Java虚拟机）上的 Lisp 方言，对我来说非常完美，所以我开始学习编写 Clojure 代码，并乐在其中，这对我来说是一种很好的消遣方式。
此外，还有其他有趣的语言，比如 Forth，这是一种基于后缀表达式的堆栈语言，与我用过的任何语言都不同，非常有趣。Prolog 也是一种非常有趣的语言，你不需要直接告诉机器什么是正确的，而是让机器通过求解来得出正确的结果。总的来说，这些都是非常有趣的语言，大家都应该去了解一下这些语言，因为它们非常独特。一旦你学会了一种非常不同的语言，它就会改变你对代码的整体看法。当机器像人一样思考，编程技巧将会过时
《新程序员》：我了解过您此前对 AI 代码的一些评论。在您看来，大语言模型有时还不错，有时也挺蠢的。虽然 AI 的代码解释帮了一些忙，但您仍然表态它不应该被盲目信任。
Bob 大叔：是的，程序员很容易过度依赖像 Copilot 这样的工具，看到它们生成的代码就不加批评地接受，这很危险。你需要保持批判性，虽然其中的部分代码还算可以，但大多数时候使用 AI 生成的代码需要非常谨慎。所以我的建议是，要小心，把它当作工具来使用，并且始终记住，如果使用不当，工具也会伤害你。
《新程序员》：那么，对于刚开始学习的程序员，他们应该如何利用 AI 成长呢？我曾经在采访中听到过两种截然不同的观点，一种是认为编程新手应该全面拥抱 AI；另一种是认为 AI 会毁掉初级程序员，因为这些人没有能力判断 AI 代码的好坏。
Bob 大叔：这就像初级飞行员不应该使用自动驾驶一样。请先学会如何驾驶飞机，然后再在不需要关注细节的时候使用自动驾驶。AI 也是一样的道理。初级程序员不应该一开始就依赖 AI，因为他们还不知道如何判断输出的代码质量。很多时候，那些代码不仅糟糕，而且就是错的，根本不能工作。
我真正担心的情况是，初级程序员接到一个任务，他们会选择用 AI 来实现。AI 给出代码猴，这些新手总是会想：“嗯，是 AI 给的，一定没问题”，然后丢掉工作。所以我的建议是，在职业生涯的前几年，甚至应该逐渐减少使用 AI。
《新程序员》：现在，越来越多的 AI 生成代码被用在不同的项目里。您是怎么在代码质量和生成效率之间平衡的呢？
Bob 大叔：我的平衡方式是先使用 AI 生成代码，然后再清理它。我可不会让它往项目里面塞糟糕的代码。所以呢，如果 AI 生成的代码能用，还能通过我的测试，那我就会毫不犹豫地回过头来重构、清理并改进它。比如改变命名，提取一些函数，调整结构，诸如此类。
因为我本来就不指望 AI 能生成很棒的代码。所以我会清理它，把它变成我自己的代码。这样一来，它就是我的项目了，是我写的代码。
《新程序员》：大约五年前，有人问过您“软件工程中哪些趋势被高估了？”，而您当时骂了一顿微服务（Microservices）。五年后的今天，有没有其他被高估的趋势？
Bob 大叔：现在被高估的趋势当然就是生成式 AI 了，毫无疑问。它是新生的事物，而任何新事物都会被高估。五年后，大家回头再看就会马后炮一句：“我们可能确实高估它了。” 这就是常态。
《新程序员》：您的老熟人 Kent Beck 在 AI 浪潮兴起的时候说过一句话。他说自己不情愿地使用了 ChatGPT，并发现自己 90% 的技能现在都不值钱了，而剩下 10% 的价值涨了一千倍。生成式 AI 到底有多大的帮助？
Bob 大叔：说实话，我没觉得 AI 特别有用。在最简单的情况下，它还算有点帮助。比如当我在做一些很基础的编码工作时，AI 会给出一些代码，我会瞄一眼，觉得还行，就接着往下做了。接着，AI 往往会跟着上下文内容继续工作，直到一旦事情变得有意思起来，AI 就越来越不靠谱了 —— 越是复杂的事情，它就越帮不上忙。
AI 可以处理一些小事，但如果我想让它重构和改进设计，就完全不行。此外，写测试的时候，AI 也帮不了多少忙。
《新程序员》：您之前说过，离编程学校变得过时还需要很长时间。会有一个具体的时间点来确定那个时刻吗？技术有终点吗？
Bob 大叔：这是个有意思的问题，但我会从科幻的角度思考它。等到我们在未来某个时候，创造出能像人类一样思考的机器，那时编程技能就会变得过时了。但说实话，那也是所有技能都变得过时的时候。所以我不确定那是不是值得期待的事。如果真的会发生的话，我觉得那是非常非常遥远的未来。要知道，人类大脑比整个互联网还要复杂得多。
《新程序员》：确实，这让我想到您还说过大家应该回归阿西莫夫（Asimov）的机器人三定律，即使这会创造一个“机器人奴隶”种族。您怎么从哲学角度理解通用人工智能（AGI）？
Bob 大叔：是的，虽然我觉得短期内不太可能实现，但我们确实已经有了基因技术。如果有朝一日，为了我们自己的生存，真的创造出了有意识的机器，我认为类似阿西莫夫三定律这样的东西就绝对有必要存在了。
《新程序员》：那在这一基础上，AI 应该被开源以避免这种事发生吗？人类是需要开放的 AI 还是封闭的 AI？
Bob 大叔：不同的公司肯定想保守自己的秘密，我觉得这本身没什么问题。AI 真正的问题是能源消耗。它耗能巨大，而且随着技术越来越复杂，还会继续增加。这就导致它的成本会相当高。所以我们得看看现今 AI 能发展到什么程度，看看这些大语言模型能做到多好。但是呢，它们会消耗大量的能源，就像核电站那样的能耗级别。
程序员的“工匠精神”
《新程序员》：让我们从 AI 抽身出来，聊点人与人之间的话题。
曾经有人问“您一生中的导师是谁？”，而您的回答是“书籍是我的导师”，您通过书籍认识了 Martin Fowler 和 Kent Beck 等杰出的人物，后面甚至还与这二人共事。那么，作为当年创立敏捷宣言的 17 人之一，能否透露你们彼此的关系是怎么样的？
Bob 大叔：过去我们经常有很多软件方面的会议，现在这种会议少了很多。我会参加各种类型的会议，比如 C 语言会议、设计模式会议，还有一些通用的软件开发会议。通过这些活动，我认识了很多人。
比如，我在一次设计模式会议上遇到了 Kent Beck，在一次早期的极限编程会议上遇到了 Martin Fowler。这些人我大都是面对面认识的，他们既是我的伙伴，也是我的导师，我从他们身上学到了很多东西。他们也都是我的同行，我们一起学习和进步。我学到的很多知识来自 20 世纪 60 年代和 70 年代的编程书籍，比如 Donald Knuth 的《计算机程序设计艺术》，那个时代的书籍对我来说是非常重要的信息来源。
所以，当我在职业生涯中工作了 30 年左右时，我开始参加各种会议，与人面对面交流，也是在这样的环境下，我们创立了敏捷会议。参加敏捷会议的大多数人我之前就认识，有过书信往来，或者在会议上见过面。
《新程序员》：我们经常可以看到一种观点，那就是“敏捷开发真的适用吗？”
以前有一段时期，许多开发者追求快速交付，忽视了软件的质量，这可能是一种对敏捷的误解。
Bob 大叔：这确实是一种对敏捷的误解。敏捷并不是为了加快速度，敏捷的核心是了解你所处的位置。你进行敏捷开发，是为了清楚地知道自己取得了多少进展，速度有多快，以及是否能按时完成任务。换句话说，敏捷是一种非常好的方法，可以帮助你了解自己到底处于多大的困境。它确保你不会在截止日期延误时感到惊讶，它让每个人都清楚地知道进度，因为我们可能并没有想象中那样快。
很多人误以为敏捷是一种快速的方法，有些人也将其作为一种快速的方法来推销，但这始终是一个误解。敏捷并不是让你更快的方式，而是让你知道自己速度有多快的方式。所以，敏捷并没有过时，它不是一种过时的技术。如果你想知道项目的实际进度和完成日期，敏捷会是一种非常好的方式。
《新程序员》：您在推特上有一句话令我印象十分深刻，即“敏捷运动最初是由开发者发起的，但项目经理在敏捷运动早期介入，反而破坏了原本的协作关系。” 能否讲一讲这其中的故事？
Bob 大叔：确实如此，敏捷运动起初是由一群程序员发起的。17 位参与者在雪鸟度假村聚会，共同创建了敏捷宣言。我们都是程序员，或者至少具有深厚的技术背景。这一运动并非从项目管理的角度起步，但其中一位创始人 Ken Schwaber，决定开设一门名为“认证 Scrum 大师（Scrum Master）”课程。该课程旨在培训希望成为 Scrum 大师的人员，教导他们如何协助团队运用 Scrum 方法 —— 这是敏捷开发的一种模式。
项目经理们对此表现出浓厚兴趣，纷纷报名参加此类课程。由于大多数参加者为项目经理而非程序员，这导致了原本由开发者发起的运动逐渐转变为以项目经理为主导的运动。程序员们对此感到不满，因为他们认为这原先是自己的创举，却被排除在外。
为解决这个问题，我们中的一部分人发起了软件匠艺运动（Software Craftsmanship），并发布了匠艺宣言，试图重新连接项目经理与开发者之间的联系。然而，这并未取得显著成效。
最终，我们分离出了一个以项目管理为中心的“官方敏捷运动”，以及一个由开发者主导的实际敏捷运动。后者依然致力于通过简洁有序的方式来工作，明确自己的位置和发展方向。
《新程序员》：所以，Scrum 大师的角色意义何在？这一角色的重要性体现在哪些方面？我们又该如何培养出一名优秀的 Scrum 大师？
Bob 大叔：Scrum 大师最初的设计理念是团队中的一员，负责提醒其他成员遵守使用 Scrum 或敏捷方法时所作出的承诺。其职责包括每周检查团队进度，例如确认是否已按计划编写测试代码，以及是否遵循了预定的估算方法。这一角色在团队内部实行轮换制，通常由不同的成员轮流承担。在成熟团队中，经过数周的实践后，无需专门的 Scrum 大师来监督，因为团队成员已经能够自觉地执行既定流程。然而，随着项目经理的介入，这一角色逐渐演变为一种项目管理职能，而这与 Scrum 大师的初衷相去甚远。因此，现今 Scrum 大师的角色已经发生了显著变化。
《新程序员》：您刚刚提到了软件匠艺的故事，这让我想到了您在推特上的签名也写着“匠艺”（Craftsmanship），这是个相当有年代的词，放在今天应该翻译为“工匠精神”。
这个词究竟应该如何理解？在当前快速发展的行业中，真的没有时间去关注质量吗？随着 AI 的进步，软件交付似乎会变得更快。我觉得 AI 会起到帮助作用，这样说对吗？
Bob 大叔：这些大语言模型确实是非常有趣的工具，我认为它们会对程序员有所帮助。但它们不会取代程序员，也不会完成所有的编码工作。它们并不擅长写代码，但它们可以提出一些很有趣的建议。所以我认为它们会有用，但还不足以让我们不再需要程序员。
至于匠艺，它是一种态度，一种对待工作的态度。最好的解释方式是这样的：当你结束一天的工作回到家，看着镜子时，你能够对自己说：“今天我做得很好，我为自己的工作感到自豪。” 这就是工匠的行为方式。工匠对自己工作质量感到满意，他们勤勉而自律，做出高质量的工作，这正是软件匠艺的核心。
当然，我们可以讨论很多技术和方法，比如测试驱动开发（TDD）、简单设计、SOLID 原则等等，有很多技术和理念。但最根本的理念是，每天结束工作时，你能够对自己说：“我今天做得很好。” 然而，不幸的是，很多程序员回家时，看着镜子，会觉得自己需要洗个澡，因为他们觉得今天做得很糟糕。他们写了一堆糟糕的代码，只是为了赶上截止日期，他们需要把这些不好的感觉洗掉。这就是匠艺的意义 —— 回到家时，知道自己做了好工作，为自己的工作感到自豪。
《新程序员》：您的著作《代码整洁之道》（Clean Code）中也体现了匠艺的道理所在。所谓代码整洁之“道”，是更关注于业务逻辑的实现，而非系统编程吗？还是说两者并没有区别？
Bob 大叔：代码整洁是一套理念和技术，这些理念和技术能够帮助你像个工匠一样工作，让你回家时为自己的工作感到自豪。无论你是在实现业务逻辑，还是在进行系统编程，这都无所谓。它只是一套帮助你做好工作、让你感到满意的技术和理念。
《新程序员》：我之前发现，不管是中国还是美国的开发者社区，都有很多人认为代码整洁意味着大量的抽象。那我们如何避免写出过度设计和过度抽象的代码？
Bob 大叔：是的，这是一个非常奇怪的现象，因为我的书本身并没有建议过度抽象，也没有提倡大量的抽象。书中建议的是，谨慎且恰当地使用抽象，但并不推荐过度设计。显然，有一些程序员认为，任何形式的间接都是不好的，他们认为写出好代码的唯一方法是尽量直接。我不赞同这种观点，我认为适度的间接设计和抽象是有帮助的，但你必须非常小心，因为抽象是有代价的。所以，当抽象有助于解决问题时你可以使用它，但要清楚它的成本，并且谨慎地使用。
《新程序员》：想必这就是您前段时间说要推出新版的《代码整洁之道》的原因，我是否可以理解为正本清源呢？不过，既然您决定彻底重新设计并完全重写这本书，为什么不换一个新名字？
Bob 大叔：书名是由出版社决定的，我主要是想重申《代码整洁之道》的核心理念，但采用了不同的表达方式，从不同的角度来阐述主题。
原来的那本书，是在 16、17 年前为当时的读者群体所写。而现在我写的这本书则是为了今天的读者。它会尝试解决更多现在常见的问题。我会使用不同的语言，并采用不同的方法，减少指令性的内容，增加信息量，试图用不同的方式来传达相同的观点。信息是一样的，只是表述不同。我认为这两本书最终会是互补的，读者应该把它们都读一遍。
AI 就是只有半个大脑的初级程序员
而且永远不会真正成长
《新程序员》：接下来聊一聊您的新书《函数式设计》。首先，为什么您想要写这本书？
Bob 大叔：函数式编程在过去十年中日益重要。尽管人们约在 2005 年开始关注函数式编程，但实际上这是一个更古老的概念，自 1936 年就作为数学语言存在，且最早的编程语言之一就是函数式的。
早期，执行函数式语言的成本较高，运行速度慢，需要大量内存。但现在，计算能力和内存资源的进步使得函数式编程的成本几乎可以忽略不计。这带来了函数式编程的优势，尤其是在多线程编程方面。函数式编程允许编写多线程代码而无需担心竞态条件或并发更新问题，这是因为函数式编程没有赋值语句，不改变变量状态。
我在学习 Clojure 时，发现这是一种有趣的编码和解决问题的方式。我认为应该将它与面向对象编程和结构化编程等其他工具结合起来。然而，近年来一些文章声称函数式编程与面向对象编程对立，面向对象编程已经过时。我不认同这种观点，因此决定写这本书。
这本书讨论了函数式编程、面向对象编程和结构化编程如何协同工作，以构建更好的系统。它从基本概念开始，逐步建立起设计原则和模式，最后组合成一个完整的小型应用程序。我希望读者理解函数式编程不是孤立存在的，它可以与我们过去 50 年学到的所有知识协同工作。
《新程序员》：我从 CSDN 的开发者社区也收集了不少关于新书的问题，而大多数人最好奇的是，为什么您选择了 Clojure 而不是 Scala 来编写书中的代码？是因为您想使用一种更函数化的语言，这种语言不支持类和继承，以此来证明您的 SOLID 原则在函数式设计中同样适用吗？
Bob 大叔：部分原因确实如此。Clojure 虽不是“纯粹”的函数式语言，但非常有利于编写函数式程序。但是，我选择 Clojure 还有一个也许更重要的原因，那就是 Clojure 非常简单。
我想在这本书中传达的是函数式编程的思想，而不是教授一种复杂的函数式编程语言。我特别不想教一种语法复杂的语言。Clojure 的语法非常简单，几乎没有复杂的语法。学习 Clojure 很容易，你可以通过阅读 Clojure 代码来掌握它。
所以当我在书中展示代码时，不会详细讲解 Clojure 的工作原理，而是解释一些基本概念，剩下的大部分内容让读者自己搞清楚。我也推荐了一些其他的文档供有兴趣的读者参考。但总的来说，Clojure 非常容易理解，这样对于那些对 Clojure 或函数式编程不太了解的读者来说，可以更专注于函数式编程的理念，而不被语言本身所困扰。
《新程序员》：我记得您在推特上曾说过，如果有人希望在您的下一本书中被提到，可以向您提交一段自认为最整洁的代码。这种情况经常发生吗？通常有多少人会提交代码？中国的开发者也可以提交吗？
Bob 大叔：是的，我确实发布过那条推文，并收到了不少回复。一些人通过GitHub链接或直接发送代码片段。我很可能会在即将出版的书中使用其中的一些代码。如果中国的开发者想提交他们认为非常整洁的代码，我也很乐意考虑。但我不能承诺使用所有人的代码，因为一本书的篇幅有限，不能把大家的代码都放进去。
《新程序员》：您对数字教材和在线学习平台有什么创新想法吗？现在人们似乎不太愿意读纸质书了。这些新形式会如何革新编程教学和学习方式？您计划如何向下一代教授编程？
Bob 大叔：的确，我们现在处于数字时代，注意力跨度已缩短到 20 分钟以内。但如果真想学到东西，就需要放慢速度，专心学习。我最近的几本书都配有视频内容，读者可以通过书中的 URL 观看编程会话的现场演示。这种结合文字和视频的方式非常有效。
此外，还有一种很有趣的方式是在线讲座。例如，在阅读印刷材料后，书中会提示访问特定 URL 观看相关讲座。我认为这些方法都非常有用。
我不认为纸质书籍的时代已经结束。它们可能会转化为电子书、PDF 或在线阅读器版本，但文字书籍不会消失。文字是一种信息密度非常高的媒介，比视频或讲座更密集，也更方便控制学习进度。因此，我认为结合多样化的学习形式可能更为有效，需要同时使用文字和视频。
《新程序员》：您的著作面向不同专业水平的读者，从初学者到经验丰富的专业人士。这在内容的深度和广度之间取得平衡时，肯定带来了不同的挑战。
Bob 大叔：我的书确实面向不同的人群，既有新手，也有专业程序员。关键是让两类读者都能获得价值，既不会让一方觉得太难消化，也不会对另一方过于简化。
在教学和写作时，我假设我的听众或读者和我一样聪明，能够理解我的内容。可能需要他们稍微努力一下，但我相信他们能够理解。我不会根据我对读者能力的判断来调整内容。我只是直接传达我的信息，就像对一个同行说话一样。
也许我经验多一些，也许我经历的更多，犯过更多错误。所以我可以分享我的经历和故事。但我不会因此放慢节奏或过分简化。
《新程序员》：这些年来，您在教授编程的方式上有哪些变化？为了跟上不断发展的技术环境，您采用了哪些新的方法和课程？
Bob 大叔：在早期，我通常会使用透明胶片，并通过投影仪来展示课程内容，通常是准备一大叠胶片，一页一页地把内容展示出来。随着时间的推移，现在我用的是 iPad 来做演示，把它连接到投影仪上，然后用 Apple Pencil 在 iPad 屏幕上画图，所有内容都会实时显示在大屏幕上，这非常有趣。
新冠疫情期间，我们开始通过 Zoom 等远程培训工具进行授课。现在，我的大部分教学都是通过远程方式完成的。我仍然使用幻灯片演示和屏幕绘图，这些方法依然有效。唯一的区别是，在远程教学中，我无法直接看到观众的反应，这种体验少了一半的乐趣。
《新程序员》：疫情之后还带来一个变化，就是许多程序员担心自己被 AI 取代。我之前看到一种说法，即学习函数式设计可以帮助他们保住工作，能请您详细说明一下吗？
Bob 大叔：函数式设计以及函数式设计书中的理念，其实就是为了帮你成为更成熟的程序员，给你的“工具箱”添加新工具。函数式编程是个好工具，面向对象编程是个好工具，结构化编程也是个好工具，这些都该放在你的工具箱里。测试驱动开发是个好工具，最好也备着。SOLID 原则也不错，放在工具箱里准没错。所以这本书的目的就是扩展开发者的工具箱，这肯定能帮你保住工作。但我觉得不用太担心被 AI 取代，这在我有生之年不太可能发生，可能在你这辈子也不会，或者永远不会。我感觉我们不会看到能达到人类智能水平的机器。
《新程序员》：关于函数式设计和面向对象编程，我相信很多人一定问过您哪个更好。但我想问的是，您认为当前的 AI 更擅长哪一个？例如，函数式编程是否更适合 AI 代码生成？它没有状态，一个函数可以在使用时生成，每个函数也可以由 AI 自动生成和验证测试。那么，如果 AI 更擅长函数式设计，对于只懂函数式编程的程序员来说，是不是面临更大的危机？
Bob 大叔：没关系，因为 AI 哪个都不会，它在生成函数式代码方面也并不比生成面向对象代码或结构化代码更好。你可以把 AI 想象成一个只有半个大脑的初级程序员，而且永远不会真正成长。它会给你一些建议，其中大部分是不太行的，少部分可能还行，但是得改改，因为 AI 写的代码总是很乱。
AI 就是这样，它可能有帮助，但你不应该为了适应 AI 而调整你的职业方向。AI 是一种工具，你可以学会如何使用它，但不应该为了某个 AI 工具而改变你的职业规划。
如果面对 AI 编程时不知道该怎么办
那就把它关了
《新程序员》：如果有一个新人跑过来问您，“我应该选择哪门语言作为第一门编程语言？” 您通常会怎么回复？
Bob 大叔：嗯，你可以选 Java。说回来，C# 也是非常好的语言。Clojure 也不错。C 语言也可以。C++ 有点难，有点复杂，但也可以选。Go 语言也很好，这是个好语言……
其实，选哪个并不那么重要。编程就是编程，从哪种语言开始并不关键。最重要的是，你得去学习下一种语言。不要停留在一种语言上。学一种，花几个月时间直到有点熟练了，再去学另一种，如此循环之后，每年学习一种新语言。把学习语言就当做一种乐趣，找一种还没学过的语言来学。你可能永远不会在工作中用到它，可能再也不会用它，但请保持每年或每两年学习一种新语言的习惯。从哪里开始并不重要，重要的是你要不断学习。
《新程序员》：您会推荐初级程序员参加开源项目吗？您自己参与过什么令人印象深刻的开源项目，能否分享其中的故事？
Bob 大叔：我和我儿子 20 年前开始了一个项目，它现在还在进行，这是一个很棒的项目。虽然我现在不再参与了，但还有很多人在继续。
如果你是一个初级程序员或年轻的程序员，想学习一些新想法，我建议你加入一个开源项目。尝试提交一些拉取请求，贡献你能做的部分。这首先是一个很好的帮助他人的方式，其次也是一个绝佳的学习机会。总之，你说的没错，我强烈建议人们参与开源项目，这是扩展职业生涯的好方法。
《新程序员》：您知道“35 岁危机”吗？许多程序员一到特定年龄就面临着两条路：要么转管理，要么退休。
Bob 大叔：考虑到科技行业对年轻人的偏好，这确实是个问题。实际上，有个开发者问过我类似的问题，我记得很清楚。他的原话是：“Bob 大叔，你都 70 岁了怎么还在编程？” 他说的没错，我现在都 71 岁了，还在写代码呢。
这种认为编程只适合年轻人的想法其实是个错觉，但确实是个很有影响力的错觉。这种错觉之所以存在，是因为过去 70 年里，对程序员的需求像坐火箭一样飙升。
我们可以这么想：每五年，全球程序员的数量就翻一番。这意味着我们每五年就得让程序员数量翻倍，也就是说，世界上有一半的程序员经验不到五年，四分之三的程序员经验不到十年。换句话说，世界上四分之三的程序员年龄都不到 35 岁。所以当你四处看看，看到的都是年轻人。你可能会问，那些老程序员都哪去了？其实我们都还在，只是数量上不那么显眼罢了。
这就造成了一种错觉，好像编程只适合年轻人，但这其实大错特错。要成为一个真正厉害的程序员，需要很长时间的积累。可能有些资深程序员，觉得自己有十年经验很了不起，那确实不错，但是再过 5 年，他还能成为更优秀的程序员。
所以，如果你真心喜欢写代码，觉得这是你的最爱，想一直干下去，那就别放弃。你不是非得去当管理不可，有人擅长管理就让他们去管好了。如果你想继续写代码，那就坚持下去。你既不用转行，也不用提前退休。又不是说你到了 36 岁脑子就不好使了。确实，现在有太多新人不断涌入这个行业，而且不光是年轻人，各个年龄段的人都在学编程。这并不意味着你就没有机会了。
《新程序员》：这让我想到，现在很多程序员面对 AI 时都有自我怀疑的感觉。但事实上自我怀疑不是什么新鲜事，很多老程序员在以前的时代也会有同样的问题。您以前有过自我怀疑的感觉吗？
Bob 大叔：我刚开始编程的时候，还是个毛头小子，总觉得自己能闯出一片天地。这时的我从未有过自我怀疑。
反倒是后来，我开始犯错误，甚至被炒了鱿鱼，还经历了一些其他挫折。这时候的自我怀疑反而是件好事。适度的自我怀疑其实挺健康的。因为过了一段时间，你就会学会应对。你会去想：“好吧，我知道怎么避免这些错误了。我知道我不是完美的，但只要我专注、小心，多和别人交流，我应该能搞定这些问题。” 慢慢地，你就会克服那些自我怀疑。其实，经历一段自我怀疑的时期不一定是坏事。它能让你成长，让你变得更强大。
《新程序员》：最后，能不能给现在的开发者一些建议？特别是那些感到迷茫的程序员，或者面对 AI 编程时不知所措的人。
Bob 大叔：如果你面对 AI 编程时不知道该怎么办，那就把 AI 关了。别理它。再花一个月时间自己写代码，然后再打开 AI。也许到时候它看看你的代码，看看你想干啥，就能给出更好的建议了。
比方说，想象一下你是个正在学开车的菜鸟。你从来没碰过方向盘，一上来就想用自动驾驶。一按自动驾驶，车子就开始动了，你可能会吓得不行，心想：“我得先关了这玩意儿。等我有点经验再说。” 直到你学会了开车，再试试自动驾驶，就会想：“哦，我现在懂这东西是怎么工作的了。” 然后你就能更好地利用它了。AI 也是如此，刚开始可能还不太顺，但慢慢来，你会越来越熟练的。
