Live data from Hacker News

Crafting Interpreters: A Review

chidiwilliams.com

111–120 of 155 posts

Re: Crafting Interpreters: A Review

#111

Earlier quoted context omitted.

I got through all chapters in around 1.5 months, spending 50-60 hours[1]. I'd do solid 4-5 hour blocks on Saturdays and Sundays when I was most into it. I'm following teachyourselfcs.com[2], so I'm hoping to solidify the concepts the book intro'd by reimplementing the bytecode interpeter in Rust (rlox) and following Alex Aiken's lectures online. OP appears to have reimplemented Lox in Golang (glox) for reinforcement.…

Did you read Computer Systems: A Programmer's Perspective first? I read about 300 pages of it (maybe 200 only, I forget) and got _extremely_ bored. I want to read Crafting Interpreters but I'm concerned that Computer Systems is too much of a prerequisite.

I read the first 3 chapters and worked through the in-chapter exercises (not the end-of-chapter exercises). I think that’s about 150-200 pages.

Yeah it’s quite a slog. I think I averaged 10-20 min per page of progress. I intend to return and finish it but it will take me ages.

It’s not a prerequisite at all though. Crafting Interpreters is pretty high level, in comparison.

Re: Crafting Interpreters: A Review

#112

What other books are of the same caliber that HN would recommend?

The Nature of Code - Daniel Shiffman

I love this book.

https://natureofcode.com/

It's one of my all-time favorite books about programming, I keep coming back and re-reading parts of it.

The author does excellent programming education through fun videos.

https://shiffman.net/

Re: Crafting Interpreters: A Review

#114

What other books are of the same caliber that HN would recommend?

CODE: The Hidden Language of Computer Hardware and Software - Charles Petzold The Elements of Computing Systems - Noam Nisan, Shimon Schocken Operating Systems: Three Easy Pieces - Remzi H. Arpaci-Dusseau, Andrea C. Arpaci-Dusseau

Worth mentioning (I think it was elsewhere in the overall thread) CODE is getting a 2nd edition later this year. I've always meant to read the book but never did, so I'm planning on using the second edition as my excuse to finally do so.

Re: Crafting Interpreters: A Review

#115

Earlier quoted context omitted.

Bob, your continued love of synths gives me hope we will see you take a real leap of faith and give us a ‘Crafting Real-time Audio via custom digital Synthesizers’. I would genuinely love a beginner friendly guide to audio programming in the style you developed for Crafting Interpreters. Help me get my friends into digital instrument programming Bob, it’s not like it would take that long!

I'd be surprised if there isn't some beginner-friendly guide to audio programming, albeit not in the same author's style. Anyone have a favorite?

I really enjoyed "BasicSynth": https://basicsynth.com/

Re: Crafting Interpreters: A Review

#116

I'm in the middle of this book at the moment and I have mixed feelings on it. 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 re…

I sympathize with your criticisms about java because the language is... not my favorite. It would be helpful here to look at its choice as a result of Nystrom solving the intersection of multiple optimization problems: - Manual Memory Management Is Hard. Interpreters are complex pieces of software, you don't need another rabbit hole to dive into while you're learning your first parser. You don't need to agonize over…

That's a really good summary. I didn't pick C# in part because it feels more tied to Microsoft and Windows than I wanted the book's language to be. Java (to me at least) feels fairly platform and corporation independent.

If you would have prefered I pick Go, you'll definitely like Thorsten Ball's two books.

Choosing a language for books is really hard these days. There are so many choose from and most are quite large and complex, so it's hard to find a single language that is familiar to a large enough segment of the audience.

Re: Crafting Interpreters: A Review

#117
post #52

I hesitated a little bit before deciding to purchase and go through the book. Had already read many glowing reviews then, but was not sure if the choice of language (Java) for the first half of the book would be a hindrance (it's not the stack I am most familiar with). Decided to buy it anyway, primarily because the two implementations of the toy language piqued my interest (most other books only go through one imple…

> was not sure if the choice of language (Java) for the first half of the book would be a hindrance I think it is refreshing he uses a "boring" language.

Java is the opposite of boring. It lacks basic fundamentals such as algebraic data types and pattern matching. You will be kicking and screaming the whole ride.

A boring language would be a language where you aren't triggered/bothered by its basic ergonomics and hygiene. In Java, you must translate discrete variants into dogmatic OO paradigm instead of using language primitives.

Thanks to Java's poor design, it's fundamentally a hazard and a land mine thanks to null not being first class in type system. The use of null as a value inhabiting any type should result in a slap in the face upon opening a pull request (until Java adopts type-safe optionals like Kotlin)

P.S. Switch expressions and sealed interfaces aren't there yet, Kotlin and Scala are still the only options if you are imprisoned to JVM.

Re: Crafting Interpreters: A Review

#118
post #63
post #20

Earlier quoted context omitted.

There's also Thorsten Ball's Writing an Interpreter in Go[1] and Writing a Compiler in Go[2]. [1] https://interpreterbook.com/ [2] https://compilerbook.com/

Excellent book indeed. Note that Ball's interpreter uses Pratt parsing, which doesn't require you to delve into the theory of formal languages.

I've found Pratt parsing meshes rather well with formal grammars. Anything that is better described by an operator precedence table rather than BNF should be handled by the Pratt parser, rest can be done with recursive decent.

Re: Crafting Interpreters: A Review

#119
post #52

I hesitated a little bit before deciding to purchase and go through the book. Had already read many glowing reviews then, but was not sure if the choice of language (Java) for the first half of the book would be a hindrance (it's not the stack I am most familiar with). Decided to buy it anyway, primarily because the two implementations of the toy language piqued my interest (most other books only go through one imple…

Using Java was a poor choice (especially without the latest improvements such as records and switch expressions): * new books should use more modern popular languages to age well and to attract younger audience * on the JVM there are languages better suited for the topic (e.g. Scala by a large margin) * There's already the "Language Implementation Patterns" book ( https://www.amazon.com/Language-Implementation-Patter…

ANTLR may be used in big data query engines but I can’t think of a single language I’ve ever used that had a parser written with it. I know you can grab off the shelf parsers with antlr for a bunch of languages, but who cares?

And frankly, Scala’s build tool is way too slow and would be a slog to use for this book.

Re: Crafting Interpreters: A Review

#120
post #52

I hesitated a little bit before deciding to purchase and go through the book. Had already read many glowing reviews then, but was not sure if the choice of language (Java) for the first half of the book would be a hindrance (it's not the stack I am most familiar with). Decided to buy it anyway, primarily because the two implementations of the toy language piqued my interest (most other books only go through one imple…

Any trouble with the Rust implementation? I wanted to give the book a go using Rust, but have been sitting on it because I don't want to get halfway through it only to find that Rust's intentional design and limitations might make it difficult to build an interpreter via the assumptions in the book.

I've been loosely following the book with Rust, and no issues so far. Both the compiler and interpreter are implementable without much issues. You'll have to adapt a bit, but in general you can use the same methods.
Post reply on HN