用自己造的语言跑 DOOM：一个独立开发的任性项目

原文来源：56,000 lines of DOOM, in a language I made up — 一个开发者花了 34 小时，用自己设计的编程语言重写了 DOOM

"用自己造的语言跑 DOOM。"

这句话对程序员群体的吸引力，大概相当于"在自己的车库造了一枚火箭"对航天爱好者的吸引力。不是因为它很实用——而是因为它确实很酷。

项目全貌

bet 是一门编程语言。表面上看，它的关键词像群聊里的缩略语（squad、crib、yeet、bet），像个玩笑。但下面藏着一个正经的编译器：通过 LLVM 编译到原生代码，自己管理内存，能自举（self-hosting），而且——跑通了 DOOM。

这不是一句空话。56,000 多行原始 C 源码（渲染器、游戏逻辑、WAD 加载、音频）被完整重写成了 bet，编译成了原生二进制，能正常运行 shareware 版的 DOOM。

—— 广告 ——

玩笑外壳下，bet 解决了一个真正困难的问题：游戏的帧预算下的内存管理。

游戏每帧都会大量创建和销毁对象——子弹、粒子、碰撞检测临时数据。传统做法是手工 free() 或者 GC 暂停扫内存，这两者在游戏跑满帧的时候都会出事。

bet 的方案是 arenas（竞技场），只不过给了自己的名字：

code

crib wave                   // 为本帧分配一个竞技场
squad e in spawn(wave) {    // 在竞技场中生成敌人
    e.tick()
}
evict wave                  // 一帧结束，整个释放，O(1)

crib（婴儿床）分配一个本帧的作用域，"用完一帧就全部丢掉"。不需要跟踪每个对象，没有暂停，没有内存碎片。

这个思路来自 Zig 和 Odin，但 bet 把它做成了语言内的一等语法——有专门的关键词，不是库函数。

项目页上有一份按任务拆分的工时记录，数据来自 commit 跟踪的计时日志：

这个时间账本有几个值得注意的点：

LLVM 后端只花了 1 小时。 看起来最硬核的部分，反而因为工具链成熟和 AI 辅助效率最高。

游戏移植占了一半以上时间。 真正的工作量不在于"写一个编译器"，而于"让编译器产生的代码能跑真实软件"。定点数运算必须精确到比特位——差一个步长，DOOM 里的玩家就开始撞墙。

总耗时 34 小时。 从想法到能跑 DOOM 的完整编程语言，不到一个工作周的时间。这在五年前是不可想象的。

这个项目还有一个有趣的角度——它本质上是一个实验：AI 编程代理在没有人类代码审查的情况下，能在多大程度上完成一个定义明确的项目？

作者的描述是：

"架构师设定问题和验收标准；零代码审查——只有测试、验收标准和语料库作为关卡。"

结果是 bet 成功了。编译器正确、DOOM 能跑、能自举。当然中途也有卡住的时候——三次 AI 代理因为用量限制挂起，给游戏移植部分额外加了 ~12 小时。

这不是说 AI 可以替代程序员了。但它确实说明：当你把问题定义得足够清晰（一门语言的语法规范、DOOM 源码作为参考实现、明确的测试集），AI 可以作为一个非常高效的执行者来完成具体编码。

项目页面明确写着：没有路线图，没有 2.0 版本。

"如果说这个项目想证明我什么，那就是我能够完成我 started 的事情。"

这在开源世界是一种罕见的姿态。大多数项目要么永远在"beta"，要么积累了做不完的 feature request。但 bet 从一开始就定义了自己的范围——完成就是完成。

你不需要去造一门语言。但 bet 这个项目展示了几个有价值的东西：

明确的范围 = 完成的概率更高。 很多人做项目做到一半搁置，是因为做着做着就无限扩张了。bet 从一开始就只有一个验收标准：DOOM 能跑。
快速验证一个"傻想法"。 34 小时，从零到能跑 DOOM 的语言。这个速度意味着你可以快速验证那些"可能很蠢但万一呢"的想法——如果不行，也只浪费一个周末。
找一个"足够酷的终点"来驱动项目。 "跑 DOOM"这个目标，提供的驱动力比"写一个编译器"强 10 倍。当你觉得写词法分析器很无聊的时候，想想终点站的 DOOM 画面。