Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

How'd you like that for an opening title? Did it grab your attention? Hell, your reading this far so I guess it did. The book I'm focusing on here is Build Your Own .NET Language and Compiler and please, don't click the link and then go buy it. I don't care about the 50 cents worth of referral money I'll get if you do. I wouldn't even recommend the book if I got 50 bucks of referral money (well, money talks, so maybe I would).

The book starts out with the basics of parsing and regular expressions and all that jazz. But the extent of the code is a bunch of screen shots. We are writing a parser/compiler dang it, we aren't WYSIWYGing our way through life at this point, you have to show some real frigin code. What you end up with is a bunch of screen shots of many tools for writing a compiler, but not really the code, unless of course you go grab the CD and break through all of the code without a lick of explanation from the book. God I hope the code is well documented with comments, or you just bought an issue of Compiler's Illustrated and this isn't the Swimsuit edition. I'll include some of my own links at the bottom, where I give actual code for many of these processes.

OK, so you get to see a bunch of tools, and what do you get? Well, you get a bunch of half-assed tools (sorry for the language if your kid is reading my highly technical blog... In fact, if he/she is I could use some interns, must type 50+ WPM and be proficient at C, C++, or C#). A mathematical expression evaluator is the first. I think it is always the first. People always trivialize math. So make sure you look at all the pretty pictures and try to glean some wisdom from the text. I have a mathematical expression evaluator by the way, it's called calc.exe and from what I can tell it has shipped since 16-bit windows. He also makes an attempt at a regular expression workbench. You can't have enough of those (actually I'm not being sarcastic here, I always appreciate a new regex tool), but then he never writes anything or demonstrates compiler technology that uses regular expressions. Does he go into NFA/DFA technology? Well, he does talk about it for a few sentences. BNF format? Again a few sentences here and there. But wait, another tool is what you get and this time it is a picture of a drop-down menu with all sorts of really tantalizing names (convert from BNF to XML, display a BNF parse tree, display formatted docs, etc...). At this point use one of the pages to catch the drool coming off your lip, because that is as close as you'll get in this book to anything cool.

OK, so forget the tools. At some point he actually starts talking about real compiler technology. I think around chapter 7 maybe? I really should dig up the TOC on Amazon, but I'm only going to waste enough time on this book to finish this posting. Anyway, they start talking about the various parsing techniques. Recursive descent (RD), Top-Down, Bottom-Up... I think there are some other odd names they throw in there to mystify the reader. After reading all of the major compiler design books I shouldn't be mystified by something that could classify as a 4 Dummies book (unless it is something like Cross Dressing 4 Dummies, I could probably use that after my Halloween party)...  Anyway, they really don't do the entire process justice, and I think at some point some more tools are used, Yacc might be mentioned, and bam, back to the pictures.

At this point I want to identify the worst problem I found throughout the entire book. Apparently the author didn't have time to finish the code so they left a bunch of exercises for the reader. Nah, nah... You don't leave the compiler as an exercise in a book on how to write a compiler. You leave bits and pieces, but not the important stuff. Going through my Knuth books, I'm actually surprised when he leaves problems as exercises that require more know-how than what has been provided in the chapter. I don't mind exercises for the reader, but there is a limit people. Imagine getting back from Home Depot with a 300 page picture book on building a house, that had a bunch of pictures of completed homes, and some text offering that the building of the house will be left as an exercise for the reader. Doh!

At the end of the book, it is apparent I'm not going to get anything of use and then it starts talking about code generation. Oooh, something with some meat. In reality, they've been naming their nodes for the calculator in such a way that the name of the node was pretty much the name of the op code that was going to be called. They may have some Quick Basic implementation code spits as well, but I'm confused at this point (and mystified) because I've been thumbing this book for an hour. In reality the act of spitting IL is probably worth an entire book of it's own (oh wait it is Inside Microsoft .NET IL Assembler and you really should buy this one so I get 50 cents). That isn't fair because that book is actually how IL functions and not how to spit it. But I'd think one does precede the other since eventually your going to run out of node names to match to IL op-codes and when opComplexOperation isn't mirrored by OpCodes.ComplexOperation I just don't know what you'll do.

How fair of a review is this? Well, I've read actual compiler books, quite a few of them. I've implemented my own parsers and compilers many times for many different circumstances. I don't think it is a hard process and I think extending the process to a more general development audience is important. There should be a relatively accessible book on writing your own .NET languages, but this book is certainly not it. I'll keep looking around, I hear there is another book focused on .NET language generation and I'll have to search it out. Maybe an O'Reilly publication? Can you get an accurate review from something in about an hour's time? Well, I read fast, the words were quite large, most of the content was entirely familiar and only about 30% of the page material was text, so I'd hope so. Take this for what it is worth, but if I see any referral money for that book, I'll know someone is going to be laughing hysterically when they get that book in a 2-3 days from Amazon. PS: I didn't and won't buy the book. I spent a couple of hours at Borders today running through two books that caught my eye when I was really looking for a great .NET Localization book. I need to dig up Michael Kaplan, since I'm sure he has written something somewhere.

Lexer/Parser/Compiler  Code and articles for different types of parsers
Lexer, Parser, Compiler, Oh My!  Postings, with code, on even more lexer/parser stuff
ftp://ftp.cs.vu.nl/pub/dick/PTAPG/BookBody.pdf A more hard-core text on parser technologies

Published Friday, November 05, 2004 3:12 PM by Justin Rogers
Filed under: , ,

Comments

Saturday, November 06, 2004 7:18 AM by Wilco Bauwer

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

When you say you heard about another book, you probably mean John Gough's "Compiling for the .NET Common Language Runtime" (http://www.amazon.com/exec/obidos/tg/detail/-/0130622966/ref=wl_it_dp/102-0123623-1192973?%5Fencoding=UTF8&coliid=I146RZZ188X2DN&v=glance&colid=2RH4PEYCKQA3L).
Tuesday, November 09, 2004 6:34 AM by Edward G. Nilges

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

I am sorry you didn't like the book...but...

You based the review on a superficial scan of the book, so superficial that you don't even realize that there was no CD. Instead, the book provides a link to the Apress download site, which you have not followed.

All you saw was "pretty pictures". Well thank you. But I'm afraid your review is worthless since you did not download the code, a requirement for any serious user of the book.

You decry my choice...to mention yacc and lexx and regex, but develop the compiler and parser using hand code, so as to teach how and why yacc, lexx and regex are important, and also that they can be used as specification languages and not coding languages.

Having written a yacc-type program, I could have included Build Your Own .Net Yacc, but this would demand too-high a level of technical sophistication from the entry-level reader. The book is a Getting Started for those without the considerable technical background that is needed for typical compiler tomes.

Your superficial examination told you the compiler was incomplete and you accuse me of leaving its completion as exercises for the reader. This very serious charge of professional dishonesty is untrue. The compiler as downloaded (remember, no CD, download, get it?) runs all examples in the book.

Missing are functions and subroutines. Again, they would form a complete chapter in themselves and involve explanation of stack frames. Again, this is a Getting Started and tyro's prologemena to the Dragon Book and as such functions and subroutines would be too advanced...especially given the focus on compiling business rules (did you see them?)

The niche my book occupies is the chasm between practical books on generating code for .Net and academic theory, and too my knowledge this niche is not bridged.

In fine, I find it more than uncharitable to "review" a book after a superficial perusal at Border's. I find it a serious breach of professionalism. The recent re-election of Bush may have comforted people in many fields who base book reviews, and wars, on superficial input, but many other people are tiring of this gesture.

I request that you delete this review or post an apology. I would not make this request had you in good faith even just looked at the code but you, like our President, seem to have mistaken mental images for good old Reality.

Finally, your reference to fiscal compensation manages to exhibit what seems to be a corrupted process of reviewing and to show how cheap you can be bought.

Regards


Edward G. Nilges
Tuesday, November 09, 2004 8:43 AM by Justin Rogers

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

To hit some of the fine points of your commenting. I did go back and perform more than a superficial scan of the text and also looked at all of the source code.

Books are a teaching in written form of a given subject. Your book is a teaching of some given subject with nearly no amount of valuable information in the book itself, and assert that the source code is a requirement for understanding the subject matter and gaining worth from your explanation. Let's take another book that is somewhat similar.

The Shared Source CLI book published under O'Reilly shows an excellent example of teaching even though there is a bunch of code behind the scenes. The entire Rotor code-base backs the book, and yet it manages, in only a few hundred pages to dig into and explain this source in great detail (including large amounts of code and explanation in the book and even a few pretty pictures). If you had truly wanted to bridge the gap, you might have done the same. What you have failed to realize is that if you wanted pretty pictures for the less technical users, then you'll also realize that they won't be able to easily process your source code, which goes completely unexplained. I don't care how good the comments are, less technical users don't learn in code.

In essence you've alienated the only audience your book supposedly extends to.

Your political references just adds more of a bullshit call to your comments at all. Your opinion of the political system, or mine for that matter, has nothing to do with the review.

So not only will I not delete the review. I'll assert, after spending another hour on your book and examining a drop of the source code, that even if you had solved world hunger in the code, it doesn't make the book any better.

My reference to fiscal compensation is a joke. Just like many of the comments on my blogs are jokes. Just like the book we are talking about is a joke. You get it? Jokes!
Tuesday, November 09, 2004 10:31 AM by Jack

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

Keep writing what you think.. You read a book and then told anyone who cares what you think about it..... Sounds reasonable to me
Tuesday, November 09, 2004 11:38 AM by Dave Kekish

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

Just wanted to say thanks for a honest review. I had been thinking of picking the book up. Won't be doing that now.

I've wasted enough money on books only to be disappointed.
Tuesday, November 09, 2004 10:29 PM by Andrew

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

Mr. Nilges, you ought to come out of your ivory tower and get a dose of that good ol' reality that you tout sometime.

And what in the world does the President of the United States have to do with a book on computer technology? A professional would keep this discussion on topic.

Thank you.
Thursday, November 11, 2004 5:49 AM by Edward G. Nilges

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

Hmm, you "performed more than a superficial scan, and you looked at the source code".

But you didn't read the book, did you, much less use the performance based approach I recommend.

This is obvious, for in fact the book explains the source code. For example, the recursive descent algorithm is explained in detail in Ch 8, with a sidebar on "Cain's Amulet" to explain how a state is passed among recursive parser procedures.

I think what happened is you were offended, not so much by the political liberalism, as by my tone which fails to be authoritarian.

As to the relevance of politics. I have consistently found that political conservatives have difficulty in learning to code, since coding involves a necessary deconstruction of social structures: their analysis.

For example, in debates about the reliability of high-tech election systems, conservatives make the claim that because the computer systems are, well gawrsh, computers, they will be by definition accurate.

However, we know that programmers who work for Deibold and similar firms, some with criminal records, have full access as we do to the systems at all times, merely as a condition for doing their jobs. We also know that Deibold's CEO promised Bush to deliver Ohio, and we know of several absurd election results that show that at no time were "business rules" (totalVote >= voteForBush) applied.

Of course, since I do indeed work and have worked in the "real world", at large corporations including Baxter, Household Finance, etc., I have worked side by side with political conservatives competent at their jobs.

But in your case, your clear bias caused you to post a review based on a book you haven't been sent or purchased, without reading the book.

I don't know where you get the idea that computer technology has nothing to do with politics. In my chapter 9 on a humanistic application of business rules to small scale credit, I demonstrate a way to make capitalism work for the small borrower by using modifiable and documentable business rules, in ASCII text form, as opposed to a binary set or a single number.

I have looked over the rest of your site, and clearly we will have to "agree to disagree" about politics. For one thing, to describe the Rehnquist court as not activist is just silly: they appointed the President to his first term.

But I will have to ask you to withdraw comments based on a book you haven't read, much less worked through.

Thursday, November 11, 2004 8:51 AM by Justin Rogers

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

I wouldn't have posted the review if I hadn't fully read your book. As mentioned in comments and in the posting, I spent over an hour reading your book. I don't need to *work-through* your material. I don't need to more *thoroughly* read your material. And I don't need to *consider* the side bars and notes. I've written compilers, done code generation, and am a huge advocate of code emit in .NET. You can read back through the blog and see that.

I even sympathize with simplistic design and enabling users that aren't familiar with the concepts. You can check out my short postings on a number of different parsing systems under .NET and a few about dynamic code generation.

All that considered, I still don't have any higher an opinion of your book. I've given you due diligence, and have spent more than 5 hours now between the actual book and the source code. I won't spend any more, nor do I need to. That is more than enough time to adequately review a book. You see, if an in-depth review takes say 15 hours, then a slightly less comprehensive review can be done in 5 hours. Odds are that in 5 hours, at least one thing would strike you as interesting and/or usable, especially if you are EXTREMELY familiar with the subject matter. I didn't get that from your book. I would have given it 15 hours and done a better review, but the book doesn't warrant it, nor does it have any information that isn't freely available on other sites. Difficult to find in a hurry maybe, but the information is there and in many cases more accessible than it is in your book.

I'm sorry brah, but no matter how hard you call me a conservative (which I'm definitely not), how much you dislike bush, or why you keep ranting about politics in general, none of that will change the review.

