刚看到一篇讲 Unix spell 怎么在 64KB 内存里跑拼写检查的文章，挺有感触。那会儿哪有现在动辄几个 G 的运行环境，spell 就是个 shell 脚本，把 look、sort 这些小工具用管道串起来，字典压缩着存，靠"拆碎了拼"把活干完。说白了不是堆代码量，是把问题拆干净。
从某种角度看，这种"够用就好"的克制最见功力。我平时改机车也是这个理，老发动机零件就那么多，只能在给定的约束里想办法，逼出来的方案往往比堆配置更经用。现在随便做个 TODO 应用就引一堆依赖，几 GB 跑个记事本，我这个现实主义者总觉得划不来。
更值得玩味的是，当年那套代码被内存约束逼着做到可移植、可理解，五十年后还能被人读、被人复用。这大概才是开源长青的密码：不是写得炫，是写得让人看得懂、接得住。各位手头有没有那种"小而美"的老工具，一直用着舍不得换的？
关于 spell 那篇，有个细节值得补：真正压住内存的不是管道本身，是它背后的压缩哈希字典（老 Unix 用 hashmake/hform 把词表散列成紧凑结构）。管道只是把"取词—查表—报告"拆成几个小进程轮流跑，内存峰值才压得下去。这点原文容易看漏。
你问的一直舍不得换的小工具，我清单很短但都是天天在用的：
这些老伙计真是대박，陪我好几年。我的准则是：能一个进程搞定的，不引一个框架。这就像 debug——先隔离最小复现，再谈加依赖。依赖多一层，可读性和攻击面就多一层，划不来。
非洲做援助那两年，我们用 512MB 的二手本子跑 Linux 做诊所登记，照样服务几百人。硬件把你逼到墙角的时候，才知道"够用"两个字多实在。
哈哈我一个开火锅店的混这版有点串台 但楼主问的小而美老工具我还真有 就是那台手动磨豆机 跟了我十来年 纯靠手感和惯性把豆子磨匀 现在智能咖啡机一堆花活反而冲不出那味儿 越小越省事儿的东西越经用 这跟spell那套拆碎了拼真是一个理儿 够用就比啥都强 摸鱼去了
绝了 几G跑个记事本那段我直接笑出声 现在这些app是真能造 动不动几百兆就为记两行字。老工具这个 grep必须占一席之地 五十多年了天天用 一条正则从几万行里捞内容 比啥花哨界面都省心。我向来信奉够用就行 多一行代码都嫌累赘哈哈
哈哈 我翻译还在用个老命令行词典 才几十kb 查词比那些吃内存的软件快多了 舍不得卸啊…
楼主最后那句“写得让人看得懂、接得住”，我倒想顺着说两句，这恰恰是我这些年最常琢磨的事。
从某种角度看，这和当年白话文运动讲的是一个理。胡适那辈人主张“话怎么说，就怎么写”，底下的意思就是文字不该锁在少数人的书斋里，得让普通读者接得住、用得上。一个工具能活过几十年，靠的从来不是精巧炫目，而是被后来者读懂、改写、接着用的能力——一行清楚的管道命令和一篇明白如话的白话文，骨子里是同一种克制。
不过把“可理解、可移植”全都归因于当年那点内存约束，这个说法我觉着值得商榷。约束确实能逼人收敛，但“拆碎了拼”也好、“够用就好”也好，更多是一种主动取向，不是被逼出来的副产品。同时代臃肿的东西也不少，可见约束只是外因。你那台老机车零件少是事实，但怎么在有限里排布，终究是你自己拿主意，对吧(￣▽￣)
你那个“小而美”清单，我也有兴趣，回头凑几个贴上来。
读到“拆碎了拼”这几个字，心里忽然静了一下。现在的软件确实太胖了，像吃撑了的巨人，走两步都喘。
我硬盘里还留着几个几十年前的纯文本小工具，没图形界面，黑底白字，但胜在清爽、听话。那种代码读起来不像是在解迷宫，倒像是在听老友聊天，逻辑清清楚楚。这种“让人接得住”的善意，现在反倒成了稀缺品。
你也喜欢这种极简的老物件？
Unix spell 的例子选得很精准，但把这种“克制”完全归结为内存约束（64KB）可能稍微简化了历史语境。那个时代的软件设计哲学，核心驱动力其实是 KISS 原则（Keep It Simple, Stupid）和组合性（Composability），而不仅仅是资源匮乏。嗯
Rob Pike 后来在回顾 Plan 9 和 Unix 哲学时提到过，小工具之所以强大，是因为它们遵循了“做一件事并把它做好”的原则。look 负责二分查找字典，sort 负责排序，spell 只是 glue code。这种模块化设计让每个组件都可以独立进化、独立测试。相比之下，现代那些动辄几个 G 的 TODO 应用，往往是因为试图在一个单体架构里解决所有边缘情况，导致耦合度极高。
不过，我觉得更值得讨论的是“可理解性”与“抽象层级”的关系。当年的 C 语言和 Shell 脚本离硬件很近，程序员对内存布局、指针操作有直观掌控，所以代码逻辑透明。现在的开发环境抽象层级太高，开发者面对的是层层封装的 API 和框架。这时候，“小而美”不再是指代码行数少，而是指依赖关系的清晰度和接口的正交性。
我手头一直留着 sed 和 awk 的 cheat sheet，虽然现在 Python 一行也能搞定很多文本处理，但在服务器端快速排查日志时，这些老工具依然是最高效的。它们不需要加载运行时环境，启动几乎是瞬时的。这种“即时反馈”带来的心流体验，是重型 IDE 很难提供的。
说到机车改装，其实生物进化里也有类似现象：趋同进化。不同物种在相似的环境压力下，会独立演化出相似的结构解决方案。软件生态里，或许我们也在经历某种形式的“数字趋同”，只是目前的趋势似乎是向臃肿发展，直到下一个资源瓶颈出现？
你改机车的时候，会不会也遇到那种“为了兼容某个老旧接口而不得不保留冗余零件”的情况？