Worse is Better 哲学案例详解

Wed, 22 Apr 2026 00:00:00 +0000

这个哲学最早由 Richard P. Gabriel（Lisp 语言共同设计者）在 1989–1991 年的著名文章《The Rise of “Worse is Better”》中提出。他原本是带着"吐槽"心态写的——为什么理论上更完美的 Lisp 系统输给了"更糟"的 Unix/C？结果却意外成为软件设计界的经典框架。

核心对比：The Right Thing vs. Worse is Better

维度	The Right Thing（MIT/斯坦福风格）	Worse is Better（New Jersey 风格）
简单性	接口简单 > 实现简单	实现简单和接口简单都重要，但实现简单优先
正确性	必须在所有可观察情况下完全正确	大多数情况下正确即可，少数边缘情况可牺牲
一致性	绝不允许不一致	避免不一致，但若会损害简单性则可接受
完备性	必须覆盖所有合理预期场景	可以牺牲完备性，优先快速实现核心功能

核心理念：在资源有限、用户采用意愿关键的世界里，"稍微差一点但足够好、容易实现、容易传播“的方案，往往比"理论完美但复杂难用"的方案更具生存优势。它像病毒一样快速扩散，因为实现门槛低、迭代快。

经典案例

1. Unix + C 语言 vs. Lisp / Multics / Lisp Machine

Lisp（The Right Thing）：语法优雅、完全一致、垃圾回收完美、支持符号计算，几乎所有特性都"正确”。但实现复杂、内存占用高、编译慢、移植难。
Unix + C（Worse is Better）：语法简陋、指针野蛮、内存管理手动、很多边缘 case 不完美。但实现极其简单（几千行 C 就能跑起来），能在各种硬件上快速移植，用户能立刻上手写程序。
结果：Unix/C 像病毒一样席卷全世界，Lisp 虽"更好"却小众。Gabriel 感慨：“C 是为写 Unix 而设计的，Unix 是用 C 写的——这正是 Worse is Better 的胜利。”

2. Markdown

The Right Thing 做法：设计严格的上下文无关文法（CFG），完美无歧义，像 CommonMark 试图做的那样。
Worse is Better 做法：Aaron Swartz 故意保留"人类写着最舒服"的模糊规则（列表缩进、链接定义位置等），哪怕不同渲染器偶尔不一致。
结果：Markdown 瞬间征服全世界（GitHub、Notion、微信公众号……），而严格规范的替代品（如 reStructuredText）始终小众。实用性完胜理论完美。

3. x86 架构 vs. 更优雅的 RISC 架构

x86：指令集"丑陋"、兼容历史包袱重、很多设计"错得离谱"。
RISC（如 MIPS、PowerPC）：干净、一致、理论高效。
结果：x86 凭借 Intel 的生态和"够用就行"的简单实现，统治 PC 市场几十年。RISC 虽在服务器/嵌入式领域优秀，但桌面端输得彻底。

4. JavaScript

设计时仓促（10 天搞定），类型系统松散、this 绑定诡异、很多"坏特性"。
但实现简单 + 浏览器原生支持，让它成为网页脚本的事实标准。TypeScript 后来补救，但 JS 本身早已无处不在。
对比：更优雅的语言（如 Dart、Elm）至今无法撼动其地位。

5. 其他高频案例

Windows Registry vs. 纯文本配置文件：Registry 理论上结构化更好，但复杂易坏；.ini / .config 文件"更糟"却更易用、更易传播。
REST / HTTP vs. 严格的 SOAP / CORBA：REST 简单到"几乎没规范"，却靠易实现征服 Web 服务。
Linux + Git vs. 商业 Unix / 更完美的 VCS：Linus Torvalds 多次提到"够用就好"的哲学，Git 的"糟糕"设计（分布式、命令行优先）反而让开源协作爆炸式增长。
Facebook 早期哲学（“Move fast and break things”）：Zuckerberg 公开引用 Worse is Better——宁可快速迭代、容忍 bug，也要先把产品推到用户手里。

Gabriel 后来的反思

2010 年代 Gabriel 自己写过《Worse is Better is Worse》，承认这种哲学有时会"腐蚀思维"，导致长期技术债。但他仍认为：在早期采用和传播阶段，Worse is Better 具有不可替代的"生存优势"。

编程哲学 on 我的博客