编程与软件工程leancrew.com
Knuth 与 Unix 之道
Knuth and the Unix Way
2011 — 2017，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章回顾了编程史上一段著名公案：Knuth 应邀用“文学编程”风格写了一个词频统计程序，而 Unix 管道的发明者 McIlroy 随后用六行 shell 管道实现了同样的功能，以此展示 Unix 工具组合哲学的威力。文章围绕这场“少写 shell、少写蛋”的对比展开讨论。
为什么经久不衰：它触及软件工程中一个永恒的争论——可复用组件与为特定问题精心编写的代码孰优孰劣，几十年后依然没有定论，值得每个开发者思考。
HN 评论精选
组件化拼接的愿景屡战屡败，反倒是 Knuth 式针对问题写代码的方式更经得起考验。
McIlroy 的基本观点是：与其写一次性程序，不如把精力放在构建可复用组件（即 Unix 工具）上，久而久之大多数程序都可以由高层组件简单拼接而成。这个愿景五十年了基本没实现，却依然流行。后来人们又寄希望于用对象拼接来构建大型应用，同样没有明显成功；中间还有 COM、CORBA、WS-* 等各种“组件化”方案，几乎都是彻底失败。所以在我看来，最后笑的是 Knuth。
jhpriestley查看英文原文
McIlroy's basic point is that, instead of building single-use programs, we should be directing our effort towards building reusable components, i.e. Unix utilities. Then, over time, most programs could be built as a simple piping together of high-level components. This vision seems to have failed for about 5 decades now, but it is still a popular one. After no one was able to build serious applications by gluing together Unix utilities, it was thought that we would instead build serious applications by gluing together objects. This vision has also failed (or at least, not succeeded in a very apparent way). In the mean time there have been other promised types of "componentry", like COM, CORBA, WS-*, ..., all more or less complete failures (or at least, egregiously unapparent successes). So, in my view, it is Knuth who has the last laugh.
McIlroy 的比较不公平：Knuth 是被指定用文学编程风格写题，而且适合 shell 拼接的简单问题本就罕见。
这是 McIlroy 的廉价一击。Knuth 本来就是被要求用文学编程风格来写的。词频统计是那种简单、领域无关、天然适合代码复用的问题，但这类问题很罕见。专业开发者面对的大多数任务，不可能靠一个小 shell 脚本解决——顶多是一个庞大而难以维护的脚本。
bluesnowmonkey查看英文原文
A cheap shot by McIlroy. Knuth was specifically asked to write in the literate style. Word counting is one of those simple, domain-independent problems that lend themselves well to code reuse. It's a rare type of problem. Most tasks presented to a professional software developer could not be solved by a small shell script. A large and unmaintainable one, maybe.
Knuth 惯常处理的是大型或性能敏感的问题，McIlroy 的管道方案在扩展性上反而更差。
公平地说，这不是 Knuth 通常做的那类小工具程序。从 TeX、Metafont 和 TAOCP 来看，他做的通常是非常大的问题，或者是对周期数极其敏感的底层东西。McIlroy 管道里的两个 sort 保证了他的方案扩展性很差，尤其是只需要前 10 个的时候。
dubya查看英文原文
To be fair to Knuth, it's not the sort of little utility program that he usually works on. At least from TeX, Metafont, and the TAOCP books, it's usually really big problems, or very low-level things where cycle counts matter. The two sorts in McIlroy's pipeline guarantee that his solution won't scale well at all, especially when only the top 10 are wanted.
shell 方案的简洁依赖于背后庞大的工具库，若把这些工具的代码算进去，比较就不公平了。
这个比较并不公平。shell 版本之所以能工作，靠的是一套丰富的程序库。Pascal 版本则 presumably 是从零写起的。如果把 shell 脚本调用的所有程序的源代码都算进来，Knuth 的方案相比之下可能会好看得多。
lisper查看英文原文
This is not exactly a fair comparison. The shell version works by using a rich library. The Pascal version presumably worked ab initio. If the source code for all the programs invoked by the shell scripts were included, Knuth's solution might look considerably better by comparison.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选