▲ 116 points
back
71 comments
> The Dragon Book covers everything you need to know to write a compiler.
No it doesn't because it only covers techniques you can use in implementing and optimizing old-school static languages.
But today a language is more than just the compiler, with modern VMs coming into play, and runtime optimizations aren't covered ... for instance if you want to implement a tracing JIT compiler, your only hope is to read the source-code of some available VM. Or if you want a precise garbage collector ... well, good luck with that.
That's one reason the implementations of dynamic languages are so shitty ... the effective techniques for doing it are yet to be explored / documented.
So if you want a book on implementing compilers, I recommend this one ... http://pragprog.com/titles/tpdsl/language-implementation-pat...
My problem with the Dragon Book is more fundamental: having once made a real effort to read it, almost cover to cover, I came away with a few hours less of my life remaining and some ideas about lexers and parsers and the like, but I still had absolutely no idea how to sit down and write a compiler. I don't understand why anyone thinks this is a good book.
There are introductory texts that might not cover the same amount of theory, but at least get you from nowhere to being able to write a basic compiler from start to finish. If you do want some serious theory, particularly on optimizations, then Muchnick blows the Dragon Book away. If you want to work with different kinds of programming language, notably functional programming with a lambda calculus foundation, then these ideas barely appear in the Dragon Book and again there are specialised texts that would serve you much better. What is the target audience for the Dragon Book actually meant to be?
The Dragon Book is supposed to be read by people taking a CS course on compilers, to fill in the gaps. I too don't believe it's a standalone work.
Well, when I wrote a compiler (on a team of 3) the dragon book (first edition) was very helpful, from lexers, parsers, to code generation. So we read it cover to cover (except for Jeanne, who got her PhD from Ullman and who wrote the LALR parser) and used it profusely.
As noted elsewhere in this thread, I think that, in contrast to the OPs article, everyone should read it or Hollub's excellent work that followed the Dragon book by a number of years.
So I would disagree with your opinion about this being a good book, but then I may have the advantage of having spent substantially more time with it.
Jack Crenshaw's book Let's Build a Compiler http://compilers.iecc.com/crenshaw/ is probably too far to the pragmatic end; it essentially walks you through the process of writing a recursive-descent compiler in Pascal for a Pascal-like language that generates code for the m68k. No separate parser and lexer as such, but he does teach you how to turn those kinds of ideas (regexes and EBNF equations) into code more-or-less directly in your head. In short, it was just about perfect for someone who wanted to whip up a nice little compiler for a foogol on a late-1980s DOS box without paying for or finding any tools beyond Turbo Pascal.
It's entirely possible to use the techniques in the book to, say, whip up a compiler in Ruby that turns an inconvenient data format into JSON. The real utility of doing this by hand in 2010 is, however, debatable.
I think a lot of dynamic language implementations suck because their authors haven't bothered to study Lisp implementations. The widely used implementations of Common Lisp and Scheme don't suck at all[0]. Of course, some implementors of other dynamic languages do seem to have studied Lisp implementations and it shows in the results. Lua doesn't suck at all.
[0] Ok, the multi-platform support of some of the CL implementations could be better.
I'd say they suck because the authors cared about specific issues other than making the implementation not suck (which I guess means fast performance performance?).
But how does lua bears lisp inheritance in its implementation? IIRC lua does not use pointer tagging which is a typical lispism, uses tables for everything, has no lists, and uses a different approach for implementing closures.
Are you thinking of LuaJIT(2) ?
notwithstanding the validity of your message, you are objecting to something that you did not quote.
If modern languages are more than a compiler, that does not denies the ability of the book to cover how to write a compiler.
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.
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.
I notice that Language Implementation Patterns was written by the Author of ANTLR. I've had terrible experiences trying to use ANTLR in practice, which kind of puts me off buying the book. Do examples in the book use ANTLR? Also, is there much point in getting the book if I already know about lexer and parser generators?
"Do examples in the book use ANTLR?"
Yes. The book is "saturated" with ANTLR. I wouldn't buy it if you don't like ANTLR. Also, (purely imho) it spends too much time on the front end (lexing/parsing) and not enough on the rest. I have yet to see good books (other than DCPL or L.I.S.P) which uses a simple concrete syntax (s-expressions say) and focuses on the rest of compiler building.
> I've had terrible experiences trying to use ANTLR in practice, which kind of puts me off buying the book.
Yes, but it explains the parsing techniques used by ANTLR, and for learning stuff it's quite OK. It uses ANTLR as a teaching tool, but you don't have to keep using it afterwards.
For writing simple parsers you don't even need to read a book ... just use a parser combinator based on PEGs, like http://wiki.github.com/sirthias/parboiled/ and you'll be fine.
If you want a general purpose language however, even if you use a tool like Parboiled, you'll need to know how its guts work. It is also a good idea for a compiler to be self-hosting, because it's more portable that way and the compiler's code itself is a good test for your language ... so you'll need to know how to implement a parser by hand.
Of course, after the parser is done you'll need to have an AST, and maybe you'll want to optimize it ... this book is thin on such details, but it's better to start somewhere and books like the Red Dragon are quite heavy and can put you off the target before writing a single line of code.
After using JAVACC for a couple of years I switched to ANTLR. I found it slightly harder to learn but easier to use than JAVACC.
This makes two JWZ references I've handed out today, but this is pretty relevant: http://www.jwz.org/doc/gc.html
Memorable quote:
"It's a common belief that garbage collection means inferior performance, because everyone who has gotten into programming in the last decade regards manual storage management as a fact of life, and totally discounts the effort and performance impact of doing everything by hand.
In a large application, a good garbage collector is more efficient than malloc/free. "
Its merits notwithstanding, I suspect the Dragon Book was at included at least partially as a dig at Jeff Atwood.
(Disclaimer: I haven't read it myself, and don't plan to. My reading stack is close to overflowing as it is.)
Couldn't disagree more about TAOCP. I haven't finished any of them, but I think they recommend themselves poorly as references and are brilliant front-to-back readers. Every time I make a couple hours for them, no matter where in which book I start, I learn something new. TAOCP is in that sense more like the Bible than the dictionary.
That the examples are in "assembly language" is a red herring, since the machine the book targets is deliberately simplified. The "assembly" is just a notation. The idea, which seems to be to make the examples as concrete as possible, is beginner-friendly --- as anyone who's been tripped up by mistakes and ambiguities in older Sedgewick books can attest.
Grab the fasciscle (sp?) 1 of Volume 4; the bitmanipulation stuff reads like poetry.
(stale) Soft copy: http://cs.utsa.edu/~wagner/knuth
fascicle
"I consider it amazing that some people do go cover to cover in my books. In most cases I know that people are going to pick and choose the parts that they like. But they know that if they dig further then they'll get something that has only one subset of jargon describing it instead of all different kinds of notations and terminology -- if I didn't write the books it would be much harder for people to find stuff out. That's what turns me on."
--Knuth, in Coders at Work
I agree. At first glance, their length makes it appear to be a reference work, but when you look at his writing style and the exercises at the end of each section, it seems quite clear that he intended otherwise.
That being said, I haven't finished the series.
"I've read all of these books myself, so I have no difficulty believing that many moderately competent programmers have read them as well."
What a strange thing to say.
I've read all of the books in the "Claim To Have Read" list and only a couple in the "Have Actually Read" list. So based on my experience I have no problem believing that programmers at least as dumb as me have read the same.
Another data point. Of the "actually read" list I'm at 6 of 10. Of the "claim to have read", I claim 3 of 5. So an identical portion of each group.
Another opinion. If you haven't read the Go4 patterns book, you don't deserve to call yourself a real software engineer -- and it's an eminently readable book, too. And if you haven't read the "The C++ Programming Language", you should not be behind the wheel of a C++ compiler. I haven't read Knuth nor the Algorithms book, but studied the topic extensively; you really need this kind of foundation to be a full-fledged software engineer.
This is an old post, and I've never quite agreed with it.
For one thing, I don't know how you can lump things like Head First Design Patterns or whatever the TDD one is in with things like Code Complete or Programming Pearls.
For another thing, I have read at least parts of all of the books that apparently programmers don't really read, and judging from the books on colleagues' desks (not the bookshelves) so have a lot of other people I've worked with. The same is certainly not true of the "books programmers do read" list.
I have never claimed I read "The C++ Programming Language" ;-)
After learning OOP with Smalltalk, it seemed a step in the wrong direction.
C is fine though. And TCPL is a fine book too.
I also never managed to finish "Code Complete".
To be fair, I also had exposure to Cincom's Mantis. That further spoiled me. To the point I still want a 3278 for my living room.
The books you end up reading are consequences of the steps you take in your career.
I don't understand why Mantis isn't better known in the programming/CS world. Then again, I'm also a former Cincomer.
I never heard of it, why not write about it?
Anyway, if this[0] page is related to your mantis, obscurity is surely connected to the usage of a <marquee> tag ;)
I have a hard time believing many people have read Code Complete cover to cover, unless perhaps they're older and it was a long time ago before that was much better to do. It's so dry that I can't get more than a couple of chapters without falling asleep.
Your comment illustrates a problem with the original submission: It's idiosyncratic. It says more about the writer than the subject.
The various books are really different, people's reading strategies are different, people's tastes are different. People who have been in the field longer tend to have read more books. Also, whether or not you have "finished" a book tends to be irrelevant in nonfiction. If you can't get through Code Complete in one sitting, try reading it in bits and pieces - it shows signs of having been designed for that. If you haven't "finished" TAoCP... you and Knuth have something in common.
(For the record, I have read all of Code Complete at none time or another, but I've barely touched TAoCP. Which is not a problem. It is good to have things to look forward to. As someone once said: What's the point of having a collection of nothing but things you have already read?)
I'm older, it was a long time ago, and I read it cover to cover. The weird thing is I really liked it when I read it, but I'm not sure I could finish it today.
A month or two during the daily 20 minute commute on the train will do it
You can safely add "Goedel, Escher and Bach" to that list.
The author's point, summarized, is "Don't recommend books to new programmers that you haven't read yourself". My recommendation is to go read those books that you recommend. Even if you read them after you recommend them.
Did you ever see that stack overflow post which says in dozens of ways that you can't fully take apart (parse) HTML with regular expressions? If not, you should. It is informative and entertaining.
Don't you think that if those who attempt to separate HTML with regular expressions had read and understood either of the dragon books that they would even try the task with RE? I don't. Once you put something like parsing and code generation in your personal toolbox, you would be surprised at the tasks before you that are a lot less intimidating.
I agree with Thomas about TAOCP. I'll give you a particular example. Volume 2, "Seminumerical algorithms" has a description of how to do long division. It turns out that we needed to do that when shipping a C compiler for 8086/80286 targets that didn't have an '87. And there is a reference to it in Coders at Work about that particular rare case that turns up only seldom.
Have you read the chapter on random number generation? How he made up this convoluted procedure to use one number to go to a page in a reference book to pick another number, and eventually ended up with a cycle of numbers that was disasterously small? It is fun.
And having an original edition and the recently issued boxed set, it is fun to see some of the problems change from HM 50 to something else. For example Fermats Last Theorem.
The lesson from that is repeated in people writing and using crypto. Just ask Tom.
While there are downsides to a university education, as often pointed out here on hacker news, the experience take you, if you are willing, to places that you wouldn't have on your own.
Similarly, the problem in front of you might not automatically make you run to get the dragon book or the others on the list, perhaps a friend can twist your arm to get you to read it.
You don't always know what you need ahead of time. There is a common word for that here, I think.
It doesn't matter if you don't read dense programming books straight through or do all the exercises, as long as you are using them. If you make almost any effort to flip through looking for something new to chew on, you're usually rewarded pretty quickly with the listed selections, and that's why they're good books. The practice aspect is a good pursuit as well, but not intrinsic to the value of the book.
Edit: And I should add - that's why they're still valuable even in the Internet era. The "pure compilation of awesome content" aspect is a compelling reason to have them.
TC++PL is written to be read cover to cover, with the exception of Part III (The Standard Library,) and even in that part, each chapter is written to be read beginning to end. C++ is a complicated and dangerous language. The complexity and length of TC++PL is dictated by the complexity of understanding required to be a decent C++ programmer. Avoiding C++ entirely is a great idea if you can manage it, but programming in C++ without investing the time to read TC++PL (or another similarly detailed book) is a really bad idea.
Or, _Projecting_.
Whatever happened to the New Turing Omnibus?
There's one on my bookshelf, unread of course.
Of these, I have read, at least a significant portion of:
- C Programming Language (2nd Edition)
- Refactoring: Improving the Design of Existing Code
- The Mythical Man-Month
- Programming Pearls
If you feel you've almost gotten OO, but not quite, then Refactoring is a great book. That one lit up the "ah ha" lightbulb for me.
I agree with the comments about GEB - I've had a battered copy for over 20 years and I still haven't made it all the way to the end.
I read Design Patterns (GoF) and actually tried to write a text editor the way it describes it and found that it made selection really really difficult, so I had to find my own solution.
But I really grew fond of the Visitor Pattern, because you can do a lot with very little code.
Computer Graphics is the best school for Object Oriented thinking, I've found.
That's funny, I tried using the Visitor Pattern very heavily for a while, and ended up deciding it wasn't worth the trouble. Using it made me feel very virtuous and proper for a few years, but I've rarely if ever used it in the decade since, and never regretted not using it.
I didn't quite "get" the visitor pattern until taking the time to learn CLOS and multiple dispatch.
I don't understand this at all. To me, this reads as "Here are books that have been recommended to me that I haven't read. Nobody reads these." He implicitly says this himself, when he states "I've read all of these books myself, so I have no difficulty believing that many moderately competent programmers have read them as well."
No, that's not the same thing at all.
Posted more than a year ago: http://news.ycombinator.com/item?id=397996
(The URLs look identical... I wonder how this made it through the dupe filter?)
Is it just me or has HN gotten really cynical today?
This is remarkably annoying.