91–100 of 193 posts
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.
The author is one of the lead developers for Dart, which has evolved over time into a pretty nice language.
Earlier quoted context omitted.
This looks cool! How did you decide on what data types to include?
Personal choice, is what I'd say. You can get a lot of mileage out of implementing a dynamic language with NaN boxing[1]. It really depends on the kind of language you're trying to build an interpreter for, and what purpose it could serve. For dynamic languages, I'd say looking at the core types of Erlang is a great place to start (Integers, Symbols, Functions, etc.). For a statically typed language things get more c…
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…
For me, this book demystified these topics and allowed me to do your second and third step in the first place :) It's okay to not come up with/reinvent from first principles every technique on your own. It's normal to stand on the shoulders of giants.
Earlier quoted context omitted.
For me, this book demystified these topics and allowed me to do your second and third step in the first place :) It's okay to not come up with/reinvent from first principles every technique on your own. It's normal to stand on the shoulders of giants.
I'd think of it as riding a bike vs reading about riding a bike.
Earlier quoted context omitted.
For me, this book demystified these topics and allowed me to do your second and third step in the first place :) It's okay to not come up with/reinvent from first principles every technique on your own. It's normal to stand on the shoulders of giants.
I'd think of it as riding a bike vs reading about riding a bike.
You could go out and fall down a few times by yourself so it’s more fulfilling when you have instruction, but I wouldn’t say that’s the most efficient path.
Planning to read this soon. Anyone got any other compiler book recommendations? Preferably modern (I've heard the dragon book is out of date)
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…
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.