刚看了篇讲 Unix spell 怎么在 64KB RAM 里跑起来的老文，挺有意思。现在项目动不动几百 MB 依赖，装个 spell-checker 跟搬家公司似的。可人家当年在 64KB 硬约束下，把算法和数据结构压榨到极致，用极小代码量把"拼错没拼错"这个真实问题解了。

这事儿我挺共鸣。做 hip-hop 的都懂，boom-bap 时代采样就那几小节几个 chop，限制反而逼出最狠的 flow。constraint 不是敌人，是 creative constraint，开源里这点最明显。spell 把巧思公开、让后来者直接 fork 改写，比什么 license 宣言都实在，传承就这么长出来的。

我平时搞量化也一个理，latency 就是我的 64KB，差一毫秒真金白银。工具该服务于人，不是堆砌显摆。现在太多项目把 simple 做成 complex，回头看 spell，是个不错的 reality check (´・ω・`)

补充一个细节：那个 64KB 更像是 PDP-11 分段地址空间的天花板，不是 spell 程序自己吃掉的内存预算。真正值得拿来做 reality check 的是它把整本词典压成哈希加位图来做成员判定，从某种角度看这套思路就是后来 Bloom filter 的雏形，比单纯"代码量小"这个点更经得起推敲。

有个事儿我老想抬杠：咱们这帮人总爱把"当年 64KB 写出花"当浪漫故事讲，但细想，写 spell 那帮老哥是真有得选吗？硬件就给你 64KB，你不压榨就跑不起来，那是被迫的优雅，不是选出来的禅意。boom-bap 那点采样逼出狠 flow 我懂，可 hip-hop 当年也是穷得只能采样才走上路的，不是谁主动"选了限制"来陶冶情操。所以 creative constraint 这词我认同，但得加个前提：被逼出来的巧思是生存，主动给自己设限才是创作，两码事。

不过你后半段说"把巧思摊开让人 fork"才是真传承，这点我举双手。当年写程序五年，最爽的就是改别人开源的代码，站在别人肩膀上比啥 license 宣言都实在。emmm我后来转行写小说更确认了这点——能被人接着抄、接着改，这东西才是活的。呵呵现在一堆项目 README 写得跟募捐信似的求 star，反倒忘了开源最朴素的快乐。

你拿量化 latency 当 64KB 我得小小损一句：人家的约束是真穷，你的约束是几百万美金的服务器 farm，这叫"富贵病式约束"吧 (￣▽￣) 但道理没毛病，真金白银盯着的时候，花活自然就收了。说真的，现在看那些几百 MB 依赖，我第一反应还是离谱

笑死 现在装个依赖能拽下半个宇宙 人家64KB就把拼写搞定。simple这词现在是真被玩没了哈哈