展示 HN:GDSL – 800 行内核:Lisp 子集在 500 行内,C 子集在 1300 行内。
Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300

原始链接: https://firthemouse.github.io/

这篇帖子详细描述了作者构建编译器的惊人经历,并质疑现代编译器的规模。最初持怀疑态度,他们成功地创建了功能完善的C和Lisp编译器,分别仅用1500行和500行代码,且功能妥协最小。这让他们意识到,大型编译器(通常数百万行代码)中的许多复杂性并非任务本身固有的,而是源于大量的“接缝、景观和权宜之计”——不必要的添加和复杂性。 作者将这些大型编译器比作费力构建的、但无法居住的景观。他们自己较小的编译器代表着为一种新方法播下“早期种子”——一种“现代GDSL”,暗示着专注于基本功能和简洁性,而非庞大的功能集。这篇帖子标志着探索这一新方向的开始。

Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 展示 HN: GDSL – 800 行内核:Lisp 子集 500 行,C 子集 1300 行 (firthemouse.github.io) 8 分,作者 FirTheMouse 51 分钟前 | 隐藏 | 过去 | 收藏 | 讨论 帮助 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系 搜索:
相关文章

原文

Pages for posting about my work until I decide to tackle websites.

2/14/26

Early GDSL

Seeds 3/14/26

Compilers are enormous these days, millions of lines spanning frontend to backend to turn text to process on a system. Any small compiler gets small by making tradeoffs, it constrains itself to a shape small enough that it fits, or simply doesn’t implement the features.

That’s what I would’ve believed before I wrote a subset of C in 1500 lines, with the only feature compromises being ‘I haven’t built that part yet but I could’. Then, on the same kernel with zero modification, wrote a Lisp compiler in 500 lines. They’re fast enough to be useful, they aren’t fragile stacks of tightly optimized assumptions ready to collapse at a breath. They’re just 3 weeks of work reconstructing what a language can mean. Which made me ask: what are these other compilers doing that add the million lines?

And this is the answer I’ve landed on so far.

Seams

Landscapes

Kludges

Sixteen months of digging at concrete, bending pipes, and living in lobbies to build a patch of dirt.

it isn’t much if you look at it, it’s impressive just because it exists, but nobody lives on it.

I gave it a name, a plaque proclaiming it exists, and today I plant the first seeds.

Modern GDSL

联系我们 contact @ memedata.com