How does "Engineering a Compiler" (by Keith Cooper and Linda Torczon) compare to the Dragon Book (Principles of Compiler Design by Alfred Aho and Jeffery Ulman)?

The Hassaan Atif <hassaanatif@gmail.com>
Tue, 7 Sep 2021 06:16:03 -0700 (PDT)

          From comp.compilers

Related articles
| List of all articles for this month |

From: The Hassaan Atif <hassaanatif@gmail.com>
Newsgroups: comp.compilers
Date: Tue, 7 Sep 2021 06:16:03 -0700 (PDT)
Organization: Compilers Central
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="54375"; mail-complaints-to="abuse@iecc.com"
Keywords: books
Posted-Date: 07 Sep 2021 11:43:47 EDT

Hey everyone, I asked this question earlier on reddit, but for the diversity
in opinions, I am posting the same question here as this group is particularly
compiler-centric.
So I have been thoroughly and religiously studying Compilers for a couple of
months now. In addition, to the Dragon Book, I have been taking video lectures
and exploring through slides online that have been compiled (no pun intended)
by people that have worked with the compiler technology for years. So anyway,
I have familiarized myself with all the basics (Scanning, Parsing (including
generating parse trees and ASTs), and even code generation, as well). I have a
good understanding of the complex algorithms involved in some of these stages,
and I have a good intuition on the complexity involved in all this (in
particular, I understand what problems are undecidable for a programmer. What
are the pros and cons of different techniques and so on).


So anyway, one of the lecture series that I watched had taken upon
"Engineering a Compiler" as their reference book, and I have explored some
portion of this book (of course, I am still at the very beginning), and my
initial thoughts are:


- This book comes across as very beginner-friendly


- I like how it builds from the basics. So, for example, while constructing a
scanner, we get to see the application of finite-state automata in action. So
the book tells us how to go from a regular expression to non-deterministic
finite automata using Thompson's construction algorithm and how all this
process leads us to recognize words. We get to learn about this process within
the first 50 pages of the book. In contrast to this, the dragon book jumps
straight into the more complex stuff (such as writing context-free grammar,
building a syntax-directed translator, and some other notions from a parsing
point of view). In other words, it seems to skip a lot of stuff at the
beginning that should have been introduced before we had jumped into the more
complex stuff.


- As mentioned above, "Engineering a Compiler" takes a very
programming-oriented approach. It is easier to comprehend things from a coding
point of view, and it is convenient to map the theory into actual practice.


- The notion of "Classic Expression Grammar" is introduced in a very
beginner-friendly manner in that book.


Anyways, I am still in the process of learning and exploring as much as I can,
so I am not sure how much weight and value my opinion carries. I am reading up
on both texts. In my opinion, the Dragon Book is very detailed, in the sense
that each sentence can be a book on its own at times, but "Engineering a
compiler" seems more beginner-friendly. One more thing that I have heard
people say is that some of the optimization techniques presented in the dragon
book are a bit outdated, but I am still looking forward to reading about
that.


Anyways, these were just my two cents on both these books. Now, why do I ask
this question from you guys? I would love to get some insights from a
professional or someone more educated on this stuff. Also, if you find any
misconceptions in the above passage then feel free to correct me on that. I
come here to learn more.
[Aho and Ullman is very old, published in 1976. They updated it and
rotated authors, Aho, Sethi and Ullman in 1986, and Aho, Lam, and Sethi
in 2006. Everything in the 1976 edition is still true but we've
learned a lot about analysis and optimization since then, and hacks
needed to fit into 16-bit computers in 1976 don't matter any more.
=John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.