While there are some good bits in the dragon book, some of its advice on the engineering of a compiler is pretty dated. For example, most of the parsing chapter(s) seem to have the notion that there is a single (global?) symbol table to which tokens and various other things refer, and which is gradually refined and updated throughout compilation. I think that may have been a widespread design once, but it's a bizarre anachronism now. Nowadays, information is often embedded directly into the AST, and compiler passes often create and destroy multiple ad-hoc symbol tables as necessary.

I would primarily trust the dragon book for its theoretical content, although even that likely no longer represents the state of the art. I'm not all that knowledgeable about the state of the art in parsers, but I know that compiler optimisations have certainly moved beyond what is in the dragon book.

In short, while the dragon book still contains useful information, I don't think its notion of how a compiler is constructed is close to how compilers are actually constructed today.

Thank you for the detailed reply. It's been years since my compilers class. I gather no one still uses lex and yacc either? To give you an idea how out of date I am in this area, when I took my compilers class we used http://www.cs.princeton.edu/~appel/modern/java/CUP/manual.ht... for much of the course work. And I've had surprisngly little need during my career for this subject area.

Lex and yacc are still frequently used (alongside similar tools like ANTLR). However, most production compilers use hand-written parsers because it permits better error messages and support for partial parses. The latter is useful for e.g. IDEs, where the code is often not entirely syntax-correct.

The dragon book is very informative but is harder to parse (ha) than many other compiler books. People should definitely read it, it just might be hard to read as a "My First Compiler" book.

I started reading it a while ago when I wanted to properly learn compilers. I actually thought it was very readable.

I must agree. It may be that you and I lean more toward the theoretical side and want more of a "grounds up" material (a chapter about transforming regexes to state machines? seriously?) than a "here's what to do to get it done by next thursday" book.

LOL. Anyone attempting to build a compiler by next thursday is in for a rude awakening.

In any case you're probably right, given that I like math and (so far) prefer algebra to analysis or applied mathematics.