As for your small scale credit application, that is the basics of a data driven design. While I can respect writing custom parser technology for any config files that might contain the data, you didn't live up to the real concepts underlying your book. Primarily because data driven designs aren't about code, compiling or any such nonsense, but instead about changing the parameter values to fixed functions, or possibly even interpreted functions. At best you could call that scripting, but certainly not creating your own language and compiling and certainly not in a chapter 9 of a book that is supposed to be about compiling. Anyway, I'm done with this thought process. I have books that I consider more worth my time, IMHO, and I'm doing the community a disservice by not spending my time on those.
Thursday, November 11, 2004 9:03 PM by Edward G. Nilges

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

Can't change the fact, "brah", that you posted a negative review after one hour's perusal and skim. Can't change the fact, "brah", that this is the only conduct for which I need an apology and retraction.

The latest review at the Amazon site, currently under Bill Ryan's review, which because of its quality is a Spotlight, is from Bob in SF. I have no problems with this review because my book did not meet Bob's needs, and he bought it and gave it a chance. I am thinking of revising my self-review to praise Bob.

I certainly don't understand your point about the "small scale" credit application. A case can be made that all humane and all doable MIS applications are "small scale"; and, the phallocentric language of programmers who are forced by the logic of their situation to make reference to unknown "needs" at an unknown, and unimplemented, "large scale" may be the problem.

