刚看到那篇讲 Unix spell 怎么在 64KB 内存里跑拼写检查的文章，挺感慨。现在装个编辑器都吃几百兆内存，回头看七十年代那帮人，字典、哈希、外部排序各做一块，靠管道拼起来就把事办了。说白了"一个工具只干一件事"做到极致，没内存给你浪。

从某种角度看，这种被逼出来的精简，比今天"先 npm install 再说"的风气更贴近开源本意。那时候代码写给人读，模块靠标准输入输出接起来，改一块不碍另一块。如今依赖树一拉几万文件，可读可改反倒成了奢望。

我有时琢磨，约束未必是负担。写工具前先问句"还能再小吗"，往往比急着堆功能更逼得出好设计。当然这也值得商榷，不是什么场景都该极小化，但那种克制比无脑加依赖耐看。严格来说

前阵子翻出自己十年前写的脚本，跑起来比现在这些"正规工程"顺手，大概就是这道理 (￣▽￣)

读到最后那句"还能再小吗"，忽然有些出神。我大概能体会那种被空间逼出来的清醒——刚来这座城市头两年住地下室，十几个平方里塞下全部家当，反而把"需要"和"想要"分得很清。东西少到一只手数得过来，每天碰什么、不碰什么，心里反倒透亮。

现在回头看，那样的克制未必是委屈，倒像一种被框住的留白。楼主说"约束未必是负担"，我是真信的。可我也常想，今天的膨胀也许不全是懒，更像一种怕——怕自己不够全，怕漏掉什么，于是拼命往里添。

btw 你那十年前的脚本跑得顺手，大概是因为那时写的是"给自己用"的东西，不是"给世界看"的东西。

等等，那个外部排序跟哈希咋衔接的？我怎么听说最早字典是挂另一台机器上查的，有懂行的出来讲讲！

能把拼写检查塞进 64KB 当然牛，但我越想越觉得这种极简能成立，一半是克制的功劳，一半是当年那摊事本来就小。emmm英文单词查本字典，没有多语言、没有实时协同、没有云端同步、没有防注入——这些现代"理所当然"的东西，每一个都是实打实吃内存的祖宗。真把今天这套需求塞回 64KB，你舍得把自动补全、语法高亮、中文支持全砍了？所以"还能再小吗"值得念，但得承认：那时候的天花板，本身就比今天低得多。

说真的，“一个工具只干一件事"现在有点被玩脱了。前阵子看人吹微服务，一个"hello world"要拉起十二个容器，离谱到我想笑。Unix 管道那套美在线缆清晰、能拼装；可今天太多"只干一件事"的库，干的那件事细到你得先读三篇文档才拼得起来，可读性反而塌了。楼主说"改一块不碍另一块”——理想很丰满，现实是依赖树的叶子节点挂了你能查三天。

不过你最后那句"先问能不能小"我举双手赞成。我自己开个文档写东西，电脑风扇能起飞，一个长得像记事本的东西吃掉四百兆内存，纯属离谱。那种节制其实跟"写给人读"是一回事：你尊重读你东西的人，自然就舍不得乱塞依赖。

就是十年前脚本那个点，我得泼点冷水——它顺手，多半是因为你那环境一直没动过。等系统升个级、解释器换个版本，那种顺手可能一夜变"这破玩意怎么跑不起来了"。克制是好设计，可维护性才是让克制活过三年的东西。行吧

或者我纯属想多了，你那脚本说不定比现在这些框架耐造多了 哈哈