Code Generation in Action 262
Code Generation in Action | |
author | Jack Herrington |
pages | 342 (10 page index) |
publisher | Manning |
rating | 9 |
reviewer | Simon P. Chappell |
ISBN | 1930110979 |
summary | A masterful tome. |
Overview
Code Generation in Action, CGiA to its friends, is presented in two parts. The first part is four chapters, and covers a code generation case-study, the basic principles of code generation, including the different types of code generation strategies together with reasons why you would or would not use each strategy. The book's chosen toolset for building generators is presented next, and then some walk-through examples of building simple generators wraps up the first part.The second part is a kind of a cross between a cookbook and a list of engineering solutions. There are nine chapters with the breadth of solutions covered being quite impressive, covering the gamut of generation of user interfaces, documentation, unit tests and data access code. Each chapter presents a couple of solutions within its topic area, often for different technologies within that topic. For example, the user interface chapter covers the generation of Java ServerPages, Swing dialog boxes and then Microsoft MFC dialog boxes. No favouritism here!
What's To Like
There's a lot to like with this book. The writing is very clear and of good prose. I found the introduction to be very compelling, and I felt completely drawn in by the opening case-study. The four chapters of part one are a concise case for code generation, and would be very useful information to help persuade co-workers and management of the positive risk/benefit ratio with trying code-generation on a live project.It would be impossible to try enough of any solution from part two in a time-frame short enough to make this review useful, but in the solutions that match my areas of knowledge, I found myself admiring Herrington's straight-forward and pragmatic approach.
What's To Consider
There are two aspects of this book that I want to flag. One of these aspects, some will love and others will hate, and that is the choice of generator language for CGiA. The author has chosen to use Ruby as his working language. This is an interesting choice. Ruby is certainly a language that is inspiring a lot of admiration these days (in fact, it's hard to get Dave Thomas to stop talking about it :-), but with the majority of the code-generation examples being for Java-related technologies, I wonder why Java was not selected instead.I also found myself wondering about the lack of discussion of how to integrate these Ruby tools into a typical Java build process. Many developers I know use ant to bring automation and consistency to their builds, yet the book doesn't mention this. (JRuby anyone?) Certainly something to consider for the second edition or future code-generation authors.
SummaryThis is a masterful tome that inspires and delights, although the two issues raised above did cost it a perfect score of ten.
Table Of Contents
- Code generation fundamentals
- Overview
- Code generation basics
- Code generation tools
- Building simple generators
- Code generation solutions
- Generating user interfaces
- Generating documentation
- Generating unit tests
- Embedding SQL with generators
- Handling data
- Creating database access generators
- Generating web services layers
- Generating business logic
- More generator ideas
You can purchase Code Generation in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
good stuff (Score:5, Interesting)
My personal favorite trick at the moment is describing interfaces in XML, and getting multi-language bindings and docs out of it with a few XSLT scripts. Techniques like that makes script language bindings easy as pie (as do other systems like Swig).
Software Engineering is not just there yet (Score:2, Interesting)
NOT about compiler code generators (Score:5, Interesting)
But apparently, it is not. I, for one, wasn't too happy seeing the term "code generator" applied to superficial software that generates HTML/user level code for standard dialog boxes etc. HTML isn't code in the first place, anyway.
Maybe I'm being too fussy about this, but a code generator, traditionally has always meant a part of the compiler back-end which actually translates intermediate code to machine-level instructions. VB and other UI tools generate stubs for the most part...well maybe they are code generators, but I'm just not too happy about the choice of terms.
Good subject, bad example (Score:3, Interesting)
"Even if code generation could build 100 percent of the application, there will still be an endless supply of boring meetings about feature design."
----
" For example, when a lot of code needs to be written to perform relatively simple tasks, engineers can smell bad design. The EJB platform requires the construction of a bunch of classes and interfaces for each database table. Some consider this a design smell."
----
Wow. So I have boring meetings and a really bad platform to look forward to. Yowza, bring it on!
OK, I'm partially joking here. But I think it's worth considering... when we're glad that we have a tool to alleviate the hassles of using a technology (like EJBs), maybe the technology and platform needs to be reconsidered? Shouldn't the platform perhaps do more to "hide" the complexity from us?
I'm struggling with this in a similar form right now with SOAP. I'm deploying a set of SOAP services in Java using Apache AXIS [apache.org] implementation. It does a lot of the 'heavy lifting' for you, but I'm still struggling with the particulars of how to deploy a service, serialize/deserialize my classes, ensure this API works well across a variety of clients (I'm testing with Perl, PHP, and Java), etc.
It can be a bit daunting. But... simple things *are* simple, and the level of code generation available is just about right. I don't *have* to generate a bunch of "helper" classes to put a SOAP service out there, the Axis implementation hides most of those details. I *can* generate additonal classes, and customize my WSDD and WSDL files to handle more complex situations, though. So, it's not perfect, but maybe it hits the mark a little closer.
Anyway, code generation can be great. I've done it before with things like interface creation (take an interface description and go to either HTML or Swing), and it can be very handy. But I wouldn't want to implement a system that is unusuable as a platform without those tools. Real programmers use vi
Code generators are just compilers... (Score:4, Interesting)
I became a code-generation convert about two years ago when I first encountered Perl Data Language -- what made PDL development feasible was a code generator by Lukka, Glazebrook, and Soeller: their generator ("PP") writes all the loops and conditionals that do vectorized processing of large arrays.
Of course, PP has its limitations -- the age old complaint of engineers is that they will eventually outgrow any code generation framework -- but it's simple enough to augment the generation language or, in extreme cases, to sidestep the parts of the functionality that you're not using.
Re:Am I FUD? (Score:2, Interesting)
Re:We didn't know we were doing anything special.. (Score:3, Interesting)
Like I said, I have no idea what people are doing these days, this was back during EJB 1.1 days, pre-2.0, and we had a primarily message-based system that used JMS or other non-JMS compliant messaging systems like TIB. Thank god I don't have to touch EJB/Enterprise Java with a 10 foot pole anymore, since it's one of the most poorly designed systems imagineable - I love a lot about the Java language, but Enterprise Java needs to die a slow death.
true story (Score:3, Interesting)
"Hey, this guy figure out a way to increase productivty to a point we can let three programmers go!"
"Well then, lets be sure one of them is the guy who figures out how to save us money!"
Code Generation incorporated in .NET (Score:3, Interesting)
What is great is how they abstracted out the target language. Once you build a CodeDOM graph in your generator, you can pass it to any language generator (C#, VB.NET, J#, write your own) to create the result.
Re:Am I FUD? (Score:3, Interesting)
Code generation and macros (Score:3, Interesting)
In theory, good programmers never write repetitive code: they factor out functions, classes. Still, there are things that cannot be factored out easily, patterns of code that just do not map well into functions or cannot be abstracted away in whatever way the language provides.
Some languages are better at abstraction than others, but not many provides the ability to generate code (think of syntactic abstraction). This is where Lisp macros shine. They can hide ugliness I'm forced to do in the name of performance, define new control structures,
Think of the number times you were forced to go out of your way to solve a problem because while it was more correct or efficient it was less easy on the eyes. True macros would have helped. Well, divide that number by 10, the rest was probably your fault
A language needing a code generator for reasons above lacks power and for this lack a thousand small tools will appear all trying to plug some holes.
Shameless Paul Graham link (Score:1, Interesting)
Someone mentioned Lisp macros? Here's the obligatory Paul Graham links, posted AC to avoid karma-whoring:
Re:Software Engineering is not just there yet (Score:3, Interesting)
For example, many games use precomputed lookup tables. It would be nice if the entire table could be generated at compile-time. You might be able to do it with a really awkward template, but it's best done using straight compile-time programming.
What's funny about C++ template metaprogramming is that it basically turns into LISP-like code because you have to define everything recursively!
Re:Code generation == metaprogramming (Score:2, Interesting)
Metaprogramming it is, but it goes beyond that in allowing you to create your own domain-specific language - and that's really the point. Even modern languages like C# and Java are incredibly long-winded at expressing some types of code, no matter how well you use templating and inheritance.
What people seem to miss is that computer languages aren't designed for computers, but for people. Lisp is nice (for a machine), but a disaster for ordinary people to read (yes, I've written a lot of Lisp). Perl is even... well, let's just not go there! And whoever imagined that cutesey RPN languages like Postscript, Forth and Smalltalk could ever be mainstream needs their head read!
Ruby is a fine choice for generators, with all the compile-time power of Lisp, all the advantages of Perl, excellent templating, integrates easily into almost any build environment, and it's readable to boot. It's really the jackpot when considering this kind of task. But to consider Java, C#, C++ or C for all but simplest CG tasks is simply frightening - I know, I've done it multiple times.
I agree that the title is misleading and said so to Jack during the review cycle (I'm acknowledged for my feedback on p.xix - thanks Jack!). Code generation is about creating, implementing and using a concise human-friendly language for your task. Or compromise a bit and use XML or CSV. You'll loose some readability but gain additional tools, and not have to understand pesky things like production rules and shift-reduce conflicts :-)
I really look forward to the creation of serious human-usable metalanguages so that generation to today's languages becomes unnecessary. For example, why are EJB's not just a pluggable language extension to Java?
Anyhow, I like the book, and although I've been writing and using generators for over a decade I'm learning some new things from it - you will too!