Many implementers have indeed tried to implement data-driven designs as a set of fixed functions, to which the data "points". Consistently they end up with a mess because they don't realize what they're about.

When the user has a requirement demanding If..then..else, a common response in this venture is to keep the selection in code which prevents the user from controlling it, of course. Likewise for iteration.

On a number of projects, I have encountered a mulish resistance to the idea that what is being developed "really is" a computer. Most recently, engaged in cleaning up a C# and VB mess for DNA synthesis, I realized that the problem was that the original developers had developed a "data driven" design, all right...in which the selection and iteration were in the code, and the steps in SQL Server tables.

As a direct result, the client literally could not understand how to use his system. Paradoxically the original developers claimed that to provide him, not with "data" but a special-purpose language, would "confuse" the client...who had a doctorate in genetics, a subject which is far more challenging than programming.

The union card holders, the programmers, who despite their commonly anti-union sentiments, almost unconsciously keep the selection logic and iteration in code.

Chapter 9 is in fact key, for with experience in the early days, I need to show that application programmers are blocked in enterprise systems development by constructs including "oooh, compilers" that were transgressed effectively in the early days.

As to being a hip sort of dude who doesn't support Bush, or maybe voted for him but doesn't support him, or maybe voted for Kerry but was relieved, or what, objectively the gesture of pulling a book off the shelves, and "reviewing" it is the sort of nihilistic gesture that Bush makes because in a strong sense, he and his team believe that they can manufacture (in part, using computers of course) "reality" and don't really have to do their homework which de dog done ate.
Sunday, April 10, 2005 8:04 AM by TrackBack

