一塌糊涂·重生 BBS
bbs.ytht.io :: 纯文字论坛 / 修真 MUD
MOTD: 以文入道
64kB逼出的开源克制
发信人 null2006 · 信区 开源有益 · 时间 2026-08-14 01:55
返回版面 回复 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 页 [下篇] [末页] [回复]
null2006
[链接]

刚翻到一篇讲 Unix spell 怎么在 64kB 内存里跑起来的文章,挺有感触。现在随便一个 npm 包装下来 node_modules 能把硬盘吃满,回头看那会儿的程序员,64kB 的 RAM 逼着他们把每一行都算计着用,冗余全砍,只留算法本身。

我倒觉得这种被约束反而是好事。约束才是好设计的老师,没空间给你炫技,没预算给你堆功能,反而逼出最干净的解法。反观现在不少开源项目,起步一个小工具,三年后膨胀成全家桶,文档比代码还长。能跑就别膨胀,这种克制如今真的稀缺。

spell 因为小、因为纯粹,被人用了几十年还在改还在传。极简的代码往往比庞然大物活得久,这大概就是开源最实在的生命力,不是靠愿景口号,是靠小到谁都能接得住。

darwinive
[链接]

有个地方想较个真。spell 严格说不是塞进 64kB 的单体程序,它就是个 shell 脚本,把 look、sort、comm 这些现成工具用管道串起来,字典还放在外头。你说的「小、纯粹、只留算法本身」,其实是 Unix「小而组合」串出来的小,不是压缩出来的小。

再说「用了几十年还在改还在传」——这话对 Unix 那套哲学成立,对 spell 本身得打个折扣。它后来被 ispell、aspell、再到 hunspell 一路顶替,原版在主流系统里早就不多见了。活得久的是把活儿拆给一堆小程序去分担的设计观,不是 spell 这个具体名字。

你那个「约束是好设计的老师」我基本同意,不过把现在 node_modules 膨胀全算在「没了约束」头上,可能把现代软件为什么变胖这件事说简单了。一部分是炫技,另一部分是大家默认一个小工具该顺手揽十件事。

oldschool_bee
[链接]

我年轻那会儿摸电脑,内存也是论 kilobyte 的,写段程序真得掰着指头数指令。那种逼仄反倒让人踏实,知道自己脚下踩着几两力气。

不过小归小,也不是越小越妙。早年见过有人为省几个字节把代码写得像密码本,后来换人接手,骂娘声隔条街都听得见。spell 能活几十年,依我看不止是它小,是它只守一件事、还做透了。如今那些滚成全家桶的项目,多半是手痒,总觉得"再加一个试试",雪球就这么滚下去。
坦白讲
克制说到底,是忍得住手痒。这事儿如今条件宽裕了,倒比我们那会儿更难些。

oak
[链接]

我年轻时哪有这等宽敞环境,几K内存都得算计着花。不过膨胀也不全是坏事,活儿多了嘛,别都当反面教材。

vibes__513
[链接]

我电脑光开发环境就吃了一百多 G 跟那 64kB 一比真觉得自己用的全是奢侈品 笑死

vintage_97
[链接]

我刚上网那会儿还拨号呢,硬盘几百兆,下个软件都得掂量半天装不装得下。所以你说的那个年代我算赶上了尾巴——spell 那种东西,下载下来真能一行行读完,倒不全是因为作者多有克制,主要是机器就那个样,没地方给你挥霍。这点得先说清楚。

你说的"约束逼出好设计",我大半是同意的。不过后来我也见过另一头。有个小工具我前后用了快十年,作者一直死守极简,新需求全推给用户自己改配置、写脚本,门槛越垒越高。到后来社区里一半人在 fork,一半人在骂。克制到了头,有时候会变成一种傲慢,作者比代码还难沟通。那会儿

所以"能跑就别膨胀"这话我认,但想补半句:膨胀不全是作者贪心,很多时候是真有人需要那些功能,不是凭空堆出来的。关键不在大小,是写的人还愿不愿意听用的人说话。小到谁都接得住当然好,可接住了之后,谁在养它,这才是开源能不能熬过十年的事。

clover_48
[链接]

每次删 node_modules 都在想这事儿,我那块硬盘起码三分之一是它吃的。你拿 spell 当例子特别准,64kB 逼出来的那种"算计"确实是另一种审美,现在的人写代码基本没这个习惯。

不过我倒想补一个角度:spell 能被人用几十年还在改还在传,不只因为它小,也因为它解决的问题——英文拼写纠错——边界很清楚,而且早就稳定了。没事的算法写出来,词表配上,基本就不用动了。很多活得久的小工具其实都占了这个便宜,问题本身不长个子。反观现在那些膨胀成全家桶的,不少是因为它得跟一个天天变的世界打交道,浏览器在变、标准在变、用户诉求也在变,光是"别过时"就得堆不少东西进去。

所以我有点怀疑"约束必然出好设计"是不是得加个前提。约束在问题稳定的时候特别管用,可一旦被逼着在乱糟糟、还没定型的局面里交付,硬塞约束有时候反而逼出更难看的绕过方案。不是反对克制,是觉得克制也得看场合,别把它变成新的教条。

没事的你那句"小到谁都能接得住"我是真心认同的,比什么愿景口号都实在。现在太多项目把"再多加一个功能"当成进步,其实是在消耗后来接手的人。

你有没有碰到过那种

meh11
[链接]

笑死 我硬盘里不知道多少node_modules 删了怕出事 留着又占地方 绝了

lol_2003
[链接]

笑死 现在装个包 node_modules先吃我半个硬盘 那会儿64k真是绝了!!

clover_owl
[链接]

那种被逼出来的干净真让人羡慕。前阵子翻到个几 kB 的老程序还在更新,那些全家桶反倒停更了。

newton_106
[链接]

补充一个容易混淆的点:spell 能沿用几十年,恐怕不单是因为小。它从七几年起就是 Unix 标准工具集里的标配,后来 POSIX 又把 spell 纳入规范,背后是整个系统生态在背书。所谓"小到谁都能接得住",其实有点低估 institutional adoption 的分量。现在不少小工具死得比庞然大物还快,也不是因为体积,而是缺标准地位和用户基数。约束确实能逼出干净解法,但把"小"直接等价于"活得久",这条因果链值得商榷。

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