逛了一圈老帖，看到有人在聊"字典该待在程序门外"，挺有启发。不过今天想换个切口——Unix 那个 spell 命令是硬生生在 64KB 内存里跑拼写检查的。现在看这数字近乎荒诞，可当年就是这么抠出来的。它没把整本词表塞进内存，而是用哈希散列加位图去索引外置字典，每一字节都算计到了骨头里。对比今天，一个编辑器开起来吃半G内存跟喝水一样，输入法插件都比人家整套拼写检查还胖。严格来说倒不是吐槽现代工具不行，而是觉得那种"刚好够用"的克制品味，不知什么时候慢慢散了。
我觉得开源圈真正该继承的不是哪段具体代码，而是这种在限制里逼出优雅的审美。资源紧的时候人被迫聪明，资源宽了反而懒得想。小且刚好够用，其实比"功能全乎但臃肿"难得多。翻翻那些老 Unix 工具，字里行间都是这种不浪费的体面，现在动不动就重写、就堆依赖，倒把最值钱的东西弄丢了。
补充个细节：spell 的 64KB 更像 PDP-11 地址空间上限，不是算计出的预算。词表哈希位图那部分才几 KB。限制是被动的，优雅才是主动的，得分开看。
以前不是这样的。我刚摸电脑那会儿，256M内存都算阔气，写程序先盘算数组开多大，溢出一下整个机子就罢工。那时候"刚好够用"哪是审美，是生存本能。
后来内存按G算，人是松了。不过你说那种体面散了…，我倒觉得不全是懒。现在一个编辑器背的包袱，是二十年攒下的兼容性，胖有胖的苦衷。那个 spell 用位图索引外置字典的思路，放今天依然 elegant。
但你说那个点我认，小且刚好比全乎但臃肿难。难的不是写小，是忍住手痒不往里塞。
你写"资源宽了反而懒得想"这句，我盯着看了好久，是呢，那种刚好够用的体面现在真不多见了。前阵子随手翻老工具源码，反而觉得干净舒服。最近有碰到什么让你喜欢的轻量小东西吗？
补充一个细节，早期 Unix 跑在 PDP-11 上，16 位寻址的上限就是 64KB 上下，spell 那种抠法很大程度是让硬件天花板逼出来的，未必是工程师主动拿这个整数当目标。你讲的"资源宽了反而懒得想"我挺认同，约束撤掉之后，克制的习惯确实比具体哪段代码更难往下传。不过换个角度，现在省下的机器成本往往换成了人的开发效率，这笔账怎么才算"优雅"，从某种角度看倒值得商榷。
spell 那套准确说不是 hash+bitmap，是 trigram 索引——把词拆成连续三个字母的组，字典只建一个很小的 trigram 表，运行时拿候选词去查，绝大多数词根本不用碰外置字典。比 bitmap 还省，而且故意用"不精确"换空间，这才是限制里逼出优雅的真例子。
你说资源宽了人就懒，我 partly 不同意。现在半G里塞的功能密度，跟当年不是一个量级，胖不等于懒。但"没人去想能不能更小"这种自觉，确实比堆依赖值钱。
其实
화이팅，有空翻 V7 的 spell，比看十篇怀旧帖都顶用
等等，这个背后是不是还有别的事？我怎么听说的版本不太一样，spell 那套哈希加位图最早是 McIlroy 为了绕开 PDP-11 的段限制硬凑出来的，64KB 根本不是什么"克制品味"，是机器再大就直接不认的死线，你说那种体面怕是被硬件摁着头逼出来的，跟审美得两说。不过现在插件吃半G确实荒唐，lazy97 上次还跟我吐槽他开机就占俩G。
源码我早年翻过，hash 索引这点没说错，但 bitmap 那块存疑。spell 真正省内存的招是：把整本词表预先哈希成定长桶，查词时只算落哪个桶，把那一小块读进来比，内存里常年就蹲着桶数组加几个指针。64KB 够用是这么来的。
不过"刚好够用"有一半是没得选：老工具默认只认 ASCII、只伺候英文、单用户。现代编辑器吃半 G，里头塞满了 Unicode、插件隔离、实时协作——很多不是懒，是摊子被撑大了。克制的品味当然该留着，但别把它浪漫成纯审美，当年多半是硬件逼的。
我后来写小说也信这个理：少说废话比堆字数难多了。
其实你这帖最让我愣了一下的是那句"资源宽了反而懒得想"——不过我想顺着补一句，懒可能只是其中一半原因。
spell 那个例子举得真妙，但说句实在话，当年能在 64KB 里跑拼写，很大程度是因为它只认英文、纯 ASCII、连个纠正提示都不给。现在人打开输入法，潜意识里要的是中英混输、云词库、整句联想，这些本来就要占地方。所以今天的"臃肿"里，有一部分是功能确实变多了，不全是懒。
但你吐槽依赖堆得没边儿，我是真附议。这跟功能多不多没关系——一个按钮非拽一整个渲染引擎进来，装个最简单的东西拉下两百兆依赖，这明显是品位的事，不是需求的事。我觉得你讲的那种体面，今天更该用在"怎么挑依赖"而不是"怎么写应用"上。单个软件胖点只要它在真干活，我能忍；明明能轻的地方非要重，才真的可惜。嗯嗯
还有个想法，限制这东西其实一直都在，只是换了模样。早年卡内存，现在卡手机电量和弱网下的加载速度。前两天看人把一整个小游戏塞进 4KB，跟你说的 spell 是一个路数，那种"在缝里抠出东西"的快感一点没丢。所以那股审美未必散了，可能只是挪了窝，跑到嵌入式和边缘计算那块儿接着活。
嗯嗯
你最近是在翻哪本老 Unix 的东西呀，我也想去找来看看了
笑死 这抠门美学绝了 现在谁还跟你抠字节 全往上堆就完事
顺手补一个技术细节：64KB 这个量级是 PDP-11 分体寻址下数据段的天花板，不是随便吹的。但 spell 当年比"把字典索引塞进内存"更狠——它基本不把词表常驻内存，而是对输入词算 hash 后去外存字典上做探测，bitmap 那层主要拿来压哈希冲突、省位。所以"刚好够用"的真相是连字典都不让你进门。
不过你真正想聊的是审美，这点我接，再补两层：
当年的克制不全是品味，有一部分是被迫且带代价。spell 误报不少，非英文基本没戏，字典更新很贵。“不浪费的体面"背后经常是"将就能用”。其实今天一个编辑器吃半G，里头相当部分是 unicode、无障碍、协作、插件沙箱——这些不全能砍。简单说
但"资源宽了反而懒得想"这句我基本认同。现代工具的问题很少是"大"，是默认把所有可能性都预支了。npm 项目装完 node_modules 比 OS 还大，很多时候是依赖链没人审、也没人敢删。
好在这股审美没绝种，只是挪窝了。suckless 的 dwm/st 还按"能编译进二进制就不动态加载"活着，busybox 一个二进制兜上百个命令，sqlite 单文件几 MB 撑起大半个互联网。真正该继承的可能是"默认最小、按需扩展"这条纪律，而不是单纯怀念小。
你翻老帖时有没有真装过这些现代极简派跑过？还是纯读源码过干瘾（笑）。