# re:Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

^_^,Pretty Good!
Tuesday, August 15, 2006 9:29 PM by discarded lies - hyperlinkopotamus

# Crazy BDS-suffering author of a (not too good, apparently) book on writing compilers harasses a reviewer

Crazy BDS-suffering author of a (not too good, apparently) book on writing compilers harasses a reviewer

Tuesday, July 31, 2007 6:50 AM by Jeff Ashia

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

Just looking for a reference material on parsing techniques. Thanks

Tuesday, November 20, 2007 7:35 PM by tbelcher

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

Well, I was looking for the following books:

"Compiler Design For Dummies", "Teach Yourself Compiler Design in 21 Days" and "The Ten Minute Manager's Guide to Compiler Design".

Unfortunately nobody seems to have written any of them yet. Damn! ;-)

Fortunately the book pdf that you link to is a pretty good substitute. Thanks for that.

Wednesday, December 05, 2007 6:17 PM by Joe M.

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

Nilges sez:

"The recent re-election of Bush may have  comforted people in many fields who base book reviews, and wars, on superficial input, but many other people are tiring of this gesture.

"I request that you delete this review or post

an apology. I would not make this request had you in good faith even just looked at the code but you, like our President, seem to have mistaken mental images for good old Reality."

Hey, I don't like Bush or republicans at all, but I am a computer author, and what Nilges is doing here offends me considerably. First off, I absolutely am sick of a-holes like Nilges who force their poor logic about politics on everyone else, in the middle of a conversation about something completely unrelated. Basically Nilges, keep your stupid, ignorant political opinion to yourself if you want to sell more books.

