Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crafting Interpreters: A Review

chidiwilliams.com

Post reply on HN
Print view View original

131–140 of 155 posts

Re: Crafting Interpreters: A Review

#131

Post by efvincent »

runevault wrote: post #100
bow_ wrote: 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…

See to me Java was an advantage because it ensured I would do part 1 in Not Java (in my case c#). Mind you c# is great because it is similar enough you can follow along while also being different enough that you still are forced to engage and think. At some point I want to redo part 1 in F# to REALLY push myself (and also force me to better engage with F#).

I did the first part in F#, and rather than translating Java to F#, I looked at what the author was trying to accomplish in each step, and did something functionally equivalent in idiomatic F#. That was fun & challenging.

haven't tackled the second part, I'm currently down the rabbit hole with Samuel Mimram's Program = Proof, which I'm just loving and the first book I've seen that focuses on the Curry Howard Isomorphism, covering essential logic, lambda calculus, type theory, and Agda... so good.

Re: Crafting Interpreters: A Review

#133

Post by bow_ »

heavyset_go wrote: post #104
bow_ wrote: 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.

Not really (for the first part at least, am not yet finished with the second part). I did deviate a little bit with my Rust implementation.

This was my goal anyway: implement Lox differently. Off the top of my head:

* I used ADTs to encapsulate error types and states as much as possible, this lead to heavy use of enums and pattern matching. * I implemented the `Environment` as an immutable, explicitly passed value. This was a little challenging at first, but overall quite satisfying to do.

Re: Crafting Interpreters: A Review

#134

Post by dunefox »

throwaway9032 wrote: post #117
rightbyte wrote: post #92

Earlier quoted context omitted.

> 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 fun…

I have the same opinion about Java and I hesitated as well before starting to read the book, so I'll use either Kotlin or common lisp.

Re: Crafting Interpreters: A Review

#135

Post by jesselawson »

mhh__ wrote: post #123

I think this book is ever so slightly overrated when it comes to actually implementing programming languages, but it contains such a nice introduction to parsing that I have for years been using it as my goto "You're not ready yet, read this" book when it comes go guiding people going down the dark unhappy path of working on language implementations.

PLT and implementing languages is something that's always fascinated me, so I enjoy hearing everyone's experiences in this domain. What makes you call it a "dark unhappy path"?

Re: Crafting Interpreters: A Review

#136

Post by mhh__ »

jesselawson wrote: post #135
mhh__ wrote: post #123

I think this book is ever so slightly overrated when it comes to actually implementing programming languages, but it contains such a nice introduction to parsing that I have for years been using it as my goto "You're not ready yet, read this" book when it comes go guiding people going down the dark unhappy path of working on language implementations.

PLT and implementing languages is something that's always fascinated me, so I enjoy hearing everyone's experiences in this domain. What makes you call it a "dark unhappy path"?

I was being sarcastic but also noting that 85% of the work is not in a book

Re: Crafting Interpreters: A Review

#137

Post by michael-go »

munificent wrote: post #48

Thank you for the excellent review! Also, I'll second the comments here: The design of your blog is beautiful.

Dear Bob, in case it helps FYI both the book's website http://craftinginterpreters.com/ and your blog https://journal.stuffwithstuff.com/ seem down right now.

And if anyone was curious like me to see the book's website, here is a archive link: https://web.archive.org/web/20220616005500/http://www.crafti...

Re: Crafting Interpreters: A Review

#138

Post by RheingoldRiver »

thundergolfer wrote: post #111
RheingoldRiver wrote: post #61

Earlier quoted context omitted.

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.

That's great to hear, thanks for the response! That sounds about as far as I got, so I think probably I was closer to 200 pages, not 300. It was just so incredibly boring. I was making it through maybe 4 pages a day if I was lucky. And all the material was so similar, it wasn't like you got through one part and then built upon it to something very different; it was more of the same with only a small difference. So no new-topic-energy-burst at the start of a new section.

Re: Crafting Interpreters: A Review

#139

Post by Measter »

runevault wrote: post #102
MatheusRich wrote: post #16

Earlier quoted context omitted.

The way that worked better for me was doing the book in a different language (I did it in Crystal and Rust). I had to fully understand the intent being every code example so I could translate it correctly. This adds another layer of difficulty, depending on how comfortable you are with Java and the language of your choice, but it was the way that worked better for me. I truly felt that I created a language, not just…

Question for you on Rust for part 2. Did you skip the data structure implementations part, did you use unsafe, or did you do shenanigans like Ids instead of pointers with backing vecs to handle them?

I also used Rust, though I only went up to chapter 21 in Part 2. I completely skipped the basic data structure implementations. I had no interest in implementing basic stuff like vectors and hashmaps, because it's not relevant to the problem.

I did go the ID route instead of pointers, because I didn't like the idea of shotgunning the heap with my AST, so I put the actual statements/expressions in vectors and everything else uses indices inside opaque ID types.

For fun, I did also start on doing compiler for part 2 based on the AST from part 1, though as I say, I didn't get far. I got distracted with a static, stack-based, natively compiled language instead.

Re: Crafting Interpreters: A Review

#140

Post by Sakos »

bow_ wrote: 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…

I wish people would be less opinionated about things like this. I've completed exercises for books or courses in C, C++, Lisp, Scheme, Go, Python, Javascript, Ruby, Rust, Java, Scala, Clojure, Prolog, Assembly, etc. It's not a big deal. Nobody is telling anybody they have to then program in that language for the rest of their lives. Be open to new experiences. Java really isn't difficult or alien or bad enough to complain that it's the wrong language and expecting book x to be in your preferred language z when there are dozens one could choose is so...closed-minded.
Post reply on HN