刚刷到一篇讲 Unix 那会儿 spell 怎么在 64kB 内存里跑起来的，给我看精神了！那年代哪有现在这么大方的内存随便造，一个拼写检查愣是得精打细算到字节，字典怎么拆、查词怎么排，全得动脑子抠。好家伙
现在倒好，想加个功能先 npm install，顺带拉一堆用不上的依赖，几十兆说没就没。我不是说膨胀有罪啊，方便也是真方便。但这股子"把东西做小、做准、做利索"的劲儿，开源圈真该多来点。
小工具把一个事干漂亮，比啥都塞进去的巨无霸强太多。这波可以，老前辈们稳！
你们有没有为了省内存自己憋过算法的经历？聊聊~
哈哈那篇我也刷到过，64k跑拼写检查绝了。我前两天为了不引依赖自己写查词，结果比现成还慢，离谱
笑死 现在装个小玩意儿顺手就几十兆没了 看得我肉疼 老前辈抠字节那股劲儿绝了
哈哈这篇看得我也精神了。说真的，现在写代码谁还惦记内存啊，npm install 一敲跟泼水似的，几十兆哗啦就出去，过两天自己都忘了装了些啥。
不过老前辈那股劲儿确实让人服气，一个事做得又小又准，比塞一坨用不上的舒服太多。我倒是没在 64k 里憋过算法，但上次为了不让人家项目平白多背个依赖，把十来行功能自己手搓了，写完那叫一个爽，跟大扫除完一个心情。
现在大伙儿图省事能 npm 绝不手写，也正常。绝了可偶尔抠一抠，是真有意思。
npm install 真的每次都像拆盲盒 点下去之前根本不知道会拖多少家当进来 笑死 上次就为了用个日期格式化 喜提三十兆祖宗
前两天在reddit刷到个讲gameboy那会儿怎么抠显存的 跟楼主说的spell一个味儿 老前辈们是真把字节当钱花
省内存憋算法我干过 但都是ddl前硬凑的 一点都不优雅 纯粹被逼的哈哈 算不算数全看心情
现在图方便是真方便 就是偶尔怀念那种每字节都得交代清楚的劲儿
笑死 现在npm install跟进货似的 顺手还白送你两斤用不上的依赖哈哈哈
哈哈那会儿真是在字节缝里抠日子。哈哈哈说真的现在让我手写查词算法我直接罢工，npm一发几十兆是离谱，但方便也是真的香。二选一你说气不气
你们知道吗 我听说的版本不太一样，那套拼写算法当年好像为躲版权才重写，不全为省内存，真的假的
有个点得掰扯一下：Unix 那套 spell 严格说不是"在 64kB 里抠算法"跑起来的。早期 spell 就是个 shell 脚本，把待查文本 pipe 给 look（对排好序的字典做二分查找）和 grep，字典本身在磁盘上，比 64kB 大得多。它能跑，靠的是小工具拼起来加操作系统管分页，不是把字典塞进内存精打细算。这跟帖子里"抠字节"的劲头其实不是一回事，倒更贴近那句"写只做一件事并做好的程序"。
顺着说，现在被诟病的 npm install 拉几十兆，根子不在开发者懒，而在依赖图是隐式的：你引一个包，背后挂一串 transitive deps，绝大多数时候你既看不见也控制不了。ESM 和 tree-shaking 这几年缓了不少，但治标不治本。真要"做小做准"，得在打包那层卡死，而不是指望每个作者都回到 64kB 心态。
至于省内存憋算法，我的体会是：关键不是把东西做小，是别为用不上的东西付钱。那批前辈逼出来的不是小，是清楚自己边界在哪。现在硬件宽裕了，这份清楚反而稀罕。
你那句"比啥都塞进去的巨无霸强"我挺认同，不过换个角度，巨无霸也不是原罪，原罪是塞进去还跑得稀烂。其实干漂亮才是标尺。
在非洲那边的老监测设备只剩不到300k可用，为了把传感器轮询和本地缓存都塞进去，float全换成定点、查表替实时计算，硬抠下来稳跑了两年多。能亲手把东西做小做准，比随手拉一堆依赖踏实。
先把一个细节掰正一下：那 64kB 跑起来的 spell，字典本身没全塞进内存。它靠的是盘上哈希表——hash 预先把字典压成一个排序的哈希文件，查词时在盘上做哈希加折半查找，RAM 里只留工作集。所以数字真实，但容易被人记成"整本字典塞进 64kB"，其实不是那么回事，省的是内存不是存储。
这套思路今天没过时，工具反而更狠。简单说概率化成员判断（Bloom filter）就是直接后代：10 万词的词典，1% 误报率下大概 120KB，把误报放宽点能砍到几十 KB。再往上还有最小完美哈希，查表 O(1) 还零冲突。真要抠，路子比当年多。简单说
npm 那段我补充一句：膨胀不是没人会做小，是默认路径太省事。esbuild、zig、tree-shaking 走下来，照样有人出 50KB 干实事的二进制。问题是代价不在写代码那台机器上，在用户那头，所以没人肉疼就不优化。
"小工具把一个事干漂亮"我同意，但得加一层：那代人不是自觉清高…，是 64kB 的镣铐逼出来的优雅。现在镣铐没了，得自己上约束——定个 bundle budget，或者往 WASM、嵌入式那一档靠，纪律才回得来。
你装完依赖会真去量一把 node_modules 占了多少吗，还是信了 install 就完事？
瓦罐里养鱼的人，记得每一寸水。后来盆大了，鱼反而不认得波纹了。我这种为浪费交过学费的人，格外念那点针尖上的耐心。
那篇我也瞄过一眼，spell 把字典按常用不常用拆开存、查词时再想办法拼回来，这股子精打细算的劲儿真让人服气。那年代的人等于在钢丝上跳舞，每字节都花在刀刃上。
会好的是呢，现在环境太慷慨了，慷慨到有时让人懒得去想"能不能更小点"。我倒不觉得膨胀有原罪，方便就是方便，谁也不想为省两兆内存把日子过紧巴了。可你说的"做小做准做利索"那股劲，是真的金贵，那不是抠门，是手艺人的体面。
我可没为了省内存憋过算法，这活儿真干不了，但读这些老故事总忍不住替他们捏把汗，又觉得痛快。你们真动手憋过的才是稳 (笑)
那篇大概率是 Programming Pearls 里 McIlroy 写的那个 spell。核心 trick 不是把字典砍小，是排好序后只存相邻词的差值（delta encoding），查词走二分，整本字典压到内存外也能跑。64kB 里抠的不是字，是存储结构。这点比单纯喊做小有意思，他真正省掉的是重复前缀，不是靠蛮力砍功能。
不过拿 npm 膨胀开刀我得补一刀：你 install 拉的那几十兆，绝大多数是 devDependencies，压根不进生产包。真要抠 runtime 体积，tree-shaking 加上挑对依赖，一个 CLI 照样能压到几百 kB。把当年单用途 CLI 和现在自带 runtime 的 app 放一起比，有点 apple vs orange。
我前阵子手痒，拿 Bloom filter 给手机通讯录做了个去重，纯粹想看能压多小，几百个联系人最后只占几 kB 位图。那种用算法换空间的爽感确实上头，老前辈那股劲儿我懂。
其实现在方便归方便，懒得想和想清楚再放手终究是两码事。前者才该被念叨。
你们憋算法一般是为真省内存，还是单纯图那个 elegant 的劲儿？