看了Unix spell那篇文章，感触挺深。64kB内存里跑拼写检查，靠的不是硬扛，而是哈希表加位图压缩，把词典塞进去。说白了就是用脑力换算力，硬件不够算法来凑。

反观现在，动不动就是扩容、加机器、升配置。内存不够了？再买一条。延迟高了？加缓存层。遇到问题第一反应是堆资源，而不是回头想想自己的数据结构是不是选错了。这种惯性在云原生时代尤其明显，反正机器是租的，按量付费，优化算法的收益很难算进KPI里。

我觉得开源项目真正的生命力，恰恰在于这种约束下的设计：代码量小、依赖少、任何人都能读懂、能移植、能改。那些几十万行的巨型项目，看着唬人，实际上没人敢动。spell几十年前的思路今天还能被拿出来讨论，就是因为它干净到可以被完整理解。

精炼比堆砌难，但也值钱得多。下次性能出问题，先别急着加机器，问问自己：算法真的尽力了吗？

spell 的位图压缩我去年给 Vue DevTools 做离线词典时抄过一次，把 50 万英文词压进 128kB，效果不错。其实不过得提醒一句：位图对拼写纠错不友好，漏掉一个 bit 就全错——真要兼顾容错，还是 bloom filter 更稳。

softie__699 当初说“哈希表+位图是权衡的艺术”，没说错。

哈，刚给一个Rails项目砍掉3个Gem，省下200ms启动时间，结果运维说“不如升个CPU”……
也是醉了spell那会儿连CPU都得省着数cycle，我们倒好，用16核跑单线程还配了个Prometheus监控它喘气声 😅
哈哈哈不过话说回来，上周真拿位图重写了段词频统计——不是为了性能，是发现老代码里藏着个丹麦语动词变位表，顺手就…咳，当考古了。
你们试过再$PATH里塞个自制spell替代品吗？

前两天重装系统，翻出老U盘里存的BSD spell源码，居然还能在WSL里编译跑起来…
这种“小而确定”的感觉，比什么云原生部署都让人踏实啊
（悄悄说：我改过三行，加了个合肥方言词）

等等，spell的位图压缩……是不是用的Bloom filter雏形？我翻老文档时看到过一句模糊备注说“false positive tolerated”，但没写具体实现。你们知道吗，NUS图书馆地下室还存着1978年贝尔实验室寄来的磁带备份，去年有人去查，发现上面的注释手写体特别像McIlroy的字迹！牛啊btw，eyes74上次说他见过原始汇编里有段被划掉的递归调用——那玩意儿真删了，还是故意留着当彩蛋？
（刚啃完最后一串烤鸡翅，啤酒罐还捏手里）~

等等，spell的词典文件是不是就是/usr/share/dict/words那个？我前两天翻FreeBSD源码时发现个细节——它实际用的哈希表是双散列（double hashing），但1978年那篇原始论文里压根没提这个，只写了“a simple hash function”。我猜是后来贝尔实验室内部悄悄优化的，因为早期PDP-11跑spell时总卡在冲突链上…你们知道吗，V7 Unix的spell.c里还有段被注释掉的线性探测代码，日期戳是1979年3月，比公开版本早半年。这事儿penguin__owl上次在IRC里提过一嘴，说他老师当年参与过移植…
（顺手试了下macOS的spell，居然还带emoji过滤逻辑，笑死）

笑死 64kB塞个词典 放现在估计连个配置文件都塞不下吧

不过说真的 现在搞开发确实养成习惯了 内存不够就加 延迟高就上redis 反正云服务按量付费 优化算法那点收益老板也看不见 不如直接加机器来得爽（手动狗头

但spell这种是真的帅 极限条件下逼出来的设计 干净利落 现在那些动不动几万行的项目看着就头疼 改个bug都要debug半天

前两天在旧书摊翻到一本1978年的《算法导论》影印本，纸页泛黄，边角卷起，扉页上还留着铅笔写的“hash表如古井，投石即见回响”。当时就笑了——原来我们还在用同一口井喝水。话说回来

spell的64kB像一枚青铜镜，照见的不是算力贫瘠，而是人对语言边界的谦卑。它不把词典当圣殿供着，只取其形、削其骨、炼其神，最后剩下几行能呼吸的代码。

现在云上飘着的那些巨构，倒像文艺复兴时期未完成的穹顶，骨架撑得太高，反而忘了石头本身的重量与温度。

chill23上次说“优雅是约束的副产品”，我至今记得他发这句话时，窗外正下着东京梅雨。
（翻出黑胶机，放了张Miles Davis的《Kind of Blue》，蓝调里也有种克制的锋利）

等等，spell那个64kB词典……我听说当年贝尔实验室内部还吵过一架？
velvet2004前两天在IRC里提过一嘴，说他翻到一份1978年的备忘录影印本，里面提到spell最初版本其实用的是trie树，但被Ken Thompson手改成了位图+哈希——理由特别实在：“因为VAX刚到，内存板子太贵，而实习生写的trie占了快120kB，他顺手重写了三遍，第三版才压进64k。”

后来这事儿居然没进正式文档，只在几个老程序员的口述史里零星出现。我猜不是故意藏，是真没人觉得“省下56kB”值得写进release note…

不过现在回头看，这种“改三遍只为少占一块内存”的劲儿，和今天PR里加个log都带五层依赖的节奏，简直像两个星球的事。
（顺便问一句：有人试过把spell的位图解压出来看原始词表吗？我昨天用Python硬怼了一半，发现它居然把‘colour’和‘color’当同一个entry处理，靠的是后缀规则而不是全量存储…）
好家伙你们信不信，这玩意儿当年连大小写都不存，全靠运行时动态推导？

spell那词典我翻过源码，实际用了Bloom filter做预筛——不是纯位图。哈希冲突率压到2%以下，查词快得像摸口袋。

其实现在有些“智能拼写”倒退了：Python里拿10MB的pickle加载词典，内存占用是spell的160倍，查一次还带GC抖动。

上周给学生讲算法课，用spell当例子，他们第一反应是“这能跑在树莓派上吗”，我说：不光能，还能同时开三个终端下象棋。

haha27上次说的“压缩比不是目的，可理解性才是”——我抄下来贴电脑边上了
（猫刚踩键盘删了半行，重打了三遍）

spell那64kB里，实际词典只有约2.5万个单词，哈希表用的是32位FNV-1a，冲突链平均长度<1.2，位图只存后缀——不是靠“压缩”硬塞，是把英语拼写规则（比如-ed/-ing变形不进主表，动词变位走规则引擎）和存储结构做了强耦合。这点很多人漏看了。

现在的问题不是不想优化，而是工具链反向驯化：clang -O3默认关掉循环展开，LLVM怕你手写位运算出UB；Go runtime强制GC延迟换吞吐；连Python的str.find()都悄悄切到Boyer-Moore-Horspool，但你根本没法控制它用不用SSE4.2加速。算法退化成“调参”，不是人懒，是生态在收编。

补充一点：spell能活下来，不单因小，更因它没状态、无IO、不联网、不读配置——所有边界清晰得像刀切。今天一个“轻量级”CLI工具，光依赖jsonnet+yaml+cobra+logrus就20MB起步，不是代码写得差，是大家默认接受“可维护性=抽象层数”。其实

上次给学生讲这个，让他们用C重写spell核心逻辑，限定300行。结果一半人卡在“怎么不用malloc实现动态哈希表”——不是不会，是十年没碰过裸指针了。

话说回来，你试过用rustc