One of the biggest challenges with writing is linearizing: deciding what order to present the material so that it makes the most sense.
There's really no perfect solution. Some readers prefer bottom up where they are given individual pieces they can understand which then get composed. Others prefer top down where they are given the high level problem being solved in terms of intermediate steps which then get incrementally defined. Some want to see code first so that they have something concrete to hang concepts off of. Others want concepts first and then to see the code as an illustration of it.
This is made even harder with Crafting Interpreters because the book's central conceit is that every line of code in the interpreters is shown in the book. There's nothing left to the reader. And, also, the book tries to give the user a program they can compile and run as often as possible as they work through things.
I did the best I could, but there are definitely some places where it's really hard to figure out a good order. Sometimes the book explicitly says "sorry, this won't make sense but bear with me and we'll circle back".
Also, at the macro structure, the entire book is organized into two parts where the first one is higher-level and more concept driven and then the second part circles all the way back to build the entire language from scratch again but at a much lower level of abstraction.
I appreciate your feedback. It's a hard problem and a skill I'm always trying to improve.
Just to throw a positive word out there from one of the quiet majority of your readers, I think you absolutely nailed it with Crafting Interpreters.
It's by far the best introductory book on this topic I've come across yet. It's a fun read and completely demystifies the "magic" of how interpreters work.
Thanks for the answer! While my comment pointed out some issues I had, I do wanna make it clear that I still found it incredibly helpful and its probably the best practical introduction to the topic out there, so huge respect to you.
I think it also heavily depends on the reader. I also followed the book in a different lang than Java and only then I had the aforementioned problems.
As another one of your quiet readers, more specifically a soon-to-be uni grad who's at a crossroads about choosing to pursue my interests in either game engineering or systems engineering as a career path in this hellfire of a world we live in, I ADORE both your books. I think your writing consistently does an amazing job of motivating a practical yet elegant design from first principles.
And yeah, as someone who's trying to start writing a blog on ~technical topics, I get what you mean. Not every explanation can be linearized perfectly, because sometimes two concepts are coupled, motivating and influencing each other's design. Sometimes there are just, so to say, dependency cycles in the "knowledge graph". Can't turn that into a directed acyclic graph no matter how hard you try. The most prudent solution probably is just resolving the cycle iteratively by starting somewhere.
There's really no perfect solution. Some readers prefer bottom up where they are given individual pieces they can understand which then get composed. Others prefer top down where they are given the high level problem being solved in terms of intermediate steps which then get incrementally defined. Some want to see code first so that they have something concrete to hang concepts off of. Others want concepts first and then to see the code as an illustration of it.
This is made even harder with Crafting Interpreters because the book's central conceit is that every line of code in the interpreters is shown in the book. There's nothing left to the reader. And, also, the book tries to give the user a program they can compile and run as often as possible as they work through things.
I did the best I could, but there are definitely some places where it's really hard to figure out a good order. Sometimes the book explicitly says "sorry, this won't make sense but bear with me and we'll circle back".
Also, at the macro structure, the entire book is organized into two parts where the first one is higher-level and more concept driven and then the second part circles all the way back to build the entire language from scratch again but at a much lower level of abstraction.
I appreciate your feedback. It's a hard problem and a skill I'm always trying to improve.