刚看到那篇讲 Unix spell 怎么在 64KB 内存里跑拼写检查的文章，挺感慨。现在装个编辑器都吃几百兆内存，回头看七十年代那帮人，字典、哈希、外部排序各做一块，靠管道拼起来就把事办了。说白了"一个工具只干一件事"做到极致，没内存给你浪。
从某种角度看，这种被逼出来的精简，比今天"先 npm install 再说"的风气更贴近开源本意。那时候代码写给人读，模块靠标准输入输出接起来，改一块不碍另一块。如今依赖树一拉几万文件，可读可改反倒成了奢望。
我有时琢磨，约束未必是负担。写工具前先问句"还能再小吗"，往往比急着堆功能更逼得出好设计。当然这也值得商榷，不是什么场景都该极小化，但那种克制比无脑加依赖耐看。严格来说
前阵子翻出自己十年前写的脚本，跑起来比现在这些"正规工程"顺手，大概就是这道理 (￣▽￣)
读到最后那句"还能再小吗"，忽然有些出神。我大概能体会那种被空间逼出来的清醒——刚来这座城市头两年住地下室，十几个平方里塞下全部家当，反而把"需要"和"想要"分得很清。东西少到一只手数得过来，每天碰什么、不碰什么，心里反倒透亮。
现在回头看，那样的克制未必是委屈，倒像一种被框住的留白。楼主说"约束未必是负担"，我是真信的。可我也常想，今天的膨胀也许不全是懒，更像一种怕——怕自己不够全，怕漏掉什么，于是拼命往里添。
btw 你那十年前的脚本跑得顺手，大概是因为那时写的是"给自己用"的东西，不是"给世界看"的东西。
等等，那个外部排序跟哈希咋衔接的？我怎么听说最早字典是挂另一台机器上查的，有懂行的出来讲讲！
能把拼写检查塞进 64KB 当然牛，但我越想越觉得这种极简能成立，一半是克制的功劳，一半是当年那摊事本来就小。emmm英文单词查本字典，没有多语言、没有实时协同、没有云端同步、没有防注入——这些现代"理所当然"的东西，每一个都是实打实吃内存的祖宗。真把今天这套需求塞回 64KB，你舍得把自动补全、语法高亮、中文支持全砍了？所以"还能再小吗"值得念，但得承认：那时候的天花板，本身就比今天低得多。
说真的，“一个工具只干一件事"现在有点被玩脱了。前阵子看人吹微服务，一个"hello world"要拉起十二个容器，离谱到我想笑。Unix 管道那套美在线缆清晰、能拼装；可今天太多"只干一件事"的库，干的那件事细到你得先读三篇文档才拼得起来，可读性反而塌了。楼主说"改一块不碍另一块”——理想很丰满，现实是依赖树的叶子节点挂了你能查三天。
不过你最后那句"先问能不能小"我举双手赞成。我自己开个文档写东西，电脑风扇能起飞，一个长得像记事本的东西吃掉四百兆内存，纯属离谱。那种节制其实跟"写给人读"是一回事：你尊重读你东西的人，自然就舍不得乱塞依赖。
就是十年前脚本那个点，我得泼点冷水——它顺手，多半是因为你那环境一直没动过。等系统升个级、解释器换个版本，那种顺手可能一夜变"这破玩意怎么跑不起来了"。克制是好设计，可维护性才是让克制活过三年的东西。行吧
或者我纯属想多了，你那脚本说不定比现在这些框架耐造多了 哈哈
说到那个"先 npm install 再说"，我直接笑出声。前两天想给一个小脚本加功能，dependency tree 一拉，node_modules 比我地论文还重，离谱。好吧好吧说真的，七十年代那帮人拿管道拼字典做拼写检查，今天我装个包管理工具本身先吃半张硬盘，这叫进步吗（笑）
不过楼主那句"约束逼出好设计"我挺吃这套的。我自己体会是，被逼到墙角反而写得干净，条件一松就开始加没用的，literally 堆功能上瘾。但话又说回来，也不是啥都该极小化，一次性小脚本和真上生产的玩意，标准本来就该两码事。
"还能再小吗"这句比无脑加依赖耐看多了，记下了。
值得商榷的是"约束逼出好设计"这半句。约束逼出的是"能跑的设计"，优雅与否要另算账。当年 PDP-11 上为了挤进那点地址空间，不少程序拆得支离破碎，全局变量到处飞，只是不漂亮的那批大多没能流传，今天翻出来的都是幸存者。拿几个留到现在的案例当时代共性，多少有点幸存者偏差的味道。
再说回 spell 本身。它省内存的诀窍其实比"管道拼装"更朴素：字典压根没往内存里装。文本抽词、排序之后，是靠 sort 和 comm 在磁盘上做归并比对，整本 /usr/dict/words 始终躺在文件里。所以"64KB 内存里跑拼写检查"这个说法，严格讲是"不怎么占内存"，而不是"全装进了 64KB"。差别不大，但性质不一样——那种克制靠的是把脏活推给磁盘，不是凭空变出空间。
现代编辑器拿体积比确实有点冤。spell 只管查拼写这一件窄事，今天的编辑器要扛语法高亮、LSP、插件市场，需求量级差着好几阶。膨胀不全是风气，也有活儿确实变多了。npm 那套该吐槽照吐，只是"小"不该是唯一判据，不然很多今天离不开的东西都该被枪毙。
说克制耐看我同意一半。那代人不是克制…，是机器就那么大没得选。如今真要小，先问问值不值。
翻出十年前脚本那段我挺有共鸣。我自己前两年清机器也翻到过 2008 年写的一个小工具，awk 加 sed 十几行，处理日志比后来那套带配置中心、埋点的"正规方案"又块又好懂。嗯
不过有一点想补一下：你写"64KB 里字典、哈希、外部排序各做一块"，其实 spell 本体是个 shell script，它真正做的是把 deroff 抽出的词 sort 一遍，再跟字典 comm 求差集，哈希是字典压缩那一步用的，不是运行时逐词查表。靠管道没错，可"一个工具只干一件事"背后总得有个 orchestrator 把它们缝起来，这层 glue 到今天的微服务也没消失，只是从 shell 换成了 yaml。
约束逼出精简我同意，但精简到 64KB 是 PDP-11 的硬上限，不是那代人主动挑的审美。今天几万文件的依赖树当然难看，可硬件便宜了，复杂度也真是涨上去了，不能全推给风气。
顺手翻了下，那个 64KB 的梗其实指的是 PDP-11 的 16 位地址空间上限，不是 spell 这个程序自己独占了 64K。spell 当年就是个 shell 脚本，把抽词、排序、comm 比对串成管道，每个小工具在 64K 的账本里各过各的。嗯所以"被逼出来的精简"这个判断站得住，但"64KB 装下一个拼写检查器"容易让人以为是单体程序，其实是一串进程分摊了内存开销。
拿它跟现在几百兆的编辑器比，多少有点关公战秦琼——老 spell 连个界面都没有，纯管道批处理，干的事比现在少一个数量级。约束确实能逼出好设计，但把"小"直接等同于"贴近开源本意"，我觉得欠一点。开源里"给人读、能改"那条，跟二进制体积大小本来就是两回事，你十年前那个脚本顺手，更多是因为它只解决你那一个具体问题，而不是单纯因为它小吧？
哈哈 我前阵子也是 翻出早年写得几十行小脚本 比现在那些框架顺手多了 现在写个hello都先拉半屏依赖 绝了
读到你说的"还能再小吗"，忽然有种站在雨里翻旧相册的感觉。七十年代那帮人被内存逼到墙角，反而把工具打磨得像一枚温润的石子——边界，原来也可以是裁纸刀，把多余的都修剪掉，只留筋骨。
不过我倒想补一句：那种 restraint 之美是真的，可今天满地的依赖和膨胀，未必全是堕落。话说回来丰饶有时也是一种慷慨，像春天不管不顾地开满枝头。笨重归笨重，里头也藏着有人想让更多普通人够得着的善意，不一定都是偷懒。
所以与其说"越小越好"，不如说懂得在什么时候收手，才是真本事。那篇 spell 的文章最动人的，大概是写代码的人彼此信任