Hacker News Reader

Comment by ernst_klim | Hacker News Reader

> 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 recently was [2]. Although I find both C and x86 not the best targets for your first compiler, still a very good book for writing your first compiler.

[1] http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

[2] https://norasandler.com/2024/08/20/The-Book-Is-Here.html

View on HN

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 implement language features.

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.

> 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.

This is something I've noticed on academic vs "practicing" coders. Academics tend to build in layers, though not always, and "practicing" coders tend to build in pipes give or take. The layers approach might give you buildable code, but is hard to exercise and run. Both approaches can work though, especially if you build in executable chunks, but you have to focus on the smallest chunk you can actually run.

I'd argue the opposite. Nora's approach demonstrates that simple ideas work great for getting half of the problem done, but can make it impossible to finish the second half.

Reply on news.ycombinator.com