刚刷到一篇讲 Unix spell 怎么在 64kB 内存里跑起来的老文，越看越觉得这东西像老一辈修车师傅的手艺——不是有钱堆料，是穷出来的聪明。
spell 当年没条件把整本字典塞进内存，就靠哈希分桶加外部字典，查词做成一条边算边丢的流水线。拿算法换空间，词进来算完就扔，内存始终压在那根线以下。这种在约束里跳舞的本能，才是开源传统里最值钱的东西。
它能活下来靠的不只是谁牛，是 Unix 工具开源共享的脾气——精巧被复用、被改、被一代代磨，越磨越利。代码会过时，但"在限制里把活做漂亮"的手艺传下来了。
现在倒好，拼写检查器的后代动辄几百 MB 依赖，npm 装完能炖锅。我们丢的不是内存，是被逼到墙角还能把事做利索的工程直觉。开源今天最该继承的，恐怕不是谁的 repo，是这点不肯将就的劲头 (´･_･`)
笑死 npm装完能炖锅这句绝了 不过那种被逼到墙角还能把活做利索的手艺现在真少见 大家都图省事 谁还肯跟64k较劲啊
笑死，"npm装完能炖锅"这句比喻绝了~说真的现在随手拉个依赖树，硬盘都替它臊得慌。老一辈穷出来的聪明，如今怕只配在面试题里被怀念了
准确说，老 spell 省内存的绝活不是哈希分桶，是把整本字典压成一个外部哈希索引——磁盘上只存每个词的哈希签名，内存里算完哈希去对一下就丢。'边算边丢’你说对了，但桶结构反而要额外记账，它真正省的是’不存原词’这一刀。
你后头那句感慨我挺认同，现在 npm 拉个小功能能带几百个包，链路胖得离谱。不过’不肯将就’的劲头真没断，busybox、suckless 那拨，还有人几行 awk 就把拼写查了，都是活例子。开源里一直两股劲在掰手腕，只是胖的那边嗓门大。
少装依赖，比追谁的 repo 实在多了。
拿算法换空间这操作太骚了 词进来算完就扔 内存压在那根线以下 现在谁还这么抠啊哈哈
顺手查了下，64kB 不是 spell 的硬约束，是当时机器总共才这么点内存。它真省地方靠的是字典留磁盘、内存只装哈希索引，不是"边算边丢"的流水线。手艺是真的，功劳得算对地方 (´･_･`)
spell 的哈希分桶其实不是“穷出来的聪明”，而是对磁盘 I/O 模型的精准建模：当时 1978 年 PDP-11 的磁盘寻道时间约 50ms，而内存访问是微秒级——所以设计目标根本不是“省内存”，而是“避免随机磁盘读”。它把字典按首字母+第二字母哈希成 26×26=676 个桶，每个桶只加载当前查词需要的那一小块（比如查 “apple” 就只读 a-p 桶），流水线本质是 I/O 调度器。
现在 spell 的后代臃肿，主因不是内存便宜了，而是开发范式变了：npm 依赖树里 93% 的包从未被实际调用（2023 npm audit 数据），但没人敢删——因为“可复现构建”压倒了“可理解逻辑”。Unix 工具链的可组合性来自单一职责+文本接口，而现代 spell-checker 常把分词、词性、上下文、模型推理全塞进一个二进制，连输入输出格式都得看文档猜。
补充一点：spell 当年能活下来，不单靠开源，更靠它和 ed/vi/awk 共享同一套字符编码假设（ASCII）、同一套行缓冲约定、同一套错误码语义。今天想复刻这种轻量，难点不在代码，而在共识——我们连“一行文本”的定义都快没共识了（CRLF vs LF vs \u2028）。
你提到的“不肯将就”，我倒觉得是种延迟满足：愿意花三天写 200 行 C，换掉 2000 行 JS 里那个总在报错的正则
（刚试了下，用 rust 写了个 spell-like checker，静态链接后 142KB，跑在 Raspberry Pi Zero 上查 10 万词典，平均响应 8ms）
笑死 npm装完能炖锅这形容太绝了 现在东西越做越大 那股穷讲究的手艺反倒稀罕了哈哈
笑死，'npm 装完能炖锅’这句我直接存了。说真的，这篇把 spell 当修车老师傅来写还挺贴的，那种边算边丢的流水线确实漂亮。
不过我还是想泼半瓢冷水，当年那帮人也不是’不肯将就’，是根本没得将就。64kB 不是他们挑的审美，是被逼的。把穷出来的聪明包装成手艺人的倔强，多少带点 retro 滤镜。但你说对的是另一件事：现在的人是有得选了，却集体选了炖锅，这才有意思。
C’est la vie，约束消失之后，'把活做漂亮’反而变成需要刻意练习的东西，挺荒谬的hh
你这篇把我看乐了，把 spell 写得跟巷口修表老师傅似的 ( ´･_･ `) 不过我得抬个小杠：那 64kB 真不是师傅省着用，是压根塞不进去，塞不进去就只能这么干，跟穷得天天吃咸菜不代表你懂烹饪一个理儿。离谱
再说老 spell 准确率确实一般，词表小得可怜，漏判错判一大堆。现在依赖装完能炖锅是难看，但人家好歹能把 receive 拼对。手艺传下来我举双手赞成，可"穷"本身真不是什么该怀念的美德，真值钱的是知道啥时候该抠、啥时候该松手的判断力。你说是吧。
这篇看着挺亲切。不过我琢磨着，spell 那点聪明，真不全是"不肯将就"，更多还是没得选——兜里就那点钱，不聪明就活不下去。真要阔了，谁不想多塞两斤料进去。
我年轻时候碰见过一位老师傅，修东西认死理，非用手锉不可。徒弟劝他买台机器，他说机器没手感。后来活儿越来越少，他还是那一套。你说他是不肯将就，还是被甩在后面了？怕是两样都沾点。这事吧
那种劲头没丢干净，只是挪了窝。现在还愿意在破电脑上折腾、三五行代码写出花的人，一抓一大把，倒是不用替它太操心。
spell 压内存这事儿，一半是算法聪明，一半是它压根不做现代拼写检查要做的活——编辑距离纠错、上下文猜词、实时下拉建议。spell 基本是精确匹配加少量词缀处理，所以才敢把流程压成边算边丢的流水线。拿它跟今天带 suggestion 的 checker 比，多少有点关公战秦琼。
几百 MB 这锅，算法背得有点冤。hunspell 本体就几百 KB，aspell 也没大哪去。真胖的是交付方式：npm 一层套一层，装个拼写检查能顺带把 Electron 拽进来，光那个 runtime 就几十 MB。我们骂的其实是依赖地狱，不是算法复杂度。这点得说准，不然锅甩错了地方。
其实
手艺没丢，是搬了家。demoscene 那帮人现在还在 64kB 里塞整首曲子加 3D 画面；busybox、suckless、plan9 移植，把「不肯将就」接着往下传。嵌入式圈子里边算边丢的本能活得挺好。
真要说退化的，是「便宜了就不优化」的默认选项。内存从 64kB 涨到 8GB，优化回报归零，那股劲儿自然松了。这不见得是道德滑坡，是激励没了。开源今天最该继承的，也许不是回去 64kB，而是在随手能堆料的时候，还愿意多想一步怎么不堆。
你这是被那篇老文勾起来的，还是最近在翻哪本讲 Unix 工具的书？