by chidiw on 6/22/22, 1:36 PM with 153 comments
by bow_ on 6/22/22, 4:56 PM
Decided to buy it anyway, primarily because the two implementations of the toy language piqued my interest (most other books only go through one implementation).
Boy was I glad I did.
Writing is superb, end-of-chapter challenges are instructive, code samples are meticulously and beautifully done. Here and there I also encountered references to other languages (e.g. had a brief detour to Lua internals [1], thanks to a side note), which I have enjoyed too.
Went through the first half twice: first using Java as it is written and then secondly implemented the interpreter in Rust (my initial fear turned out to be unfounded). Currently going through the second half.
So if you're reading this, thank you, Bob :).
by Derbasti on 6/22/22, 3:29 PM
To me, it was a missing piece of the big puzzle of "how do computers work". I read many a book to answer this question, and came away with three books:
- CODE by Charles Petzold explains the CPU
- Operating Systems: Three Easy Pieces by Arpaci-Dusseau explain OSes
- Crafting Interpreters by Robert Nystrom explains programming languages
Masterfully done.
by hardwaregeek on 6/22/22, 4:58 PM
by alexobenauer on 6/22/22, 2:23 PM
Doing the tree-walk interpreter (the first “half” of the book) took two weekends, working much of the day on Saturdays and Sundays.
When I went through it, I built my interpreter in another language, and added other features as I went along. Both helped solidify the concepts. I often had to pull out my additional features as I learned better in subsequent chapters; getting to see the difference between my amateur approach versus the author’s experienced methods was quite helpful!
by lordleft on 6/22/22, 3:26 PM
The author has also kindly made a web version of his book freely available:
by d23 on 6/22/22, 2:11 PM
by recursivedoubts on 6/22/22, 2:22 PM
when i was given a compilers class to teach i wanted to teach hand-written recursive descent because it is simple, elegant and makes the recursive nature of grammars so readily apparent without hiding concepts behind obscure tools
i was despairing that there were no good books around on recursive descent, but stumbled on crafting interpreters before it was even released as a book and immediately structured my class around it
absolute life saver and my students all love it
cannot say enough good things about it!
by munificent on 6/22/22, 4:25 PM
Also, I'll second the comments here: The design of your blog is beautiful.
by chapliboy on 6/22/22, 2:00 PM
This is really useful in setting expectations.
by Noe2097 on 6/22/22, 2:42 PM
There exists various flavors of the book (in ML, Java, and C).
by wrp on 6/23/22, 1:06 AM
1. Peter John Brown. 1979. Writing Interactive Compilers and Interpreters.
2. Timothy Budd. 1987. A Little Smalltalk.
3. Ralph E. Griswold. 2000. The Icon Programming Language, 3e.
4. Pat Shaughnessy. 2013. Ruby Under a Microscope: An Illustrated Guide to Ruby Internals.
This is a new one I haven't read yet, but it looks very practical:
5. Clinton L. Jeffery. 2021. Build Your Own Programming Language: A Programmer's Guide to Designing Compilers, Interpreters, and DSLs for Solving Modern Computing Problems.
I don't know anything about this one, but people have told me they prefer the first edition:
6. Ronald Mak. 1991. Writing Compilers and Interpreters: An Applied Approach.
by collinvandyck76 on 6/22/22, 3:25 PM
by hyperzhi on 6/22/22, 2:06 PM
by vertexmachina on 6/22/22, 5:28 PM
It's definitely well-written and you can feel the love and care that went into producing it. But I think it would have been stronger had Nystrom skipped the Java version and spent those pages on theory instead before jumping into the C implementation. While going through the Java stuff (implementing in C# instead because I have an emetic reaction to Java) I found myself just wanting to hurry up and get to the good stuff in C. And I found the visitor pattern and code generation stuff to be a distraction.
The code can also be a bit hard to follow at times because he jumps around from file to file and function to function. He'll present a function that calls a function that doesn't exist yet, and then define the new function, etc. He does it that way because he wanted to ensure that every single line of code was present in the book (he wrote a tool to ensure that was the case), and it certainly helps if you're trying to copy his code verbatim, but not so much for high-level understanding. Maybe that's a failing on my part.
Finally I wish he had gone into more detail on how one might implement a register-based VM because they are faster and more interesting (to me) than a stack-based one.
by shaftoe444 on 6/22/22, 2:53 PM
by dingosity on 6/22/22, 2:23 PM
by nphard85 on 6/22/22, 3:56 PM
by cpard on 6/22/22, 2:56 PM
by geekraver on 6/23/22, 2:25 PM
https://www.wired.com/2013/01/comedy-in-the-hacker-world/amp
I was lucky enough to be working on the Dart team in Seattle at the time with Bob, who is one of the smartest, funniest and nicest people I have ever met (although the whole team was an exceptional bunch).
by mhh__ on 6/23/22, 1:53 AM
by twh270 on 6/22/22, 3:43 PM
by EamonnMR on 6/22/22, 11:20 PM
by MarquesMa on 6/22/22, 4:53 PM
But I think it could be more straight forward if the first interpreter didn't use Java, but a modern main stream language that can avoid code generation and Visitor Pattern. Those parts feels like unnecessary detour.
by xbar on 6/22/22, 4:11 PM
by ParallelThread on 6/22/22, 2:38 PM
by icholy on 6/23/22, 2:22 AM
by mengibar10 on 6/22/22, 4:13 PM
by sydthrowaway on 6/22/22, 6:15 PM