It’s inspiring to see technical writing done like this. As an aspiring engineer, this sets a really high standard to aim for - excellent resource.
Crafting Interpreters
21–30 of 193 posts
Re: Crafting Interpreters
#22Re: Crafting Interpreters
#23Planning to read this soon. Anyone got any other compiler book recommendations? Preferably modern (I've heard the dragon book is out of date)
The dragon book was my textbook in college, brings back memories, might be outdated but some concepts should still be useful.
Re: Crafting Interpreters
#24Planning to read this soon. Anyone got any other compiler book recommendations? Preferably modern (I've heard the dragon book is out of date)
AFAIK the problem with the dragon book is the same as with most academic compiler courses. It spends most of its time on the theory-heavy front-end (parsing) and much less on the back-end (code generation). Real-world compilers are very much the opposite.
Re: Crafting Interpreters
#25Planning to read this soon. Anyone got any other compiler book recommendations? Preferably modern (I've heard the dragon book is out of date)
Recent, that is the Racket version and the author has a Python version, too. Based on the nanopass compiler idea. It builds out the compilers over the course of the books.
Re: Crafting Interpreters
#26Read 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…
Re: Crafting Interpreters
#27I know this book has been praised before on HN, but I've been personally a bit disappointed. It's suitable for someone with no very little knowledge on the topic, but it doesn't really cover any advanced topic.
> It’s the book I wish I’d had when I first started getting into languages, and it’s the book I’ve been writing in my head for nearly a decade.
> In these pages, we will walk step-by-step through two complete interpreters for a full-featured language. I assume this is your first foray into languages, so I’ll cover each concept and line of code you need to build a complete, usable, fast language implementation.
> In order to cram two full implementations inside one book without it turning into a doorstop, this text is lighter on theory than others.
It sounds to me like you picked up the wrong book, skipped the introduction, and then were disappointed that it wasn't directed at you.
The good news is that it is free, so you aren't actually out anything but time.
Re: Crafting Interpreters
#28Is this book still relevant?
Unless compiler design radically changes it will likely remain a relevant book for a very very long time. Especially since Java-adjacent languages are likely to remain in vogue and the odds of us losing C as a major language in the next few decades is basically zero.
Re: Crafting Interpreters
#29The lex and yacc utilities are part of POSIX.2; is there any reason not to reach for them first? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/l... https://pubs.opengroup.org/onlinepubs/9699919799/utilities/y... All the POSIX.2 standards for shell utilities can be found here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ The original introduction to lex and yacc was in the book by Kernigan…
Re: Crafting Interpreters
#30The lex and yacc utilities are part of POSIX.2; is there any reason not to reach for them first? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/l... https://pubs.opengroup.org/onlinepubs/9699919799/utilities/y... All the POSIX.2 standards for shell utilities can be found here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ The original introduction to lex and yacc was in the book by Kernigan…
Does a single production compiler use lex and yacc to generate any part of their system, beyond maybe a first pass to test out syntax before it gets rewritten into a hand written parser/lexer? I'm not going to say none exist since I don't know literally every production compiler ever written, but I have never heard of one that used them for the final code.