历史与人物buttondown.email
唐纳德·克努特被冤枉了
Donald Knuth was framed
2020 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Hillel Wayne 重新审视著名的 Bentley–Knuth–McIlroy 轶事：Knuth 应约用文学化编程写了一个单词频次统计程序，McIlroy 则用一段 Unix 管道命令作评论，后来这个故事常被简化为“Knuth 的完美程序被一行命令比下去了”。文章指出这种流行叙述忽略了原始语境：Knuth 是在演示编程纪律与可读性，而 McIlroy 的评论也带有推广 Unix 组合哲学的成分。
为什么经久不衰：它把一个被反复转述的编程轶事还原到原始语境，提醒我们警惕用阵营偏见和后见之明讲技术故事，今天仍值得读。
HN 评论精选
应读原始资料；McIlroy 的评论是在借机推广 Unix 组合哲学，而非单纯比较程序。
很高兴看到这篇文章：人们回到原始资料而不是二手叙述通常是好事，而且这个主题我感兴趣。文学评论中评论者借机推销自己的观点、而不只评论作品，是长期传统；这里也是如此。Knuth 写的是他被要求写的程序，用来展示编程纪律；但 McIlroy 作为 Unix 管道发明者和 Unix 哲学代表，除了好评之外，还要指出这类专用程序根本不该写，应先积累有用程序并用管道之类的方式组合它们。
svat查看英文原文
I'm glad to see this here, for two reasons: (1) In general it's nice when people return to the primary sources rather than second-hand accounts, and (2) this particular topic is of interest to me; here are a couple of previous comments that were somewhat well-received on HN: https://news.ycombinator.com/item?id=22221592 https://news.ycombinator.com/item?id=18699718 For further context you can look at past and future issues of Bentley's column (and its spinoff); a list of them I collected here: https://shreevatsa.net/post/programming-pearls/ I guess it's a long-standing tradition in literary reviews for reviewers to push their own ideas, rather than confining themselves solely to reviewing the work in question. That is what happened here. Knuth had written a program that he had been asked to write, to demonstrate the programming discipline. But McIlroy, as the inventor of Unix pipes and a representative of the Unix philosophy (at that time not well-known outside the few Unix strongholds: Bell Labs, Berkeley, etc), decided to point out (in addition to a good review of the program itself) the Unix idea that such special-purpose programs shouldn't be written in the first place; instead one must first accumulate a bunch of useful programs (such as those provided by Unix), with ways of composing them (such as Unix pipes). A while later, John Gilbert described this episode this way: > Architecture may be a better metaphor than writing for an endeavor that closely mixes art, science, craft, and engineering. “Put up a house on a creek near a waterfall,” we say, and look at what each artisan does: The artist, Frank Lloyd Wright (or Don Knuth), designs Fallingwater, a building beautiful within its setting, comfortable as a dwelling, audacious in technique, and masterful in execution. Doug McIlroy, consummate engineer, disdains to practice architecture at all on such a pedestrian task; he hauls in the pieces of a prefabricated house and has the roof up that afternoon. (After all, his firm makes the best prefabs in the business.) There are other points (not mentioned in this article), e.g. the fact that someone had to have written those Unix programs in the first place and writing them with literate programming can lead to better results, and the fact that Knuth's idea of using a trie (though not a packed/hash trie; that's no longer needed) still seems fastest: https://codegolf.stackexchange.com/questions/188133/bentleys-coding-challenge-k-most-frequent-words (please someone prove me wrong; I'd love to learn!) Knuth gladly included McIlroy's review verbatim when he reprinted this paper in his collection Literate Programming. BTW here's an 1989 interview of McIlroy https://www.princeton.edu/~hos/mike/transcripts/mcilroy.htm where he looks back and calls Knuth's WEB “a beautiful idea” and “Really elegant”, and his review “a little unfair”, though of course he reiterates his main point.
故事被简化为完美主义对实用主义，且叙述常偏向实用主义一方。
同一个故事有很多讲法。它引起共鸣，是因为符合一个持续存在的动态：程序员天然想造完美工具，而业务往往需要能由预制部件拼起来的快速粗糙方案。这个例子很极端：很难找到比 Knuth 更追求完美工具的程序员，也很难找到完美与够用差距如此戏剧性的著名问题。因此它成了这类冲突的典型故事，被自认站在快速粗糙/预制拼装一边的人反复讲述，并为了迎合偏见而倾斜叙述。
btilly查看英文原文
There are many, many ways to tell this story. However it resonates because it fits well with an ongoing dynamic. Which is that programmers naturally want to build perfect tools while the business need tends to be for a quick and dirty solution that can be assembled out of prebuilt pieces. Except that this one is extreme. It is hard to find any programmer who builds a more perfect tool than Knuth. There isn't a better known problem where the discrepancy between the perfect and the good is this dramatic. Therefore this became the poster child for this ongoing type of conflict retold by those who see themselves as on the side of the quick and dirty solution built out of preassembled pieces. Who, of course, slant the story to further fit their prejudices. This kind of slanting is common. Take a famous WW II example where they were looking to improve bomber durability by putting more armor plate where the bombers were coming back hit. A wise statistician advised them that those were the spots that didn't need armor, they should put it on where the bombers were hit and didn't come back. Which, assuming that bombers were hit evenly everywhere, was all the places that they didn't find holes. The reasoning is perfect, and illustrates a key point of statistical wisdom. But the retelling of the story almost never admits that the advice didn't really make a difference. The actual solution to the rate at which bombers were being destroyed was to drop chaff - strips of aluminum cut to half the length of the German radar - so that the radar systems got overwhelmed and the Germans couldn't find the bombers.
良好设计的价值主要在降低未来修改成本；若重写成本低，设计价值下降；可复用组件更有价值。
精心设计程序（有文档、模块化、可测试、无坏味道）的很多好处，与其说是让程序当前正确，不如说是让未来修改正确——无论修改者是别人，还是忘了怎么做的自己。但未来修改只有在你想以现有程序为起点时才重要。McIlroy 的管道不太易读，但我敢打赌，大多数有中等 shell 管道经验的人能从零重建等价物。一个推论是：如果你能在 30 分钟内从零写出完成任务的程序，考虑良好编程设计的理由就少得多；如果同样任务要一天，那么写文档和结构化代码的价值主要在于别人让你修改时只需 30 分钟。
geofft查看英文原文
Something related that's been on my mind recently: a lot of the advantage in building well-designed programs (documented, modular, built to be tested, free of smells, etc.) is less about getting the program right than about getting future changes right, either by someone else, or even yourself when you've forgotten how to do it. But future changes only matter if you want to use the existing program as a starting point. McIlroy's pipeline is a little bit hard to read, but I would bet that most people with moderate experience in building shell pipelines could rebuild something equivalent from scratch, even if they'd have trouble explaining how the current pipeline works. (Or people with experience in Python, Perl, etc. could throw together an equivalent script from scratch quickly.) An implication is that, if you're in a language where you can write a productive program to do a task from scratch within (say) 30 minutes, there's a lot less of a reason to think about good programming design than if you're in a language where doing that same task from scratch is likely to take you a day. In the second language, most of the value of writing documented and well-structured code is so that it takes you 30 minutes when someone asks you to modify it. But in the first language, you can throw away your code when you're done with it and still solve the modified problem within 30 minutes. Another possible implication: it's better to build reusable components (libraries and utilities) than easily-modifiable code. Part of why McIlroy's pipeline works so well is that tools like "tr" and "uniq" exist - and most of us will never have reason to modify the source code of those tools. We need to know what their interfaces are, but we don't need to know their internals.
该事件背后还有 trie、TeX 和 Programming Pearls 等更深的背景值得挖掘。
这条评论提到文章是在 HN 前一日讨论后发布的；评论者计划写一篇长文《Tries, Packed Tries, and the Bentley–Knuth–McIlroy story》：第一部分讲 trie 数据结构及如何表示子节点、打包数组等权衡；第二部分讲 Bentley–Knuth–McIlroy 事件的前因后果，包括 Bentley 的《Programming Pearls》、Knuth 写 TeX、可移植软件目标等。
svat查看英文原文
I guess this was posted after someone saw this come up on HN yesterday: https://news.ycombinator.com/item?id=31295427 I've been planning (for 2+ years now so it probably won't happen) writing a large blog post about this matter, which would be called “Tries, Packed Tries, and the Bentley–Knuth–McIlroy story”: • Part 1 would introduce the trie data structure both abstractly (the tree structure) and concretely (how exactly to represent the children of a node), with the trade-offs: as a linked list (space-efficient, slow lookup), as an array (fast lookup, takes space), or as some more nontrivial tree structure itself (“yo dawg…”). Then we'd discuss the really cool idea of “packing” the array, as nicely described in Frank Liang's thesis https://tug.org/docs/liang/ (also mentioned in TAOCP Exercise 6.3:4 and answer, which incidentally refers to the CACM Bentley–Knuth–McIlroy article that we're talking about). We'd also illustrate how hyphenation is done in the TeX program using packed tries (maybe this can be a separate post). • Part 2 would go into the Bentley–Knuth-McIlroy story: • Part 2a ("Before"): Bentley's thesis/book on writing efficient programs, and the Programming Pearls column. Knuth writing TeX first for himself in SAIL in 1977–78. The instant interest and ports/rewrites it led to. Knuth responding by rewriting TeX into its current form in 1980–82, and how the goals of portable software (thus Pascal, and its limitations! see BWK rant) and of eventually publishing it as a book led him to the idea of literate programming, which he still considers the most important outcome of his years into the TeX project. Meanwhile, at Bell Labs, McIlroy's invention of Unix pipes, and the instant excitement of "pipe day". (“It was absorbed instantly into one's outlook on programming. And by the end of the week secretaries were piping the output of NROFF into the printer”) The Unix philosophy, and how it took a while to spread. How these three threads came together in 1986, when Bentley read Knuth's TeX, wrote about LP in his Pearls column, and published one program of Knuth's (the random-numbers one) and asked him to write another (the frequent words one). • Part 2b (the program): How Knuth ingeniously combined the idea of packed tries with that of hashing with linear probing, to create the data structure especially for this problem (maybe we can call it a hash-packed trie?). Another look at his very nice idea/program, presented differently (maybe some illustrations of how the data structure works), and some design choices he made. • Part 2c (the review and later): How Bentley got McIlroy to review it, a close reading of the review: its actual content and points about LP and Knuth's style, and finally the (first sentence and) last part where McIlroy used the review to advertise his own Unix philosophy and the short shell pipeline version. The further reactions to this, including Bentley's remarks in the same column, and later articles and reactions like the "prefabs" comment (https://news.ycombinator.com/item?id=22406070). The short-lived LP column in CACM that it spawned (https://shreevatsa.net/post/programming-pearls/) and how it fizzled out, how it turns out everyone wants to do LP in their own system. How the story got bastardized over time (the misleading "More shell less egg" blog post for example, and some other examples of people misunderstanding the history entirely). • Part 3 would compare the two approaches (even though they are not meant to be compared!), mention how at https://codegolf.stackexchange.com/questions/188133/ I simply translated Knuth's program into C++ and beat the then-fastest Rust solution (since beaten again by translation from C++ back into Rust: still based on the trie idea though!), some words about cache misses and 32-bit “pointers” in a 64-bit world (and Knuth's rant about it). Something like that: it's probably too long for me to ever get around to writing it (or for anyone to be interested in…
历次讨论
同类还值得读
开发者无薪坚持完成 Mac 图形计算器：一个秘密项目的故事
Dev stays without pay to finish Mac Graphing Calculator as skunkworks project
苹果 Mac 图形计算器（Graphing Calculator）开发者的亲述：在项目被砍后，几位工程师在没有报酬、没有正式授权的情况下，以“地下项目”方式偷偷留在公司把软件做完…
历史与人物上首页 6 次 · 2009–2022pacifict.com理查德·费曼与 Connection Machine
Richard Feynman and the Connection Machine
长文回忆费曼晚年参与 Connection Machine 并行计算机项目的经历：他分析路由器、用自创的并行 Basic 编写 QCD 程序，也涉足细胞自动机等主题。
历史与人物上首页 5 次 · 2010–2021longnow.org编辑精选负 2000 行代码
-2000 Lines of Code
folklore.org 上 Andy Hertzfeld 记录的一则苹果 Macintosh 开发轶事：Bill Atkinson 被问到写了多少行代码时，回答“-2000 行…
历史与人物上首页 4 次 · 2014–2022folklore.org编辑精选Dennis Ritchie 的第一版 C 编译器（约 1972 年）
Dennis Ritchie’s first C compiler (c. 1972)
这个 GitHub 仓库保存了 Dennis Ritchie 约 1972 年编写的最早 C 编译器源码，是 C 语言和 Unix 早期历史的一手材料。
历史与人物上首页 4 次 · 2013–2025github.com一位破解赛马密码的赌徒
A Gambler Who Cracked the Horse-Racing Code (2018)
彭博社 2018 年的长篇特写，讲述数学家 Bill Benter 如何用统计模型和算法在赛马博彩中持续盈利、累计赢得近十亿美元的故事。
历史与人物上首页 4 次 · 2018–2024bloomberg.com