如果你只打算精读一条编程演讲，它很可能是这一条——Dylan Beattie 的《The Art of Code》（代码的艺术）。这不是又一场“教你怎么用某框架”的技术布道，而是一场被无数程序员称为“看完重新爱上编程”的经典演讲：从"Rockstar 开发者"这个招聘黑话出发，他真的发明了一门用摇滚歌词写代码的编程语言；从 FizzBuzz 面试题出发，他把“代码到底写给谁看”这个老问题讲出了全新的纵深。在 AI 大量替人写代码的 2026 年，"代码首先是写给人看的沟通媒介”这个论点非但没有过时，反而成了每个工程师的必修课。本文带你逐段拆解这条视频的论证结构，补上它背后的理论源流，并指出哪些说法该信、哪些只是高级玩笑。
说明：本次撰写环境网络工具受限，未能实时核验最新播放量与发布日期等页面数据，下表中相关信息已按规则标注为“据频道页面/公开记录”，量级为撰写时公开数据的记忆值，请以视频页实时数据为准。
| 项目 | 内容 |
|---|---|
| 视频标题 | The Art of Code（代码的艺术） |
| 演讲者 | Dylan Beattie，英国软件工程师，曾任招聘/选角平台 Spotlight 的 CTO，Rockstar 语言作者，业余乐队 The Linebreakers 成员 |
| 发布频道 | NDC Conferences（YouTube 会议演讲频道） |
| 发布时间 | 2018 年前后由 NDC 频道上传（据频道页面，本次未实时核验具体日期） |
| 热度 | 百万级播放（量级约两三百万，据公开页面历史数据，本次未实时核验）；多年间在 Hacker News、Reddit 反复回热，属于“长青型爆款” |
| 选题理由 | 最近两年每逢“AI 写代码冲击程序员”的讨论周期，这条演讲都会被社区重新转发——它恰好回答了 AI 时代最要紧的问题：人类写代码的意义到底是什么 |
整场演讲大约一小时，但论证骨架非常清晰：先立论，再用三个“极端演示”不断把论点推向荒谬又收回本质。按叙事顺序可以拆成五个要点。
Beattie 的开场立论是：编程语言是人类历史上罕见的“同时说给两种读者听”的语言。第一个读者是机器——编译器只在乎语法正确与否，多一个分号都过不去；第二个读者是同事、是三个月后的自己、是接手你项目的陌生人。工业界投入了大量工程智慧伺候第一个读者（类型检查、静态分析、编译器警告），但伺候第二个读者的功夫，往往只停留在“心情好就写两行注释”。
这个立论并不新，但 Beattie 把它讲成了一个文化判断：代码不是数学证明，而是写作。一个函数写得好不好，评价标准不止“跑得对”，还有“读起来顺”。整场演讲的三个极端演示，都是为了把这个判断逼到极限。
演讲中他借用了业界著名的 FizzBuzz 梗：这道“3 的倍数喊 Fizz、5 的倍数喊 Buzz、共同倍数喊 FizzBuzz”的幼儿园级题目，被大面积用于程序员面试筛选，原因据说是大量“资深工程师”现场写不出来。Beattie 对这个现象的解读和主流不同：FizzBuzz 淘汰的往往不是不会算法的人，而是不会把一个简单想法翻译成清晰代码的人。这恰恰呼应了要点一——编程的核心能力是“把脑子里的意图变成人类和机器都能读的结构”，而不是背诵算法。
演讲的高潮之一是 Rockstar 语言的现场演示。起因是个语言学的恶作剧：招聘广告里满屏都是"looking for a rockstar developer / ninja coder"，Beattie 干脆反问——如果行业真的想要 rockstar programmer，那我可以真造一门语言，让代码字面意义上就是摇滚歌词。按 Rockstar 的规范（spec 1.0，2018 年发布）：
Tommy、Midnight；Tommy was a lovestruck ladykiller，而 Tommy 的值由右侧短语的词数决定（这句三个词，Tommy 即为 3）；Midnight takes your heart and your soul，表示 Midnight 函数接收 heart 和 soul 两个参数；Shout（带换行打印）和 Whisper（不带换行），自增自减写作 Build me up / Knock me down。于是 FizzBuzz 在 Rockstar 里读起来像一首叙事歌谣。官方仓库的示例程序就是 FizzBuzz 实现，这也是这场演讲最出圈的名场面之一。
第二个极端演示指向“深奥编程语言”（esoteric languages，简称 esolang）这个小众传统。Beattie 重点展示了 Piet：一门用抽象色块作图、用图像执行的语言，程序长出来就是一幅蒙德里安（Piet Mondrian）风格的画，所以这门语言以画家命名。执行时，一个“指针”在色块间移动，色块的色相变化编码指令、色块面积编码数值。他顺带扫过了这个谱系里的其他成员：只有 8 个符号的 brainfuck、程序在二维网格里四面乱窜的 Befunge、用莎翁戏剧对白写程序的 Shakespeare……这些语言没有生产价值，但它们把要点一的逻辑推到极限：当“可读性”的读者被彻底换掉（从工程师换成画家、诗人、乐迷），代码依然成立——这证明“代码是表达媒介”不是修辞，是事实。
收尾的压轴是 Quine：一段输出自身源代码的程序。它以哲学家蒯因（W. V. O. Quine）命名（其“间接自指”思想经侯世达《哥德尔、埃舍尔、巴赫》普及到计算机界）。Beattie 演示了 JavaScript 里如何用自指技巧写出一个合法 Quine，并展示了更疯狂的变体——多语言接力（quine relay，一种语言输出下一种语言的代码，直到最后一种语言还原出第一段代码）。他借此点题：能自我描述的程序，是“代码作为语言”最纯粹的证明。语言可以谈论语言，程序可以打印程序——这正是人类自然语言独有的递归性在代码中的镜像。
这场演讲看似插科打诨，其实每个段落背后都站着真实的学术与工程传统。逐条对齐如下。
1. FizzBuzz 的真实源流。 2007 年，开发者 Imran Ghory 在博客提出用 FizzBuzz 筛选候选人；同年 Jeff Atwood 在 Coding Horror 发表《Why Can't Programners... Program?》（准确标题为 Why Can't Programmers... Program?）将其发扬光大，引用数据显示当时大量计算机专业毕业生写不出这道题。这条脉络是有据可查的，Beattie 只是把它的解释重心从“能力恐慌”扭向“表达训练”。
2. 文学化编程（Literate Programming）。 “代码首先是写给人的”这个主张，正牌祖师爷是 Donald Knuth。他在 1984 年提出 Literate Programming，并开发了支撑 TeX 排版系统的 WEB 工具链，名言大意是：让我们改变对程序构造的传统态度——与其把主要任务想象成“命令计算机做什么”，不如把精力放在“向人类解释我们希望计算机做什么”。Beattie 的立论可以视为 Knuth 的通俗化重述。
3. “程序即理论”。 彼得·诺尔（Peter Naur）1985 年的论文 Programming as Theory Building 提出：程序真正要维护的不是代码文本，而是开发团队脑中关于“程序为什么这样设计”的理论。这解释了为什么 Rockstar 这种“把代码写得像歌”的实验并非纯粹搞笑——降低他人重建理论的成本，就是降低维护成本。
4. 命名之难与整洁代码运动。 “计算机科学只有两大难题：缓存失效和命名”这句名言常被归于 Phil Karlton（社区归因，原始出处存疑，引用时请注意）。Kent Beck 的那句“任何傻瓜都能写出计算机能懂的代码，好程序员写出人类能懂的代码”经 Martin Fowler《重构》（1999）流传。而 Beattie 的命名实验（用名词短语做变量）等于把“命名是设计”这个观点做成了行为艺术。
5. 深奥语言谱系是真实的计算机文化史。 brainfuck 由 Urban Müller 于 1993 年发布，目标是极小编译器（数百字节量级）；Befunge 由 Chris Pressey 于 1993 年创造；INTERCAL 是 1972 年普林斯顿学生 Don Woods 与 James Lyon 的恶搞之作，是该传统的开山；Shakespeare 语言出自 Karl Hasselström 与 Jon Åslund 2001 年的课程作业；Piet 由 David Morgan-Mar 设计。这些信息在 esolangs 社区维基均有据可查。
6. Quine 背后的硬核理论。 自我复制程序不仅是玩具：它有递归函数论的基础（克莱尼第二递归定理保证了自复制程序必然存在），更有安全领域的分水岭意义——Ken Thompson 在 1984 年图灵奖演讲《Reflections on Trusting Trust》中，用“短到塞进一页纸的 C 语言 Quine”作为论证台阶，演示了可以给编译器植入自我延续的后门。理解 Quine，是理解那次演讲的前提。
证据充分的部分。 “可读性影响维护成本、命名质量影响代码理解速度”有大量软件工程经验文献（《代码整洁之道》《重构》《软件设计哲学》）以及部分实证研究支持——例如 Bonita Sharif 等人用眼动追踪研究程序员阅读代码时对标识符命名的注视模式，总体方向支持“好命名降低认知负荷”。Beattie 的核心立论与这些证据一致，属于被广泛接受的专业共识。
属于玩笑或艺术实验的部分。 Rockstar 是讽刺作品，不是生产工具：词数决定数值这类规则对真实工程是灾难；Piet、Shakespeare 等深奥语言从设计目标上就放弃了实用性。演讲里的一些段子（如对招聘广告用词的挖苦）是喜剧素材，不应被当作行业统计数据。
存在争议的部分。 一是“注释该写多少”：Beattie 站在“代码是写作、注释是重要文体”一边，而《代码整洁之道》主张“注释是失败的补救”，John Ousterhout 在《A Philosophy of Software Design》（2018）里又针锋相对地主张应当慷慨写注释、注释是设计工具——这是软件工程界至今没有终审的真实分歧，演讲没有也不必给出裁决。二是 FizzBuzz 的解释：把它归因于“表达能力不足”是 Beattie 的个人诠释，原始讨论更倾向于“缺乏最基本的动手编码实践”，两者并不互斥，但也不等价。三是 Quine 演示中“程序自我打印”的哲学感慨属于借题发挥，严格的技术基础在递归定理，演讲省略了这层推导。
一点时代性的再评价（本文作者观点）。 2018 年看这条演讲，你会觉得“代码写给人看”是情怀；2026 年再看，它几乎成了生存技能——当 AI 能生成大段可用代码，工程师的核心工作正在向“读懂、审查、命名、组合”转移，人类侧的可读性成了新的性能瓶颈。这是这条老演讲近期在社区反复回热的真正原因。
1. 把命名当成一次微型 API 设计来对待。 下一次提交前做“朗读测试”：把变量名和函数名读出声，如果不像一句通顺的中文/英文句子（例如“订单，是否已支付”vs ordSt），就重命名。规则很简单——用业务词汇，禁用自造缩写，同概念全程同名。
2. 注释只写“为什么”，不写“是什么”。 无论你站 Clean Code 还是 Ousterhout 哪一队，有一条折中纪律是两边都认可的：代码本身负责说清“做了什么”，注释负责留下代码说不出的信息——为什么这么写、为什么不用更显然的方案、这里踩过什么坑。改行为时先问自己“注释要不要一起改”。
3. 每月做一次“表达体操”。 重做一次 FizzBuzz 级别的 kata，限定目标不是“做出来”而是“让一位不看代码的同事能听懂你的实现思路”；再挑战写一个 Quine——它对语言本体的理解要求之深，远超多数面试算法题。表达能力和肌肉一样，靠低强度高频次维持。
flowchart TD
A["开场之问：代码是写给谁的？"] --> B["核心论点：编程是一种沟通<br>代码同时服务两类读者"]
B --> C["读者一：机器<br>语法必须精确"]
B --> D["读者二：人类<br>命名 / 注释 / 结构"]
D --> E["FizzBuzz 重新解读<br>筛选的是表达力而非算法天赋"]
B --> F["极端演示①Rockstar<br>代码写成摇滚歌词<br>词数即数值，歌词即逻辑"]
B --> G["极端演示②Piet 等深奥语言<br>代码即抽象画<br>读者换成画家与诗人"]
B --> H["极端演示③Quine<br>程序打印自身源码<br>语言谈论语言"]
E --> I["收束：代码是人类文化的表达媒介"]
F --> I
G --> I
H --> I
I --> J["AI 时代的再延伸<br>人类侧可读性成为新的瓶颈"]
本文由「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 等场景全覆盖。