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

111–120 of 193 posts

Re: Crafting Interpreters

#111

Post by BoiledCabbage »

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.

Just to be safe, make sure to also copy the url into a note app, or some other location where you'll never look at it again.

Re: Crafting Interpreters

#112

Post by lolinder »

dils wrote: post #97
IAmLiterallyAB wrote: post #22

Planning to read this soon. Anyone got any other compiler book recommendations? Preferably modern (I've heard the dragon book is out of date)

"Writing An Interpreter In Go"[1] is also pretty good. I read it after finishing crafting interpreters. [1] https://interpreterbook.com/

Does it provide information or techniques that aren't already covered by Crafting Interpreters, or was it more of a refresher?

Re: Crafting Interpreters

#113

Post by blackerby »

phyrex wrote: post #110
sva_ wrote: post #91

Earlier quoted context omitted.

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

Why not buy an copy and put it on your to-read shelf for the next couple of months?

Months? How about years? And then start it, step away for a year, come back and start it again, then step away for a year, come back and … ?

Re: Crafting Interpreters

#114

Post by liamilan »

news_to_me wrote: post #26
liamilan wrote: post #21

Read Crafting Interpreters when building Crumb ( https://github.com/liam-ilan/crumb ). It was indispensable, especially the sections on scope and local variables. The balance between technical implementation and conceptual insights is super helpful, especially when trying to go off of the book’s set path. It’s inspiring to see technical writing done like this. As an aspiring engineer, this sets a really high standard…

This looks cool! How did you decide on what data types to include?

It was my first time making a language, so I built into the language whatever was needed to build something cool with Crumb.

Wanted first class functions to simplify the parse step (they can be treated like any other value), but I needed a different mechanism to invoke “native code” vs user-defined methods, so there’s two different types for that.

Needed some kind of compound data type, but I didn’t want to deal with side effects from pass by reference, so Crumb implements lists, but they are always pass by value :)

P.s. theres some pretty neat stuff build with Crumb at https://github.com/topics/crumb if anyone’s interested!

Re: Crafting Interpreters

#115

Post by munificent »

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 made the book much longer and more tedious.

Balancing thoroughness and brevity is always a challenge when writing.

The code is compilable at the end of every chapter and usually compilable at the end of every heading within a chapter. One thing I could have done that I didn't would be to place some visual markers in the book whenever you reach a point where things should be compilable. I'll keep that in mind if I write a third book.

Re: Crafting Interpreters

#116

Post by munificent »

shortercode wrote: post #71
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…

This book is intended to be a cover to cover job. I tackled it about 2 or 3 chapters at a time while building alongside. But after the midway point where it swaps to a C based byte code compiler I just read it instead. There are books like the dragon book which cover PL design in a more reference book style. But I don’t recommend them. If you’re looking for a lighter alternative then “writing an Interpreter in Go” is…

> Also Bob Nystrum has some other good material on his blog, and a chapter in game programming patterns about PL stuff.

Links:

https://journal.stuffwithstuff.com/

https://gameprogrammingpatterns.com/bytecode.html

Re: Crafting Interpreters

#117

Post by munificent »

xigoi wrote: post #56

Does anyone know of a good resoucce for creating a statically typed language with stuff like parametric polymorphism and basic type inference?

People have asked me to write something like this many times and one of the main reasons I haven't is because it's so open-ended.

With Crafting Interpreters, I felt like there was a reasonably small self-contained language I could come up with that covered almost all of the concepts I wanted to teach: variable scope, functions, closures, classes and dynamic dispatch, control flow, etc.

With type systems, there are a lot of forks in the design space and no clear "best" path:

* Does the language have subtyping or not?

* Are generics erased or reified?

* Is generic code specialized at compile time or not?

* Is type inference local or Hindley-Milner?

Any choice I make here would miss out on a lot of important material from the unchosen branch and disappoint readers who wanted me to take the other path.

Maybe the right answer is a broader survey-style book that tries to cover a bunch of different options (like Types and Programming Languages). But then you lose the fun of building one coherent thing.

Re: Crafting Interpreters

#118

Post by munificent »

cageface wrote: post #9

The author is one of the lead developers for Dart, which has evolved over time into a pretty nice language.

I should clarify that I've been an engineer on the Dart team for a long time, but I wasn't one of the original designers of the language. (If I had been, the language would be pretty different.)

I am on the language team now, but I'm just one of the team members and not a lead. The Dart team is really fantastic. Every day I'm grateful I get to work with such a good group of people.

Re: Crafting Interpreters

#119

Post by munificent »

eredengrin wrote: post #53
bmoxb wrote: post #34

Earlier quoted context omitted.

I think Engineering a Compiler is a great next step after Crafting Interpreters. It's both easier to get into (in terms of writing style and structure) and, as you say, generally more practical than the Dragon Book.

Do you have any thoughts about how to read some of the next step books like Engineering a Compiler/Dragon Book? I don't normally read large technical books end to end so I'm curious how others approach it. I am going through Crafting Interpreters right now and I like how it has well defined checkpoints that help me know that I can move on when I understand the current material. I skimmed Engineering a Compiler and it…

I think everyone has to pick a strategy for consuming material that works best for their brain. For me, when I read textbooks, I tend to read them front to back. Only a fraction of it sticks on the first read through, but I accept that. I've tried to go really slow and do all of the exercises to make it all stick, but I usually just run out of steam and give up. I'd rather just get through the whole thing.

Then, in the future, when I find myself needing some concept from the book, I usually remember at least that it is in the book. Then I go back and read that part more carefully. Now that it's relevant to a real problem I have, I tend to remember it much better after the second read through.

Re: Crafting Interpreters

#120

Post by munificent »

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.
Post reply on HN