Ask HN: Similar books to “Raytracing in one Weekend”? I really liked the "Raytracing in one Weekend" Series [0], in terms of: explaining a complicated concept by programming a toy implementation of the thing itself and afterwards one is left with more knowledge and something to "show". Does someone know similar series on other subjects than raytracing? I know there is the Advent of Code, but that's more like solving a puzzle. |
They are surprisingly alike. Mine takes you through two complete implementations of the same language: first as a tree-walk interpreter and then as a bytecode compiler. His first book does the former and his second book does the latter.
Both are written in an informal friendly style and focus on working code. If you like one, you'll probably like the latter.
Mine uses Java for the first language and C for the second. Thorsten's books use Go for both. I think mine has more background information, theory, and historical context. His will get you to a working interpreter with less prose to wade through.
I think it's mostly a question of style and preference. I'd dip into the first chapter of each and see which resonates with you.
"Build your own X" - "This repository is a compilation of well-written, step-by-step guides for re-creating our favorite technologies from scratch." [0]
[0]: https://gamephysicsweekend.github.io/
[1]: https://matthias-research.github.io/pages/tenMinutePhysics/
I built an educational KV store to teach someone to write a database from scratch. I have set up this project in TDD fashion with the tests. So, you start with simple functions, pass the tests, and the difficulty level goes up. There are hints if you get stuck. When all the tests pass, you would have written a persistent key-value store in the end.
It's about 2D programmatic raster graphics.
https://www.pearson.com/us/higher-education/series/Sams-Teac...
https://www.amazon.de/Crafting-Interpreters-Paperback-BOB/dp...
https://www.amazon.de/Crafting-Interpreters-Tracy-Shep/dp/B0...
https://www.amazon.de/Crafting-Interpreters-Steven-Billups/d...
Have you already tried getting Amazon to remove them and failed?
In general, customers seem to be pretty good at distinguishing garbage on Amazon from the real deal, and my actual listing has enough reviews that it clearly stannds out as the one they want.
Thanks for letting me know.
Unsurprisingly my family asked what I wanted for Christmas and I put both your book and Thorstens on my list to reread .
I have been curious. Why the choice of java as introductory level?
Maybe I’ve been lucky to choose my own tools over the years. But I still get hung up on this. It’s just that Java is so longform.
I’m not sure I ever really wrote a sort in it, without cheating. Besides showing off that I could, I probably installed groovy or later scala, mostly.
So heh. I had a pleasant headfake in “Crafting Interpreters” when it was revealed that the JVM machinery wasn’t going to get anyone the full distance.
Java just feels backwards, as the low-level code is simpler and smaller. Why is Java still seen as more accessible than [anything else]?
Is OOPs curriculum still that prevalent?
Or. Pointers? Pointers took me a long time, even after I got them. Is it pointers?
It was a hard choice. I wanted a language that was:
1. Fairly high level with garbage colleciton so users didn't have to worry about pointers and stuff while they were trying to learn basic concepts.
2. Object-oriented, since that's familiar territory for many programmers and because I wanted to show some techniques around working with programming languages in an object-oriented language, like the visitor pattern.
3. Widely known and not mostly confined to a single platform or domain.
4. Statically typed, since I think it makes it much easier to see what types are flowing through the code when it's on paper and you don't have a debugger to help you.
There isn't much in the intersection of that set. Functional languages like SML and Haskell are great for writing compilers and interpreters, but now readers have to learn two things at the same time. C++ is a reasonable widely known typed OOP language, but is a nightmare of complexity. JavaScript is a good OOP linqua franca but the lack of types is a drag. TypeScript is maybe a good choice, but it's type system is so complex and JavaScript has so much weird baggage that I didn't want to go there. C#, Swift, and Kotlin are all nice languages but hew mostly to specific platforms.
Java was the least bad lingua franca I could find. I also don't mind it as a language.
> It’s just that Java is so longform.
My experience is that Java isn't particularly verbose as long as you don't program in a 90's Enterprise Java style.
> as the low-level code is simpler and smaller.
The C bytecode VM is quite compact, but it is so because it deliberately discards a bunch of things like an AST, simple environment representation, or separate resolution pass. It is designed to be implemented in C.
But I also want to teach users those other concepts. If I'd written the tree-walk interpreter that you do first also in C, it would end up a huge sprawling C program. Just dealing with allocating and freeing the AST nodes at the right time would have been miserable.
Not to mention, it means you would have to implement a garbage collector very early on since Lox relies on it but C doesn't have it.
I like it, you called my cohort out on being jaded by the developer experience of J2EE. I will revisit that outdated bias.