I have seen a lot of people on the internet say that the dragon book is horrible book to learn compilers from.
well, I have read some of the second edition of the dragon book and I think it is a great book. The main criticism is that its too focused on parsing. Thats just like 5 chapters. I skipped these and went straight into the intermediate language, code generation, and optimizing chapters.
These chapters give a detailed account of things such as register allocation, instruction selection, and instruction scheduling. The optimizing chapters are also good.
im not claiming im an expert compiler person. I am not but compilers is something i want to learn and so i gave the dragon book a try and i really liked it.
more importantly the dragon book made me realize that compilers are mathematical systems in a way. the ast is tree and trees have mathematical properties but graphs are needed for register allocation, dataflow analysis for optimization. optimization is math problem.
So i think this book gave me a better understanding of the field and it made appreciate compilers.
i'd say if youre interested in compilers you can start with "essence of compilation" by dr. siek and get some experience writing compilers and then read the dragon book.
i just wanted to share my experience. i think the dragon book is a great book.
I've had good experiences using parser combinator libraries. They are straight-forward to use, and to write, and expressive. Beyond that, it's seeing how to breakdown a parsing problem into a grammar that I think is the main skill.
What else should I study besides the first 5 chapters of the 2nd edition of the dragon book?
Though mind you, not everyone shares my sentiment here, last time I wrote that people were adamant about hand-written parsers.
But you are probably not a compiler practitioner. Then I agree it is a good book to learn about compilers.
In fact SSA makes no constraints on the number of operands in an instruction/operation what so ever.
But the average programmer should just use a CSV parser lib, why reinvent the wheel? For custom tasks learning about ANTLR is much more productive (a good parser generator)
Just some clarification, it is not difficult to understand but difficult to build from scratch. I'm thinking maybe a book that asks me to build up BNF expressions for a series of grammars of gradually increasing complexity would be nice.
This [1] is a great tutorial to start with. Personally, I followed up with a standards compliant JSON parser of my own, in Python [2], and later ported it into a larger golang codebase. Practically building up multiple JSON parsers taught me to build my own DSL, using recursive descent parsing. My path admittedly is quite non-standard and idiosyncratic, but was way more fun than going through a textbook :)
[1]: https://www.booleanworld.com/building-recursive-descent-pars...
Came across it on HN but I have not read it though.
so a lot of people say a lot of things. i like chapters 1-5 just as much as the rest, btw. it's objectively a great book, written by objectively great developers and computer scientists.
is it the best to learn from today? who can say.
you might also say we should not start the education for structural engineering by studying the Brooklyn bridge either.
but, so here we are.
List please?
Since it's so old that blog post is dead now, here is an archive copy: https://web.archive.org/web/20180929002914/http://www.billth...
Sorry, title took me down a nostalgic trip.
