Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Code Generation in Action Paperback – July 1, 2003
Top 20 lists in Books
View the top 20 best sellers of all time, the most reviewed books of all time and some of our editors' favorite picks. Learn more
What other items do customers buy after viewing this item?
About the Author
Jack Herrington is an engineer, author and presenter who lives and works in the Bay Area. His mission is to expose his fellow engineers to new technologies. That covers a broad spectrum, from demonstrating programs that write other programs in the book Code Generation in Action. Providing techniques for building customer centered web sites in PHP Hacks. All the way writing a how-to on audio blogging called Podcasting Hacks. All of which make great holiday gifts and are available online here, and at your local bookstore. Jack also writes articles for O'Reilly, DevX and IBM Developerworks.
Jack lives with his wife, daughter and two adopted dogs. When he is not writing software, books or articles you can find him on his bike, running or in the pool training for triathlons. You can keep up with Jack's work and his writing at http://jackherrington.com.
Top customer reviews
All the code snippets and regular expression samples are explained in a very clean, detailed way. I was pleased to see that many examples were non-trivial, covering concrete, real world, implementations. Herrington uses Ruby as an implementation language; you may like it or not, but what really matters here are the concepts, not the syntax and even if you don't know Ruby (like me), you will find the code pretty easy to follow.
Little is done to convince the reader that the code generation option in each case was the best solution. For instance, in the case of SQL statements, there are countless other options. What makes this approach superior? One gets the feeling that the answer is the author just needed another example to paper his undertaking with.
Some of the sections are downright preposterous in their brevity. There's a section on generating Swing dialog boxes. It contains almost nothing but a silly diagram that looks like a data flow.
A good book on this subject would have used a real object oriented language to implement the generators, and would have showed the abundant design patterns that would apply to this problem (Builder, Bridge, etc.). One imagines that there could be many reuse opportunities in the generation framework. Code generation in some of the proto-MDA tools (like Eclipse's EMF, for instance) or the JET project show a lot more promise.
The author presents this subject cleanly from very simple beginnings to more complex solutions that really made me rethink the subject and left me with a much clearer idea about how to proceed in the future. I am now looking very hard at Ruby! It's by my desk now until I can get it memorized!
The book suffers from two problems. (1) the regular expression technology proposed is inappropriate (2) the exercises provided are not rich enough to be useful.
I have no objection to scripting languages. I have happily used bash, gawk, python/Jpython and php. I avoided perl because I was struck by its lack of readability and writability. Ruby is no better and no worse than many scripting languages, but the documentation and error messages leave very much to be desired. CGIA offers almost nothing in the way of real help with the language. It took me some time to figure out how to install the libraries properly and debugging was a nightmare! Ruby's regular expression language is yet another variation in the regex language Babel. This is not something I would foist on developers in my organization. Especially when there are much better alternatives.
For years I have been using lex (flex actually) in C for code generation and human language processing. (I have never had much use for YACC/Bison.) When I switched to Java, I found an excellent flex equivalent called JFlex ([...]
JFlex.jar is around 240K. The regular expression language for JFlex is extremely close to that of lex and gawk. It is much more readable and modular than that of ruby, perl, etc. Your Java programmers and maintainers need not learn a new language or download/install/configure an additional 28 MB of libraries. Even better, they can use JFlex in runtime production code, since it produces compiled FSA's which are orders of magnitude faster than an interpreted regex processor like ruby.
Additionally, you can get with lex/flex/JFlex full grammars for C++ and Java, not the superficial variable reader that came with CGIA. And the debugging mode, while not perfect, is quite usable. (There are commercial visual tools for debugging flex grammars, if you need and can afford them.)
From the code point of view, I found nothing usable in CGIA. In my judgment most of the examples were more suited to the classroom than to work, and the solutions presented were often not competitive with alternatives. On the theory/fundamentals side the book does not contribute much to the the understanding of language parsing or generation issues.
The arguments for using code generation are cogent. But if you want to use a more useful, popular, constantly evolving (but equally poorly documented) code generation system, go for XDoclet.
My recommendation: skip CGIA. Spend your time and money learning flex/JFlex for parsing and XDoclet for generating and you will be much better off. If you want theory, sink your teeth into something like the "Dragon" classic (Aho & Ullman).
Sorry, I can't jump on this bandwagon.
Most recent customer reviews
1. The language -- Ruby -- is a strange choice. I've been writing and using code generators, in some form, for decades; I've used mmm...Read more
--I find it...Read more