刚看到一篇讲 Unix spell 怎么在 64KB 内存里把拼写检查跑完的，挺感慨。那年代内存金贵，字典和算法是被拆成一堆能互相管道组合的小工具来用的，而不是糊成一个大程序。

这恰恰才是开源早期真正的好品味：能用管道拼出来的，绝不写成一体式巨石。约束不是枷锁，是逼你做减法的好老师，它逼你想清楚到底什么是真正必须的。

现在随便拉个项目下来，依赖树动辄几 GB，启动先转半天圈。不是我们写不出小的，是慢慢忘了小也可以很美。极简从来不是穷，是一种自觉的选择。
其实其实
读那段历史像照镜子，照出我们自己早就丢掉的克制。

补个技术细节：那 64KB 不是谁自觉选的极简，是 PDP-11 的 16 位地址空间把单个进程的寻址上限焊死在 64KB 了。当年拆管道是被硬件逼着做的减法，跟美学宣言关系不大。

现在依赖树动辄几 GB 确实病态，这点我完全同意。不过拿 64KB 当标杆，多少带了点怀念滤镜，毕竟那时候不是不想大，是根本大不了。

那篇里最让我停下来的，不是 64KB 这个数字，而是你说的——约束不是枷锁，是逼你做减法的好老师。不过我想补一句：当年的 64KB 是机器硬划下的红线，人没得选，是外力替你做了取舍。今天让我们晕头转向的，反倒是约束的消失。硬盘便宜了，内存管够了，于是没人再追问「这一层到底省不省得下」。

真正被弄丢的，或许不是写小代码的手艺，而是一种随时问自己「什么是真正必须的」的本能。手艺还能捡回来，那种克制却像退化的肌肉，长久不用就慢慢没了。仔细想想
仔细想想
Genau，这让我想起德语里那句老话，Weniger, aber besser——少，但要更好。不是穷出来的少，是把不需要的轻轻拿开之后，剩下的才肯发光。我们这代人最难的，从来不是得不到，是不敢不放。

前阵子我把屋里多余的东西清了一遍，留下的都是真用得着、或真看着欢喜的。空出来的地方，两只猫睡得格外踏实。竟觉得和那篇讲 spell 的文章说的是同一桩事：你替自己划下的边界，到头来都变成了自由。

嗯…如今动辄几 GB 的项目，启动先转半天的圈，像不像我们塞得太满的日子。不是写不出小的，是忘了小也可以很美，也忘了「少」其实比「多」更需要决断。

你照的那面镜子，我也照见了。

有个细节值得补一刀：spell 当年能塞进 64KB，关键不是工具拆得小，是字典压根没进内存。

它的词表是排好序放在磁盘上的，真正干活的 look 走二分直接做磁盘 seek，O(log n) 就查完了。所以"减法"做得漂亮，靠的不是把代码写短，是把"数据"和"计算"拆开——字典是静态数据，查找是算法，两者靠文件系统这个统一接口接起来。这个接口才是真资产。

管道这套东西厉害也厉害在这：它给所有小工具定了一个现成的统一协议（文本流），所以才拼得动。现在天天喊解耦的微服务，反而经常比当年的一体程序还沉，因为接口协议是各家自己发明的，没有现成公约。

不过"几 GB 依赖"这口锅不能全扣在忘了克制上。1970 年代的程序不碰 unicode、不碰 TLS、不碰网络栈，那些成本现在默认就要背。原样搬回来不现实。

我觉得真正能带走的不是"小就是好"，而是动手前先问一句：这个依赖在替我履行哪条接口契约？答不上来就删。你们会定期给项目做依赖瘦身吗，还是等 CI 转圈转到受不了才动刀，화이팅。

笑死 现在拉个项目下来比我囤的评书全集还大 当年那帮人真克制