[jcdavis]

Fun writeup. When I went through and implement the book in rust (https://github.com/jcdavis/rulox), I just used Rc and never really solved the cycle issue.

I'll +1 and say I highly recommend going through Crafting Interpreters, particularly as a way of building non-trivial programs in languages you are less familiar with - If you just follow the java/C example you are tempted to lean into copy/pasting the samples, but figuring things out in other languages is a great experience.

I spent a longass time tracking down an issue with how the reference interpreter implementation defines tokens: https://github.com/munificent/craftinginterpreters/issues/11... which was frustrating but good debugging practice.

[lawn]

> If you just follow the java/C example you are tempted to lean into copy/pasting the samples, but figuring things out in other languages is a great experience.

I'll echo this recommendation.

I haven't gone through Crafting Interpreters yet (it's on the bookshelf) but I did go through a big chunk of Building Git and instead of Ruby I did it in Rust, to get back into the language and go a little deeper.

It was really great and it gave me a lot more than if I'd just copy paste the code as you say.

[ghosty141]

My only issue with Crafting Interpreters is that it relies too much on writing code and then explaining it instead of getting the concepts across first and then providing the code. Another thing I disliked was some code was structured in a way that it would go well with concepts that came further down the implementation which can lead to confusion since it seems overcomplicated/overabstracted at first.

[munificent]

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.

[liveranga]

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.

[munificent]

Thank you! :D

[ghosty141]

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.

[ConcurrentCrab]

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.

[scott_s]

I love the code-first approach. It was a revelation to me when I first read Mark Pilgrim's Dive Into Python (https://diveintopython3.net/).

[grumpyprole]

My minor nit pick is that it uses mostly the Java language to implement a Java-like language. What have we gained? Surely something Python-like in C would be more rewarding, one would be gaining a level of abstraction.

[munificent]

> Surely something Python-like in C would be more rewarding, one would be gaining a level of abstraction.

That's the second half of the book.

[grumpyprole]

My apologies, that does indeed seem like a reasonable way of doing it.

[munificent]

Also, I should note that even in the first half of the book, the language isn't Java-like. It has Java-ish syntax, but the semantics are much closer to JavaScript/Python/Lua.

In the first half, what we gain from implementing it in Java is mostly the garbage collector. The rest of the static and runtime semantics basically have to be implemented from scratch on top of the JVM.

[grumpyprole]

There is significance coverage of OOP features, hence my Java-like comment. I would have personally left OOP out for a beginner book, it isn't really fundamental. Another advantage to using Java in the first half, could be to use Java closures to implement Lox closures.

[Dowwie]

did you not want anyone to ever find rulox on github? it has no descriptive information about it in the repo