刚看到一篇讲 Unix spell 怎么在 64kB 内存里跑起来的老文，挺感慨。那年代的拼写检查不是把整本词典塞进内存，而是词库留在磁盘，内存里只算索引和哈希，“数据外置、计算内聚"八个字就把思路说清了。
其实
真正厉害的其实不是省了多少内存，而是受限环境逼出来的那种克制。每字节都要算计，不依赖、不膨胀，反而写出来了好用又耐读的代码。放到今天看，这本身就是开放协作最好的范本，你读得懂，才改得动。
其实
反观现在，随便一个开源小工具，node_modules 装下来能塞满半个仓库，几百 MB 起步。我们不是没能力做小，是慢慢把"够用就好"的节俭弄丢了。可恰恰是"小”，才带来可读和可移植。有时候真觉得，该把那一代人的手艺捡回来。

顺着那个 64kB 的例子，有个事实值得先校准一下：spell 当年那么小，很大程度不是因为那代人更克制，而是 PDP-11 的地址空间就是 64KB 量级的硬天花板。换句话说，那更像“不够也得够”的被逼，而不是“够用就好”的选择。把后来的手艺浪漫化成一种自觉的节俭，容易把外部约束和内部修养混为一谈。

这不代表“小带来可读和可移植”没道理，只是因果要倒过来看。真正值得捡回来的，可能不是体积本身，而是当年那种把约束显式写出来的习惯。当年不写不行，今天显式了反而少有人写。

至于 node_modules 动辄几百 MB，我倒觉得不能全算退步。同一份拼写检查，今天要处理 Unicode 全字符集、防辞典型投毒、做 AST 级错误定位，这些在 1978 年根本不在需求列表里。膨胀里有一部分是真功能，有一部分才是惯性依赖。一刀切归为“丢掉了节俭”，对维护者不太公平。

更想讨论的是那句被轻轻带过的“读得懂才改得动”。老 Unix 不少代码是高度优化的紧凑 C，能跑但不一定好读，可读性更像一种理想而非普遍事实。今天开源项目的文档、测试和 CI 反而更规范，这算不算另一种意义上的“可读”？

你提到“数据外置、计算内聚”最接近今天的按需加载思路，这点我挺认同的。

笑死…，前两天帮人看个开源小玩意儿，光 node_modules 下载的功夫我奶茶都续了一杯还没跑起来。说真的，那代人的手艺是值得捡，但你指望现在人人都回去抠字节也不太现实，关键还是得有人愿意为"读得懂"这事儿较真。

你说的"数据外置、计算内聚"这八个字，我年轻那会儿是真见人这么干过。

刚离了写程序那行当的头几年，还留着个毛病：见着臃肿的东西就皱眉。后来慢慢想通——那一代人的克制，一半是内存逼的，一半也是脾气。真要讲"够用就好"，靠的是人肯算计，不是靠环境小。现在环境大了，肯算计的人少了，就这么简单。
我觉得吧
node_modules 那几百兆，里头多半也不是没用的，替你扛了不少兼容的苦。大不一定错，只是大了以后，愿意一行行读的人就少了。这倒是我较在意的。

读到那句"数据外置、计算内聚"，我盯着看了好一会儿。八个字，干净得像冬夜里结在窗上的霜，不沾泥，不带水。

楼主说手艺慢慢丢了，我倒不完全这么觉得。如今许多膨胀，是被"卷"出来的，不是做不出小，是怕小了显得单薄，怕别人一摞特性压过来，自己这边没话讲。我信竞争，也信长进要靠争，可争着争着，连转身的地方都挤没了。恍惚间倒想起当兵那两年，处处受限、日日约束，反而把许多多余的东西放下了，日子轻得不像话。

那一代人的克制，未必是手艺断了脉，更像是对"够用"二字有一种笃定。我们缺的，许是肯在刚好处停手的勇气。那种分寸感，我到现在都学不大来。