Revisiting "Let's Build a Compiler" • Hacker News Board

Re: Revisiting "Let's Build a Compiler"

#51

Post by seg_lol » Fri, Dec 12, 2025, 3:33 AM UTC

zwnow wrote: post #4

xyproto wrote: post #3

Earlier quoted context omitted.

"breaking things down into the right primitives" is the real key to programming. There are many books and web pages about algorithms, but I wish there were more searchable and browsable resources for how to approach problems through primitives.

The process of breaking a complex problem down into the right primitives requires great understanding of the original problem in the first place. Whats blocking me during programming usually are edge cases I had no idea about. Its still hard to find good material on compilers if you are not into reading dry ass books. Thats a me problem though, I simply cant force myself to read boring factual only content (one of th…

There is a good body of literature that is distinct from the academic compiler literature.

https://t3x.org/

https://compilerbook.com/

https://interpreterbook.com/

https://www.craftinginterpreters.com/

R. G. Loeliger Threaded Interpretive Languages Their Design And Implementation https://news.ycombinator.com/item?id=43973544

https://github.com/IUCompilerCourse/Essentials-of-Compilatio...

And check out Andy Keep's Nanopass Compiler work, https://nanopass.org/

Re: Revisiting "Let's Build a Compiler"

#52

Post by AlexeyBrin » Fri, Dec 12, 2025, 1:42 PM UTC

qsort wrote: post #23

ernst_klim wrote: post #19

> Rather than getting stuck in front-end minutiae, the tutorial goes straight to generating working assembly code, from very early on. I think this is important and for a more sophisticated compiler design I find Ghuloum approach very appealing [1]. I.e. build a very simple subset of the language from top to bottom and then grow the meat gradually. The really great book following this approach I've discovered recentl…

Yeah, I think this is one of the (few, rare) cases where the "official" academic way of teaching the subject is actually baggage and not really aligned with what's practically useful. Compiler courses are structured like that because parsing really was the most important part, but I'd say in the "modern" world once you have a clear idea of how parsing actually works, it's more important to understand how compilers im…

> Even if you want to implement a compiler yourself, "Claude, please generate a recursive descent parser for this grammar" is close to working one-shot.

How is this even close to implementing it yourself ??? If Claude gave you the code, by definition, you didn't implemented it yourself - you hired a third party to implement it for you.

Re: Revisiting "Let's Build a Compiler"

#53

Post by fuzztester » Tue, Dec 23, 2025, 1:08 AM UTC

microtherion wrote: post #48

fuzztester wrote: post #40

Earlier quoted context omitted.

Thank you. Just to confirm, by "accessible", do you mean easy to understand? Anyway, I think I had come across that book on the net, but did not check it out at the time. I don't remember the exact reason, maybe it was because I didn't want to go into the subject of compilers at the time, and was only interested in interpreters, because I prefer to take things one step at a time. Now I will check it out.

Yes, accessible in the sense of being readable without extensive prior knowledge. If I recall correctly, I read the initial edition while still in high school.

Got it, thanks.