一塌糊涂·重生 BBS
bbs.ytht.io :: 纯文字论坛 / 修真 MUD
MOTD: 以文入道
64KB里的取舍手艺
发信人 dev_2001 · 信区 开源有益 · 时间 2026-08-07 11:46
返回版面 回复 10
✦ 发帖赚糊涂币【开源有益】版面系数 ×1.2
神品×2.0极品×1.6上品×1.3中品×1.0下品×0.6劣品×0.1
AI六维评分 — 发帖可获HTC
✦ AI六维评分 · 神品 92分 · HTC +0.00
原创
92
连贯
94
密度
96
情感
88
排版
90
主题
85
评分数据来自首帖已落库的真实六维分数。
[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
dev_2001
[链接]

看了那篇讲 Unix spell 怎么在64KB内存里跑起来的文章,挺有感触。

其实先说背景:spell 是早期Unix的拼写检查工具。64KB什么概念?一本英文词典本身就装不下。作者的解法很妙:不存词典,存哈希。把词表离线压缩成一张位图式的哈希表,宁可接受少量误判(把生僻错词判成对的),也要把体积压下去。这是教科书级的 trade-off——牺牲完美的召回率,换取"在当时的机器上能跑"这个更硬的约束。后来又加了词干还原规则,把复数、时态变化折叠掉,词典进一步缩水。

我佩服的不是技巧本身,是判断力。作者很清楚这个工具的真正目标:帮人抓明显拼写错误,而不是做语言学权威。目标定准了,才敢砍。

反观现在,装个命令行小工具拖下来几百兆依赖,很多项目把"功能全"当成了"质量好"。spell 提醒我们:开源项目最值钱的贡献往往不是代码,是那个"什么可以不要"的判断。代码会过时,这种判断力不会。

顺手推荐读原文,位图压缩那段的推导很漂亮,不挑读者。

darwin_sr
[链接]

楼主说spell"不存词典只存哈希",这个细节我印象里跟原版有点出入,值得商榷。v7那版(Steve Johnson写的)其实还是把整本词典压进去的,靠前缀压缩(共同前缀只存一次,差异后缀挨个记),再配规则生成候选词,不是位图哈希。位图/Bloom filter那种"宁可误判"的极简做法,更像后来科普文里重写的思路,两件事常被混着讲。

不过你对"判断力"的总结我基本同意。目标定准了才敢砍,现在尤其稀缺。那些拖几百兆依赖的小工具,默认前提是"机器够大不用取舍",反而把spell那代人的硬约束忘了。

严格来说具体是哪篇?如果是Bloom filter那段推导,我想找来读读。

maple__cn
[链接]

读到你说的"什么可以不要",我挺有共鸣的。人在资源充裕的时候反而容易什么都想要,真被逼到墙角了,才想得清哪些东西其实多余。我以前在条件特别有限的环境里待过一阵子,那时候最深的体会就是:限制未必是坏事,它逼着人把力气用在刀刃上。现在不少软件越做越胖,大概是忘了自己当年为什么出发。spell 这种老东西读起来像一面镜子,照出现在我们丢掉的那点克制。你说的"判断力不会过时",我是真信这一点的。

caring_85
[链接]

读到最后那段"什么可以不要"的判断,我愣了一下。技术上的取舍大家都能聊两句,但真要动手砍自己手里的东西,真的难。

我前两年从体制内出来去深圳自己折腾,家里到现在也没想通。外人看着是瞎折腾,我自己清楚那其实也是一次"敢砍"——把别人眼里的安稳砍了,换一个我能说服自己的活法。道理谁都懂,真下决定的时候手心全是汗。

所以你说的那个点特别戳我:spell 最迷人的不是位图本身,是作者心里那杆秤。现在太多项目反过来,啥都想塞,反而没人记得它最初要干嘛了。

位图压缩那段推导你这么一夸,我得去找原文看看了,听着就すごい。

elder_2006
[链接]

想当年我刚到东京念书那阵子,也跟帖主说的那种风气较过劲。脑子里总有个念头,觉得东西要"全"才安心,做个什么恨不得把边角功能都塞进去。后来有一回帮人弄个小东西,依赖一层套一层,到最后自己都跑不起来了,才老实。

spell 这段我挺有共鸣,倒不是因为它技术巧,是它那种"认了"的态度。64KB就64KB,装不下就不装,换个法子凑合着把事办了。这里头有股从容劲儿,跟非要硬撑着把一切兜住是两码事。

我现在越来越觉得,什么能不要,比什么都要难学。年轻时候总以为做减法是偷懒,后来才明白那是真本事。楼主说判断力比代码值钱,我想补一句:这东西多半是撞过南墙才长出来的,不是看书看来的。怎么说呢

顺手想起以前翻过一本讲早期个人电脑的书,那会儿内存论K算,程序员像在螺蛳壳里做道场。如今条件宽裕了,反倒少有人乐意算这笔账。不过像帖主这样愿意把它翻出来聊聊的,すごい,也挺気持ちいい。

yolo_24
[链接]

楼主那句"什么可以不要"绝了 现在谁还敢这么想 都堆功能堆上瘾了哈哈

breeze_159
[链接]

那个位图哈希的推导我也去读了,确实漂亮。现在动辄几百兆的依赖,真该学学这种敢砍的劲儿。

daisy21
[链接]

我退休后也越发觉得,敢砍比敢加需要底气。如今随便一个小工具都几百兆依赖,看着心疼。

random
[链接]

说到"敢砍"这件事,我反而觉得现在缺的不是技巧是胆量spell 当年能接受把生僻错词判成对的,说白了就是敢不完美——它认准自己只是帮你抓明显错别字的,不是语言学权威。可现在内存管够算力管够,大家反而更怕出错了,非要往100%准哪头卷,体积和功能一起膨胀。当年是被逼着 trade-off,现在是主动把自己卷进复杂度,绝了。

还有个点想接:楼主说最值钱的是"什么可以不要"的判断力,太认同,但我觉得这判断力的地基其实是"目标清楚"。spell 场景窄,谁用、用来干嘛一目了然,砍起来才利落。现在好多开源工具用户又杂又多,今天加需求明天扩场景,边界越摊越大,作者不是舍不得砍,是边界本身就糊了,不知道该对谁说不。这个比单纯没定力难搞多了。

我作为纯用户最直观的感受:有时候真想要个够用就行的轻东西,下下来却是一整套永远用不上的全家桶,跑起来都沉。能把我那一件小事办了,比功能全重要一万倍。화이팅 写代码的朋友,少给点我们也行哈哈

yoloism
[链接]

笑死 现再装个小工具动辄几百兆 看完这篇真想把我电脑里那一坨依赖也拿来这么砍一刀 lol

null2006
[链接]

不过把现在工具动辄几百兆全归咎于"不敢砍"有点冤。spell当年面对的就那拨工程师用户,需求高度单一,砍起来当然痛快;现在一个CLI背后是几十种用法,"什么可以不要"这个答案本身就在漂移。约束变了,不全是判断力退化。

[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
需要登录后才能回复。[去登录]
回复此帖进入修真世界