[经典重读][1/n] Worse Is Better
最近想系统补一轮计算机科学和软件架构经典。书单来自 GPT Pro
找几十篇类似 The Bitter Lesson、No Silver Bullet、You and Your Research 的文章和书。
Codex 让写作成本低了很多，所以我想通过 AI 写作进行 Retrieval Practice。
第一篇选 Worse Is Better，因为它短，也因为我从读书时就听过这个名字，但从未读过。
它问的问题很直接：为什么很多没那么“正确”的系统，反而更容易获得 adoption，最后甚至变成标准？
Worse Is Better
Gabriel 在 The Rise of Worse is Better 里对比了两种设计哲学：
The Right Thing: 优先追求接口简单、行为正确、一致性强、覆盖完整。为了正确性、一致性和完整性，可以接受更复杂的实现。Worse Is Better: 优先追求实现简单。正确性、一致性、完整性都重要，但如果它们让实现变得太复杂，就可以先做取舍。
两边真正分歧的地方，不是要不要把事情做好，而是当简单性、正确性、一致性、完整性不能同时满足时，先保哪一个。
The Right Thing：系统应该替用户多承担复杂度，接口和语义应该尽量干净。实现复杂一点可以接受，因为复杂度被封装在系统内部。Worse Is Better：系统自己先简单下来，才更容易实现、移植和传播。用户多承担一点复杂度可以接受，因为系统活下来更重要。
原文里有个典型例子。系统调用被中断以后，The Right Thing 的思路是：系统应该恢复好状态，让程序能优雅地继续。Unix 的做法更直接：调用可能失败，返回错误码，程序自己检查后重试。
The Right Thing 会觉得这把复杂度甩给了用户程序。Worse Is Better 会觉得，实现简单更重要，多写一个检查和重试循环可以接受。
这个例子背后，是 Lisp、Unix、C 这些系统命运的分叉。更优雅的系统不会自动成为赢家。Gabriel 的判断是，Worse Is Better 往往更容易先占上风：
- 更容易实现
- 更容易移植
- 对机器资源要求更低
- 更容易先获得 adoption
一旦系统先获得 adoption，后面就会长出生态、补丁、教程、工具链和历史惯性。到那一步，再优雅的替代方案也会变得很尴尬：道理上我支持，但项目里先不换。
Gabriel 后面还讲了 The Right Thing 容易走向的两种结果：big complex system 和 diamond-like jewel。前者像 Common Lisp，功能接近完整，但系统大、实现慢、工具复杂、硬件要求高。后者像 Scheme，小而漂亮，但为了保持那种漂亮，设计和高效实现都会变得很难。一个太大，一个太精，最后都可能输在 adoption 上。
所以这篇文章真正有价值的地方，不是歌颂“差”，而是把两件事拆开了：工程上更对，和生态里更容易获得 adoption，不是一回事。
顺便一提，这个观点当年也不是一说出来全场鼓掌。Gabriel 后来回忆，那次 keynote 讲完以后，现场先是一阵沉默，接着 Gerry Sussman 等人当面开批。这个细节挺好，它说明这篇文章不是一句后来被供起来的名言，而是一次当时就不太顺耳的判断。
三十年后
我觉得这套逻辑仍然成立，但要说清楚边界。
Worse Is Better 主要解释的是 adoption boundary：一个系统怎么先获得 adoption、先进入现实世界。到了 leverage boundary，也就是系统已经被大量使用、开始承载更多复杂性时，The Right Thing 又会变重要。
过去三十多年里，这个模式反复出现：
| 例子 | Worse Is Better 的一面 |
后来的补课 |
|---|---|---|
| JavaScript | Brendan Eich 用十天做出第一版原型；语言并不优雅，但浏览器里默认存在 | TypeScript、lint、bundler、框架 |
| Python | 性能和类型系统都不是强项，但容易写、容易读、反馈快 | type hints、formatter、lint、packaging 改良 |
| Git | 命令行不友好，但数据模型强，分布式协作好，生态起来得快 | GUI、GitHub workflow、各种 porcelain 工具 |
| REST/JSON | 不如 CORBA 这类方案完整严整，但更容易看懂、调试和集成 | OpenAPI、schema、validation、typed client |
| Claude Code, Codex | 不稳定、不完美，但已经足够有用，所以先进入工作流 | evals、sandbox、verification、harness |
这些例子不能机械套。但它们都说明同一件事：更完整、更精致，不一定更容易先获得 adoption：Worse Is Better core + The Right Thing repair layers。
这不是“粗糙总比严谨好”。更像是：先上车，后补票。先进入现实，再慢慢为现实补秩序。
工程上的“对”和生态里的 adoption，不是同一个问题。真正难的是同时知道，什么时候该用 Worse Is Better，什么时候切回 The Right Thing。