Slashdot Mirror
Code Generation in Action
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.
Code generation is definitely something programmers of large/complex projects should look into. There's a lot of different forms of it, and I'd be surprised if people haven't used on form or another already.
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. It is a nice concept, but not pratical. Rational Rose does it to a certain extent.
Consensus is good, but informed dictatorship is better
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.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
The linked article on devx.com really makes me not want to use code generation :-). Let's pick out some fun quotes:
;-).
"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 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
It's a strange world -- let's keep it that way
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.
One area where code generation is very handy is in creating java code to interface with a specific database. Based on the type of interface I want (select, insert, update, delete) and the database I can easily create the classes in minutes saving me days of valuable time. In my case I use this to convert data between 2 databases which could be any number of totally different databases. Now only the conversion procedure needs to be coded (for now).
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.
I wrote a 'software generator'. It worked so well, they laid of 3 coders, and yes I was one of them.
"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!"
The Kruger Dunning explains most post on
The .NET Framework has great built-in support for code generation, called the CodeDOM model. It is the mechanism used by all of the Visual Studio IDE wizards.
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.
Take a look at http://sandboss.org for an example of this in action. Sandboss is a tool for building enterprise apps, so it's rather domain-specific. It makes extensive use of generators as part of the build cycle, so you get the benefits without the BS. In the included sample app, a few hundred lines of application source get turned into 150,000+ lines of communication, configuration, persistence, serialization, and UI code (html, servlets, etc). That sounds like a lot (and it is), but that's 150k lines of code that you don't have to worry about maintaining.
Generating code from database schemas and the like can be acceptable in my book. However, generating code just because it is repetitive and clunky is *not*.
...
:-).
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.
Someone mentioned Lisp macros? Here's the obligatory Paul Graham links, posted AC to avoid karma-whoring:
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!