01#人物：Donald Knuth，程序是写给人类看的
编辑：不管写文章、写程序也好，表达总是来理清自己的。
简介
美国计算机科学家，算法分析之父
- 1938年：出生于于美国密尔沃基，父亲是德裔喜欢演奏风琴，在自家地下室经营一个小印刷厂；
- 1951年：参加 Ziegler's Giant Bar 比赛，谎称胃疼请假两周，拼出 4,500 个单词，远超裁判的 2,500 个；
- 1956年：高中毕业，同时在纠结读音乐还是物理，最终入读凯斯理工学院攻读物理；
- 1959年：创办并主编《Engineering and Science Review》获全国最佳技术杂志奖，转修数学；
- 1960年：进入加州理工学院读博，二年级为公司写编译器，赚得5,000美元；
- 1963年：获加州理工数学博士学位，并留校任教；
- 1966年：决定编纂一部七卷本系统地介绍计算机程序设计的巨著《计算机程序设计艺术》；
- 1968年：出版《计算机程序设计艺术》第一卷，拒绝美国国安局邀约；
- 1969年：正式加入斯坦福，专注算法分析，确立“算法分析之父”地位；
- 1974年：获得了图灵奖；
- 1977年：访问中国，姚期智的夫人储枫为他取了一个中文名字“高德纳”，同年开始开发 TeX 科技排版系统；
- 1990年：斯坦福授予“程序设计艺术教授” （Professor of The Art of Computer Programming）独特职称；
- 2025年：不使用电邮，专注深度思考，《计算机程序设计艺术》第 5 卷将于年内完成；
写给人类的程序
我是做什么的？
1967 年，Knuth 参加学术会议，有人问他是做什么的。
当时计算机科学还没有真正的自我认同。学科被粗略地划分为三个方向：做计算的、做智能的、做编程语言的。
Knuth 回答不出来。后来他决定，再有人问起时，他会说：我研究算法。
他甚至提出过一个更根本的建议：与其叫“计算机科学”，不如叫“算法学”（algorithmics）。
Knuth 认为人与人之间最好的沟通方式是通过故事。
在那个时代，大量计算机论文质量低劣，甚至本质上是错的。
Knuth 的直觉是：我们正身处一个全新的领域，但这个故事被讲得太糟了。
他想做的事很简单：把一个讲得很糟的故事讲清楚。
于是，他动笔编写《计算机程序设计艺术》，一套七卷本的系统巨著，用来讲清楚程序设计的本质。
向人类解释我们希望计算机做什么？
他在编写出版《计算机程序设计艺术》时，出版商放弃了旧的出版技术，转而支持照相排版。
他对照相排版法达到前几卷的质量感到非常沮丧，于是花时间研究了数字排版，亲手开发 TeX。
但更大的转变还在后面，在设计排版系统的过程中，他突然意识到：
我们写程序，是不是太关注“让机器能跑”，而忽略了“让人能懂”？
与其想象我们的主要任务是告诉计算机该做什么，不如让我们专注于向人类解释我们希望计算机做什么。
这个转念，改变了他的写作方式。他提出一个新概念：文学编程（Literate Programming）。
文学编程
写程序时，不妨问自己：如果这段代码是你未来十年后要阅读的，你现在会怎么写给自己看？
Knuth 认为，传统的编程方式过于关注“让计算机执行”，而忽视了“让人理解”。
这导致程序难以维护、难以合作、更难复用。
现在他想推动下一步进化，写“有文学性的程序”，即“Literate Programming”。
写给人看的代码，是另一种写作。
- 程序 = 文档 + 代码
- 写程序 = 写一篇程序说明文档 + 逐步插入代码块。
- 写程序的人像一个散文作家，要讲清楚“要做什么”和“为什么这么做”。
编写顺序是“心理顺序”
- 不是按照语言语法的顺序写，而是按照人类理解的顺序来写。
- 他强调写作顺序要符合人类的思维逻辑，不是语言的语法要求。
- 比如：先解释程序的大致计划、变量含义，再分段插入每一步实现的代码。
- 支持“上而下”（Top-Down）或“下而上”（Bottom-Up），甚至混合写法 —— 只要更容易讲清楚。
段落式结构：一个思想 + 一段解释 + 一段代码
- 每个程序“块”是一个小节（Section），都有标题、文字讲解、再加代码。
- 每段代码都围绕一个明确的“动机”或“概念”展开。
- 写模块时为每段代码写一句“为什么这段代码存在”，哪怕一句注释。
名字就是文档：用“可读的名称”组织程序
- 不像传统函数那样用 do_X()、main() 命名，他用人类语言命名代码段
- 这些名字也是结构标题，自动出现在目录和索引中
- 把函数/注释/文档块命名为有意义的短句
模块不是“先写好”，而是逐步展开
- 一个代码块可以在多个地方逐渐补全（+≡ 的语法），表达“我还会继续补充这部分”。
- 这样他可以写得更像一篇“讲解+实现”的过程文章，而不是必须自顶向下展开。
Knuth 所谓“文学编程”，不是搞浪漫，也不是故作风雅，而是回到一个基本问题：
你写下的东西，别人能不能理解？未来的你还能不能读懂？
这背后的信念是：程序不仅是一堆命令，更是一个人思考的痕迹。
写得清楚，才能看见自己的思路；
表达得明白，才更知道自己在干什么。
参考