FWIW, a large chunk of the dragon book is about lexers and parsers, but from an automata theory perspective, where rather than creating a compiler, you're creating a compiler compiler, like lex for DFAs creating token streams from character streams, and yacc for PDAs creating trees from token streams.

But such detailed info isn't necessary even to write a compiler front end. It's good that the treatment exists, and that it's in the dragon book, but it's not what you need, even for parsing.

Perhaps you are implying the Dragon Book is not needed for people who will use tools like lex and yacc to generate it.

While that is true, the Dragon Book gives real insight into how a compiler really works and how to code one from scratch. If someone is only interested in getting a very basic compiler up and running quickly and not interested in understanding how to really make one, a simple tutorial for yacc should suffice.

If you're really making a compiler, it's unlikely you'll use a parser generator. Most production compilers use hand-written parsers for a variety of reasons: speed (e.g. folding more logical passes over the AST into the AST construction in the parser), semantic resolution of grammatical ambiguities, flexibility for compatibility (e.g. toggling different syntax rules dynamically), etc.

My comment wasn't about the article's point (which I thought it is valid), but about one idea that keeps getting rehashed ... i.e. if you want to learn about real compilers, you should read the Dragon Book.

> If modern languages are more than a compiler, that does not denies the ability of the book to cover how to write a compiler.

True, but the best way IMHO to learn about compilers is to start more lightly and then to read lots of source-code.