58 von 62 Kunden fanden die folgende Rezension hilfreich
Let's Compare Options Preptorial
- Veröffentlicht auf Amazon.com
Format: Gebundene Ausgabe
Anyone studying compilers have either endured or profited from one of the red/green/purple "dragon" books such as Compilers: Principles, Techniques, and Tools (2nd Edition). Given multi processors and the now proven success of LH parsing and much more, much of the old dragon series is out of date and Modern Compiler Design (MCD) is well positioned to fill the void, along with Cooper.
The "go to" book on compilers today, both for courses and reference, is the Rice U team of Cooper and Torczon's EAC: Engineering a Compiler, Second Edition. There are six or seven others out there dating back to the '80s, some very cheap, but both MCD and EAC are really the only two worth consideration given the "takeover" of the OOP paradigm as well as the rebirth of functional languages like Haskell and Scheme and numerous changes in optimization. But see below about this edition's changes if you are studying this away from career considerations.
So, your decision, whether for a course or self study, comes down, in my opinion, to MCD vs. EAC. What about both? There is a LOT of overlap between the two, and both cover very current topics, including the reprise of legacy algorithms due to multiprocessors (eg. instruction scheduling). A key difference is organization-- Cooper uses a component build pedagogy, sortof going left to right from scanner and parser to front end, LOTS on Intermediate Representation (much more than any other text including the current MCD), a LOT on optimization, and a good amount on back ends, machine language, assembly, etc.
To do this, and keep it under 1,000 pages like the dragon, Cooper mostly sticks to LISP for high level languages, but obviously covers all the middle calls and structures. MCD on the other hand, is much more interested in the paradigms themselves, so you get a wonderful cornucopia of wider ranging example applications than EAC.
Another major difference is that EAC doesn't rule out that you might someday build a virtual compiler, or participate in compiler design or maintenance. MCD doesn't even nod or wink at this-- it pretty blatantly states that at millions of lines of code it is very likely 99% of the readers will never really work on a real world compiler, and the learning is really about the value in understanding integrating systems from the algo and data structure level all the way down to registers and processors. EAC knows this too, and certainly teaches to the "30,000" foot level overview, and both books are musts for IT engineers as well as programmers, from the viewpoint of "getting" the big picture.
In the real world, compiler engineers use what we programmers would call "design patterns" as much as OOP coders do. Both authors challenge the "already proven," "best practices," "previously solved," and "well understood" assumptions of plug in patterns (which don't work nearly as generally with compilers as with OOPs, but which are long established in compilers where they do work), but do give numerous real world implementations that can be used day one in your compiler study or designs, and certainly in better understanting the whole chain of custody from symbol back to symbol. These approaches, as well as the very up to date comparisons of compiler vs. algorithmic options, leave the old dragon series in the dust, unless you're simply trying to get a background. I'm budget conscious and wouldn't be so tough on the dragons if they were available more reasonably, but even used and out of date they are more expensive than either of these two! To be honest, compilers change very slowly compared to other IT components, so the dragons aren't "bad" -- they are just too expensive at this date.
If you are studying to get an overview, you won't go wrong with either of these two fine texts. If you really are going into compilers (and as a LISP lover, we often build our own compilers AND languages), including in the hot field of embedded, you might want to consider both if you can afford them. If you are teaching a course on compilers (I've used both texts in my online compiler tutorials), I prefer Cooper if your focus is on handoffs between components, and this text if your theme includes more paradigm comparisons and you want a greater variety of syntactic examples. (But remember, the front end of scanning and parsing, and the back end of assembly, ML and code generation, have MANY similarities between higher level languages-- 0/1 is still 0/1, in Java, C# or Scheme!).
As for your students: Cooper is the choice for those going into compilers, and MCD for those looking for more general knowledge of how GUIs relate to registers and processors vis a vis others than LISP, like JAVA, C++, and other imperatives. Of course there also are compilers that OUTPUT in C, so you can engineer the ENTIRE compiler as a front end for another C compiler! Silly? Nope-- I see a lot of new patent applications that are using creative "partial interpreters" in embedded applications, and many combined imperative/functional syntactic features. (My own simple, summary definition being that the interpreter generates results, and the compiler generates code). Either book is fine for interpreter study too, enough is covered that the differences are negligible-- IOW, please don't bother buying a separate text with the word "interpreter" in the title just for that semantic difference!
The authors make a good point in this fine text: unlike any other IT topic, compilers are a "mature" science-- meaning change is much slower than, for example, in concurrent register and memory access algorithms for differing architectures and data structures using off chip memory, or, the cost and use of RAM. Even so, after a 12 year hiatus, and the text being used in numerous undergrad courses, this edition has a complete makeover, including a new chapter on optimization (not missed in previous years, just more dispersed thoughout the text). These two texts aren't cheap, and what I'm saying is that if you're more into self study and "retirement" type tangential interest, you can save a lot by getting older editions, and then brush up on newer topics on the web (concurrent, parallel, optimization, etc.). If you are beginning, or hot into your career, this won't work! At least it's easier to get away with in compilers than it would be in, say, newer ways to structure red/green trees in oop, learning Canvas, or studying HTML5.
Prediction: Just like in JAVA, I'm predicting that, due to embedded and cloud apps, future "compilers" will be much more distributed entities, some pieces residing on the client side, and barely recognizable from today's models. Enter Erlang? Where does that leave these texts? It doesn't hurt to "look" at "a" compiler as if it were an entity, even though that part of the model is fading quickly as we write-- the components are the same. But once we get to handheld Crays for $50, a LOT of the old compile steps will necessarily be remote. Distributed communication then raises a ton of issues only briefly touched upon by these volumes, but both correctly wink at the fact that "old" models will see rebirth as batch and in-order pipelines come back in vogue, not due to your smartphone recognizing your voice, but Google's servers recognizing your voice!!! As both books point out, some of the register issues with concurrent and parallel are NP hard, and the "solution" is seen to be coming in Quantum computing. With that perhaps a decade off-- what fills the gaps in between? GREAT career question!
NO COMPILER REVIEW WOULD BE COMPLETE without mentioning the contributions of Ronald Mak, "Mr. Compiler." His three books (Writing compilers and Interpreters) are HANDS ON step by step encylopedias on writing compilers. The three books used different language approaches and were, respectively, 1991 (516 pages, IBM 8086 target, language: C); 1996 (2nd Edition, 838 pages, also 8086, C++ language (plus Pascal processor)); 2009 (3rd edition, 840 pages, complete Java rewrite, source program still Pascal, includes IDE so is platform independent (or JVM dependent if you will). Links are at: 1991: Writing Compilers and Interpreters: An Applied Approach (Book + Disc); 1996: Writing Compilers and Interpreters; 2009: Writing Compilers and Interpreters: A Software Engineering Approach. Unlike the dragons, these fine texts are available for pennies and worth more than the $50 plus of the dragons!
Library Picks reviews only for the benefit of Amazon shoppers and has nothing to do with Amazon, the authors, manufacturers or publishers of the items we review. We always buy the items we review for the sake of objectivity, and although we search for gems, are not shy about trashing an item if it's a waste of time or money for Amazon shoppers. If the reviewer identifies herself, her job or her field, it is only as a point of reference to help you gauge the background and any biases.