一个人用C语言写了1门编程语言：编译器不是魔法

GitHub上有个项目，作者用C语言从零写出一门完整的编程语言，带词法分析器、解析器、抽象语法树、字节码编译器、栈式虚拟机、类继承、字符串插值、break/continue、复合赋值、用户模块，还有内置静态分析器。Star数不到500，但评论区全是"我读了三年编译原理没搞懂，看你代码懂了"。

这事最扎心的地方在于：作者不是科班出身，代码量不到8000行。

国内某大厂编译器团队的工程师私下跟我说，他们招应届生时最怕遇到"读过龙书但一行代码没写过"的候选人。简历上写着"熟悉编译原理"，问起来连递归下降解析都讲不清楚。这个项目作者反着来——先写代码，后补理论，反而打通了。

8000行代码里藏了什么

项目结构很直白：lexer.c负责把字符流切成token，parser.c递归下降生成AST，compiler.c遍历AST吐字节码，vm.c执行字节码。没有LLVM，没有第三方库，纯C手写。

类的实现用了经典的"对象头+字段数组"布局。每个对象头存类型指针和GC标记，字段按声明顺序排。继承通过原型链查找实现，super调用翻译成运行时指令序列。字符串插值在编译期展开为拼接操作，不是运行时解析——这个选择省了不少性能开销。

静态分析器是后来加的。作者发现新手用户最常犯的错误是未定义变量和类型不匹配，于是在编译前端加了趟遍历，不生成代码，专门报错。这设计很产品经理思维：用户痛点在哪，功能就补在哪。

代码示例能跑通面向对象全套：

class Animal {

fn init(name, sound) {

self.name = name

self.sound = sound

fn speak() {

print self.name + " says " + self.sound

class Dog extends Animal {

fn init(name) {

super(name, "woof")

let d = Dog("Rex")

d.speak()

输出：Rex says woof。没有运行时依赖，单二进制文件直接执行。

为什么"从0写"比"读10本书"管用

作者在项目README里写了句话：「Learned more from this than from anything I've read. Compilers are not magic.」

这话我翻译一下：编译器的神秘感，很大程度上来自教材的叙述顺序。龙书第一章先讲形式语言、有限自动机、正则表达式，新手还没见到代码就已经晕了。但这个项目作者选择"先让东西跑起来"——lexer先用最笨的switch-case写，能识别关键字就行；parser先不支持优先级，括号强制分组；VM先用数组当栈，性能以后再说。

跑通第一个能算1+1的版本后，再回头看理论，每个概念都有具体的代码锚点。DFA不是抽象定义，是lexer里那个状态转移表。LR冲突不是习题，是parser面对左递归时的真实选择。

国内某985高校的操作系统课用了类似思路：学生两周内先写出一个能启动、能打印字符的"玩具内核"，再学进程调度、内存管理。挂科率比传统教法低了一半。原理是一样的——认知负荷要分批给，先建立信心，再填充细节。

手写VM这件事，2024年还有必要吗

肯定会有人说：现在都用LLVM/MLIR/WASM，手写字节码 interpreter 是不是开倒车？

看场景。如果你想在浏览器里跑，WASM是正确选择。但如果是嵌入式脚本、游戏MOD、配置语言，一个几千行的自研VM反而更可控。作者这个项目的目标场景很明确：学习。而"可控的复杂度"对学习是加分项——你能单步跟踪每一行代码，没有黑箱。

另一个隐藏收益：面试。国内某头部云厂商的编译器岗位，一面常考"设计一个简单的表达式求值器"。候选人有两种表现：读过龙书的，开始讲语法树、中缀转后缀；写过类似这个项目的，直接说"我用递归下降，运算符优先级用 Pratt Parser 处理，这是处理负号和减号冲突的细节"。后者通过率明显更高。

项目评论区有个细节很有意思。有人问了句"为什么不用Rust"，作者回复「Started with C to keep it simple, might port later」。没有语言宗教战争，没有"系统编程必须用内存安全语言"的表态。这种实用主义态度，在当下的技术讨论里反而稀缺。

代码最后更新是两周前，作者在加GC的增量标记功能。从玩具到生产可用，这条路还长。但第一个能跑通类继承的版本，已经够让很多人重新理解"编译器不是魔法"这件事了。

你上次写超过1000行、没有依赖第三方框架的代码，是什么时候？