刚刷到一篇讲老 Unix 的 spell 怎么在 64KB 内存里跑起来的文，稳，太稳了！最让我拍大腿的是它的路子：它压根没把整本字典搬进内存，而是靠哈希加压缩，把"这词到底存不存在"变成一个能秒答的问题，内存里只留张瘦巴巴的签名表。

现在咱随手写点开源小工具，内存随便造、依赖随便拉，反而很少再琢磨这种被逼出来的巧劲。我前阵子自己弄个小脚本，第一反应就是上库、加缓存，回头一看，其实几行哈希就完事了，纯粹是被"堆料"惯坏了。牛啊

这波老Unix的思路，搁今天也是顶好的开发经验。被限制逼出来的创造力，真比无脑堆资源爽太多 (￣▽￣)

等等，这个签名表的路子我怎么听着还有个坑？有个事不知道该不该说，我之前瞎翻过相关的，光存哈希签名是会误判的，两个八竿子打不着的词算出一个签名，就被它当"存在"了。

所以老spell玩的是"先猜后查"：瘦表秒筛一遍，真撞上了才去翻磁盘上那本完整字典复核。要不是被64K逼到墙角，谁想的出这种损招 (￣▽￣) 现在随手拉库加缓存是爽，但你说的"几行哈希就完事"我太认同了，纯是被堆料惯坏。你那小脚本后来真改回纯哈希没？

笑死，这帖戳我痛点了。我前阵子写个小脚本也是第一反应装库加缓存，回头一看纯属脑子懒。说真的，被冗余惯坏的不只内存，还有咱的脑回路 Хорошо

你那张"签名表"基本就是 Bloom filter 的思路:内存里只放一个 bit 数组,每个词算几个哈希位,全 1 才算"可能存在"。它有个铁律,绝不漏判但有误判率。所以严格讲不是"这词存不存在"秒答,而是"这词肯定不在表里"秒答,后者才是真零成本。

不过你最后那句,我得较个真:今天随手拉库加缓存,多数时候不是被惯坏,是内存管够时它本就是性价比最高的解。老Unix那套巧劲只在嵌入式或受限环境才值钱。为不存在的限制抠内存,是自找麻烦。真该学的不是回去用64KB,是写之前先问一句:这依赖我到底需不需要。

那张"瘦巴巴的签名表"这说法绝了，画面感直接拉满。说真的，现在写个小玩意儿，动不动先npm install半个互联网，缓存中间件一梭子，搞得像要盖栋楼。回头看老Unix那帮人，64K里装下整本字典的魂儿，靠的就是没得选，被逼到墙角反而蹦出真本事。

不过话说回来，咱今天堆料也不全是因为懒。好多时候今天写完明天就得上线，谁有空跟你抠哈希压缩那点空间。被惯坏是一码事，时代确实也变了，对吧。懒一点换开发速度，这笔账也不是不能算。

笑死 拍大腿+1 我前两天也是装一堆库 回头一看十行就能搞定 堆料真香（不是

绝了，几行哈希完事的东西现在偏要拉一整套依赖，惯坏的哪是工具，分明是人

笑死…，我前阵写脚本也是上来就 pip install，回头发现老 Unix 几行哈希就搞定，被惯坏属实了

看你说哈希那一段真觉得有意思，那种"不把字典搬进内存、只留张瘦签名表"的巧劲，现在确实越来越少见啦。

我也常有这种感觉，东西一多就先想着加装备，把简单事绕远了。前阵子收拾屋子，先买一堆收纳神器，回头发现几个旧纸箱就搞定，自己都乐了。

能像老Unix这样被逼出巧思，真挺让人佩服。现在条件宽裕，肯静下来用几行哈希换掉一堆依赖，反而更见功夫。没事的你那小脚本后来改成哈希版了吗，跑起来是不是清爽多了？

笑死 我也老这样 写个小脚本第一反应就是上库加缓存 回头一看纯属想多了 十几行哈希就完事 现在的人太被便利惯坏了哈哈

笑死 64KB那个真给我看愣了 现在写代码谁还管内存啊 第一反应全是pip install随便造 别说64KB 64MB我都嫌挤哈哈

我前阵子也犯这毛病 弄个小脚本统计玩意儿 上来pandas一套拉满 结果就几百行数据 朋友看了直乐说你杀鸡用牛刀 后来改几行正则直接出 尴尬死
笑死
不过被逼出来的巧劲是爽 但也别把现在那套说太不堪 堆料至少能跑还能交接给别人 全靠手写哈希后人来看怕是要头秃 时代不一样咯