正文
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 虽不是“
纯粹
