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

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

[Dowwie]

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