Hacker News Reader

Comment by green_man_lives | Hacker News Reader

I have a question about the book. I haven't been able to ask anyone else because I don't know anyone else who is working through the book.

Is the first half of the book boring or is it just me?

I wasn't really expecting the scanner/lexer to be interesting, but the interpreter part as well feels like an absolute slog. I started with a lot of enthusiasm but just couldn't keep going after implementing functions. I downloaded someone else's JsLox implementation and was planning on just skipping to the VM part of the book and hopefully would find it more engaging.

I also am a pretty jr developer. I have about 5 years experience since I started learning to code so I just may not "get" it yet. But I found writing the interpreter to be incredibly boring.

View on HN

It's possible the subject itself is "boring", and I have found other compiler books to mostly be intolerable.

Crafting Interpreters, IMHO, is the most accessible book on the subject. If you didn't find the implementation of the first part exciting, I would suggest to probably ignore the book code after reading the text and implement it yourself, and later compare with the book implementation. I encountered several pleasent surprises using this approach.

Yeah I personally found the second half of the book much more interesting! My strategy was to read the first half of the book casually, but then actually implement the second half (in Rust, like the article here).

Compiler writing does involve a fair amount of tedium. I don't think it has anything to do with experience, either. It's why tools like Yacc, Lemon, or ANTLR exist.

May I suggest Rob Pike’s video on writing a lexer? It will make the task far more interesting

https://youtu.be/HxaD_trXwRE

Except where comparisons being made, the first and second halves are mostly independent. If the tree-walking interpreter might not be what you have hope for, you can, in principle, skip finishing it. The bytecode VM half is a re-implementation (in C instead of Java as the first half) and only the scanner/tokenizer has some inevitable redundancies in implementation. For me, who had less prior knowledge in interpreters, it is still good to have fully gone through both halves to relate to the comparisons and trade-offs of both implementations.

perhaps you had no motivation for writing an interpreter? almost all programming tasks that are of any interest require you to have some special problem to solve.

i really don't know how to describe this, but if you have no specific goal, you are not going to do, or learn how to do, anything. why do you deeply, deeply want to learn how to write an interpreter? what problem will writing an interpreter solve for you?

Nothing in particular other than knowledge that I can use across domains. I don't want to know how to write an interpreter per se, but I want to understand the steps from text to machine code.

I think it has already yielded benefits in my better understanding of environments and lexical scoping, grammars + LALR. It has just given me different conceptual tools that I can use to learn new concepts.

A concrete example was that I was playing around with a recursive prompt with ChatGPT the other day trying to figure out if I could get it to write a more specific version of a prompt I had given it and sort of bootstrap its way to a very specialized "train-of-thought". I was thinking about grammars and how recursive prompting is sort of like a meta-grammar. It's just a new way of thinking about things.

Could be worth a try. I didn't find the first half as boring as you did, but I did find the second part more fun.

One tip, copilot is absurdly good at giving you interpreter/compiler boilerplate. You can definitely use it to speed through the boring parts.

Reply on news.ycombinator.com