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

Crafting Interpreters

craftinginterpreters.com

Post reply on HN
Print view View original

131–140 of 193 posts

Re: Crafting Interpreters

#131

Post by fuzztester »

PhilipRoman wrote: post #121
fooker wrote: post #76

This book should be the second or maybe third step of your journey into PL compilers. The first step is to write an interpreter yourself, for a simple language you create, without knowing anything about interpreters or language design. The second step is to rewrite it, and make less mistakes! :) If you don't do this, you are never going to appreciate the nuances of this topic. And you are going to skip over concepts…

That brings back some memories... Having just started learning Java I wanted to create my own language. It wasn't that bad, I even managed to implement an operator precedence algorithm without looking it up. It worked by scanning the list of tokens and each time finding the highest priority subexpression. There was no recursion involved, just good old manual pushing and popping on a stack. The problem was that I didn…

what do you mean by some concepts not being nestable?

Re: Crafting Interpreters

#132

Post by fuzztester »

sva_ wrote: post #91
chris37879 wrote: post #8

I feel like this is a book most programmers should work through at some point or another. Doing so made me really appreciate just what's going on inside a compiler / language toolkit. It's also one of the most well written technical guides I've ever followed, it really helped me internalize the concepts, and they are useful all over the place, not just in compilers.

This comment sold me. Gonna keep this as an inactive tab for the next couple months.

Redirect it to /dev/null, that way you'll never see it again, so won't feel guilty:

$ cat this >/dev/null

Bonus points for redirecting standard error to standard output:

$ cat this >/dev/null 2>&1

Now no one will hear the screams ...

Re: Crafting Interpreters

#133

Post by purplerabbit »

munificent wrote: post #120

Author here. Seeing all of the positive comments about my book is really warming my heart. I appreciate everyone and I'm glad so many people have enjoyed the book. I put a ton of time and love into it and it's gratifying to see it had the effect I'd hoped for.

Self-taught sweng here. (And late self-taught -- didn't really start learning programming until age 21.) Early in my first job, I was asked to design a simple query language and create an interpreter for it. I had absolutely no idea what was involved in interpreters.

I found your book online (it was less complete back then -- this was 2017), and in 3 or 4 days I had a working prototype. In another week or two, I had a working product. Thank you so much for creating this resource -- learning from it and leveraging it gave me a huge confidence boost, and was super interesting and fun. One of the very best resources I've come across. I still reference that project as one of my very favorite I've ever worked on. Best wishes

Re: Crafting Interpreters

#135

Post by keoghpe »

munificent wrote: post #120

Author here. Seeing all of the positive comments about my book is really warming my heart. I appreciate everyone and I'm glad so many people have enjoyed the book. I put a ton of time and love into it and it's gratifying to see it had the effect I'd hoped for.

I LOVE this book. I have been dipping in and out the last few months implementing Lox in Rust.

It’s so well written, full of personality and beautifully illustrated - for me this book is a 10 and the bar I’d use to judge other programming books.

Re: Crafting Interpreters

#136

Post by LordN00b »

munificent wrote: post #115
lifeinthevoid wrote: post #98

What bothered me a little bit while following the book was that copying the code doesn’t result in compilable code all the time because there is code missing that is only introduced later. I get why the author chose to follow this path, but I’m from the club that every commit should compile and was annoyed a bit by that.

It's hard to have the code compile after literally every single snippet. Sometimes, we need to change the signature of a function that already exists and is called, so there's going to be at least two snippets you'll have to apply before you're back to a working state. It probably would have been possible to make this work by introducing temporary scaffolding code which gets removed shortly after, but it would have m…

That had better be "when I write a third book" Bob, not "if". It's not just the technical content (Which is excellent), but your ability to convey and entertain that helped create such a classic book.

So if you do get a spare couple of thousand free hours, please ignore the pull of family, the economic safety of work and plunge head first into another oversized computer engineering project. You may now take my money.

Re: Crafting Interpreters

#137

Post by [deleted] »

Arisaka1 wrote: post #66

Curious question from someone new to the programming field who lacks a formal CS background: How are books like this one are meant to be consumed? Do you read it cover to cover as you code along with the author in a way YouTube tutorials work? The main reason for asking is, I don't know if I'm lacking in natural gifts (really likely) but I can't seem to retain knowledge like that. It feels nice to onboard myself to a…

[deleted]

Re: Crafting Interpreters

#138

Post by munificent »

WJW wrote: post #124
munificent wrote: post #120

Author here. Seeing all of the positive comments about my book is really warming my heart. I appreciate everyone and I'm glad so many people have enjoyed the book. I put a ton of time and love into it and it's gratifying to see it had the effect I'd hoped for.

Thank you for writing the book! I'm currently almost done with the first part (doing it in Haskell because why not) and every chapter I encounter situations where my "clever hack" turns out not to be so clever in the light of later requirements. It's been great fun so far. Have you considered writing up a follow-up book doing (say) a compiler or a JIT or something for Lox? PS: the lexical analygator is the best and h…

Yes, people have definitely asked for a follow-up on compilers and/or static types. There's a little context here:

https://news.ycombinator.com/item?id=40956138

I'm not sure if I'm the best person to write a compiler book, or, at least, not yet. I've written a lot of language front ends and interpreters, but I don't have much experience targeting native code. It's something I've wanted to do for a long time, but haven't made the time to make it happen.

Static types are also hard for the reasons the linked comment talks about.

I still think about it sometimes, but writing a book is a lot of work and I've been enjoying not writing a book for the past couple of years. :)

Re: Crafting Interpreters

#139

Post by turndown »

fuzztester wrote: post #123
chris37879 wrote: post #8

I feel like this is a book most programmers should work through at some point or another. Doing so made me really appreciate just what's going on inside a compiler / language toolkit. It's also one of the most well written technical guides I've ever followed, it really helped me internalize the concepts, and they are useful all over the place, not just in compilers.

>really helped me internalize the concepts, and they are useful all over the place, not just in compilers. Which are some of those places? Parsing data formats could be one, I guess.

IMO compilers make you a lot more mature in recursive algorithms and trees, and then after that much more conscious about what exactly the code you write resolves to in terms of that languages semantics. Learning how closures work(variable capture and having to traverse the scope stack to find bound variables) is also a positive.

Re: Crafting Interpreters

#140

Post by chasil »

nicoburns wrote: post #37
gavinhoward wrote: post #11

Earlier quoted context omitted.

As the author of a POSIX standard utility, I would advise you to only reach for such utilities when portability is the most important thing. POSIX utilities are not great. Lex and Yacc included.

Are POSIX utilities even portable? They tend to have poor windows support. And they also tend to target C, which has a high ceiling for portability, but also a high bar for making things portable (whereas more modern languages are often just portable by default). My take on POSIX utilities would be only to use them on Linux platforms where they effectively form a "native" part of the platform.

The NT kernel was created with a POSIX layer (along with os/2).

https://en.m.wikipedia.org/wiki/Microsoft_POSIX_subsystem

Microsoft had previously been the largest AT&T UNIX licensee with Xenix sales on the TRS-80 model 2, so they were familiar with the need.

Post reply on HN