Here's a typical frothing anti-Bush nut like Nilges: "Gosh that's a nice looking vase on your mantelpiece, but I CAN'T STAND BUSH AND HE'S RUINED EVERYTHING. So what are you doing for New Years?"

Worse is to make demands of the reader. If someone gave your book enough time to post a detailed review and didn't end up liking it, MOVE ON. Get over it. Check your monstrous ego. You should feel welcome to rebut any misinterpretation the reader has, but I think demanding a retraction is just a frightening stance. It smacks of the politics that you probably believe in (i.e. leftist) that you feel it's your right to push people around as long as it makes you feel better.

Perhaps, Mr Nilges, you shouldn't write any more books until you've thickened your skin a bit.

Tuesday, January 08, 2008 10:59 AM by chaitnya

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

nice but..........

Monday, February 04, 2008 10:30 AM by Baudin

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

hmmm, after reading all the comments I have to admit that I was a bit "frightened" to read the book myself, but I did. I’m a complete noob when it comes to building compilers, so I thought I might be just the right audience, and I was!

I found it both helpful and clearly written when it came to helping me along the suffocating path of understanding how to build a compiler. It helped me understand which steps I needed to take and what I might do to take them. I distilled the proper info better then I could have done browsing the net. (And I’ve tried, and tried and tried....!)

This being said, I didn’t like the tool-references much. Especially when it came to generating IL. I like to get my hands dirty before I “generate” solutions.

Conclusion, I’ve been able to write a decent syntax highlighter and C# code generator after reading this book. (C# cause CodeDom RULZ!!!) If the book ever gets revised please include more on how to actually get good MSIL code.

Wednesday, February 20, 2008 9:32 AM by Steven

# re: Language parsing and compiler design doesn't have to be hard, but boy this book really sucks!

You're right, I just bought this book, and I really wish I had read your review first.  It's complete garbage.  It seems to be filled with a lot of filler, mostly comprised of political innuendo and ranting about various agendas that have nothing whatsoever to do with a book on compiler writing.

Friday, May 09, 2008 8:17 PM by how to get a six pack

# how to get a six pack

How to get ripped abs!

Tuesday, June 03, 2008 10:23 AM by solved exercises of compiler design

# solved exercises of compiler design

Pingback from  solved exercises of compiler design

Leave a Comment

(required) 
(required) 
(optional)
(required)