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

前两天刷到一篇讲Unix怎么在64KB内存里跑拼写检查的旧文,看完心里莫名静了一会儿。那年代没有如今随手npm install就拉来几百兆的依赖,spell把字典甩到外面,用哈希表和管道一点一点拼,硬是在一口气的空间里把事做完了。约束没困死它,反倒逼出一身精巧的骨头。

我总觉得开源最体面的样子就藏在这种小里。不是功能摞得多满,而是一个工具锋利、轻巧、肯跟别的工具握手。我觉得吧现在太多项目一上来就胖,依赖链像藤蔓缠成一团,谁也讲不清自己到底栽了什么进去。回头看那64KB,像面擦亮的镜子,照见我们弄丢的从容。

窄处也能把舞跳好看,这事本身,就够温柔了。

wise__360
[链接]

前阵子拉个库,依赖比本体还沉,跟你说的藤蔓一个样。以前一屏看透的清爽,真怀念。

nosy__jp
[链接]

你们知道吗,我听一搞这些老古董的朋友聊过,说那 64KB 的 spell 其实没帖子里写得那么"恰到好处"。字典甩出去是甩出去了,可当初那么干纯粹是因为内存真不够,不是谁在刻意追求什么克制之美。牛啊那面"擦亮的镜子",多少是后人自己擦亮了再摆上去的。

我不是扫兴啊,就是把当年的不得已当成一种自觉的体面,挺容易一厢情愿的。现在项目胖归胖,可你要是真活在那年代,天天手搓哈希表跟管道拼来拼去,还觉得它温柔吗?

ears2001
[链接]

我怎么听说的版本不太一样。那哥们把字典甩外面根本不是啥优雅克制,是64K真塞不下硬挤的。后来内存宽裕了,他转头往里塞,哪来什么初心。太!现在项目一上来就胖、依赖缠成藤蔓,确实离谱。

byteism
[链接]

你那个"哈希表塞在64KB里"的画面感很强,但经典 spell 真正省内存的招数不是把哈希表搬进来,而是压根不往内存里搬。文档过一遍 tr 拆词、sort、uniq 去重,再跟排好序的字典用 comm -23 比差集,全程流式走磁盘。sort 和 comm 本来就是外部排序加流式比对,额外占的内存几乎可以忽略。

所以那面镜子照的其实不是"小巧克制",是"脏活交给别的工具、自己只做拼接"。工具之间肯握手这点我同意。不过"64KB里的从容"更像是后人加的滤镜——当年那拨人多半是顺手把现有命令接起来,没想那么多体面不体面。

现在项目一上来就胖,根因也不全是审美丢了。npm install 太便宜,便宜到没人愿意先读一遍上游源码,确认自己到底要不要那几百兆。

meh
[链接]

笑死 现在装个输入法都比那64KB沉 那时候的人是真能省

wise_z
[链接]

前几天收拾屋子翻出张老软盘,里头就一个几KB的小工具,当年当宝贝使。如今随便点开个网页,后台跑的东西怕比那张盘整百倍还不止。不是技术退步了,是没人肯收手了。

你最后那句窄处把舞跳好看,我信的。年轻时总怕东西不够多、不够满,后来才懂,能收着的地方收着,剩下的才利落。生活里也是这个理。

tesla_ive
[链接]

这篇勾起我一点回忆。不过有一处想跟楼主商榷:spell 那个经典实现,严格说并不是"用哈希表和管道在 64KB 里拼"出来的。

我记得源头多半是 Bentley《Programming Pearls》里转述的 McIlroy 解法。它真正省内存的关键,是把字典当作一个已排序的文件留在磁盘上,再用 look(或 sort + comm 的管道)做外部归并或二分查找。哈希表想塞进 64KB 其实很吃力——一个像样的开放寻址哈希,面对十几万词的词典,光冲突和再散列就够受的。McIlroy 的漂亮之处在算法层面的"外包":能交给磁盘和别的小工具的,绝不自己扛。严格来说

所以与其说它赢在"小",不如说赢在"分工"。管道天然把状态拆散到多个进程,每个只持一小段工作集,看着克制,其实是操作系统在替它分担。64KB 这个数字,从某种角度看更像是一个叙事锚点,未必是真硬约束。

其实当然你说的"从容"我是真心认同的。只是把今天的胖简单归咎于"丢了克制",可能漏了另一面:现在软件要管 Unicode、多语言、网络边界、安全沙箱,这些当年根本不在 spell 的账面上。约束能逼出精巧,但今日的复杂度里也有真实需求的重量,不全是缠人的藤蔓。

你那篇旧文具体是哪个出处?我想找来重读一遍。

studiousism
[链接]

顺着你这帖把那篇旧文翻了出来,读着确实让人静。不过"64KB"这个数我想较个真——你说的 spell,具体是 McIlroy 哪个版本?

最早的 spell 其实是行 shell 管道:tr 剔掉非字母,sort 之后拿 /usr/dict 的词表 comm 一减,字典从头到尾没进过程序自己的内存。它轻,是因为把活全甩给了 sort、comm 和系统词表文件,依赖的也是一条链,只是那条链是操作系统本身,不显眼。

所以"老工具不胖"这话得分开看:它不胖,靠的是站在 Unix 一整套工具肩上,而不是真的在 64KB 里凭空变出魔法。后来才有那个想把字典哈希压进内存、不再外调 sort 的 C 版本,那才真去跟空间较劲。新项目的依赖膨胀当然该批评,但拿 spell 当对照时,把"借用系统"也算成"干净"就有点偏心了,老先生未必认这个账。

你那篇要是另有出处,麻烦甩个链接,我好奇到底是哪段被记成了 64KB。

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