Great for pocket calculators when you can remember what the 2 or 3 levels of stack contain, but close to unusable in a programming language, because you can't visually parse it (thinking Forth here) without knowing the arity of every method.
If the CG is well written, the generator and the resultant code is more functional, performs as well or better, and is much more maintainable.
An example we're using at present takes an XML description of a database schema (our main database is described in 1200 lines without the embedded documentation, 58 tables). It generates perfectly-formatted, commented, readable, and eminently predictable code in five different programming languages, totalling 40,000 lines, as well as high-quality printed documentation. In fact the code is indistinguishable from code produced by a human, except that it lacks human quirks and inconsistencies.
The generator itself is around 4000 lines of Ruby including all the templates, and has been significantly extended by at least six developers, each of whom found it took them less than thirty minutes to learn enough Ruby to read, understand and extend the generator. The generator itself isn't a simple template expander; it understands and analyses the structure of the database, taking only a few hints to decide exactly which operations are required on each table, relationship and index.
The generated code includes:
SQL DDL (so far only for 1 database product, but additional ones with ease),
SQL stored procedures for a range of data access operations including all the bulk operations needed for performance (things like efficient subset-replace from a temporary table, etc),
Beans-style C# objects, collections, and nicely segmented access (CRUD) APIs,
Composite data type conversion code for the same tables in C++,
Business logic base classes
Consistent naming, logging and error management across all generated code.
A further generator in C# augments the generated (and manually subclassed) APIs to produce (sorry, no line count):
WSDL interface definitionss for all these APIs,
Web Service implementations with location and version brokering,
Web service client proxy APIs supporting location transparency (including local linkage),
I think you'll agree that to generate all this from such a small description file adds significant value over hand-crafting the same. And that's before we start generating user interface, performance predictions and analytical models, test code and adta, etc.
The generator is integrated into our build environment so that the resultant code never gets checked-in (so is not susceptible to modification) and yet it's always available for debugging. We can subclass all the objects where hand-tweaking and additional methods may be necessary.
Because it does the grunt work of handling all the bulk operations on the database, those higher-performance features are more likely to get used - developers wouldn't always bother. In these cases, the performance will exceed that of hand-written code.
Since introducing the generator, we almost instantly found other applications for it (other databases), and also have become much more able to make changes to the schema during the project as needed. Adding a field is a one-line change in one file, not a series of dozens of changes spread across many files, following by a simple recompile. Adding an access method is as simple as adding the index which supports it - the retrieval APIs are implied by the existence of the index.
A couple of times an additional method has been needed, and it's been added to the generator - this method is immediately available for all relevant tables in the database. Again, adding such methods has been as little as a 2-20 line change in the generator.
The simple fact is our project is literally months ahead of schedule, and future projects will be even more efficient. As far as I'm concerned, you might as well have asked me what Java or C++ could possibly do that assembly code couldn't have done - the comparison matches at almost every point, with the possible exception of performance.
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!
Optimum density for the reaction mass is around 0.3 - mercury would be *way* slower than water. Remember you have to accelerate some of it.
Try it at http://www.osa.com.au/~cjh/rockets/simulation/
except the server is down (being fixed) at the mo.
Slashdot Mirror
Great for pocket calculators when you can remember what the 2 or 3 levels of stack contain, but close to unusable in a programming language, because you can't visually parse it (thinking Forth here) without knowing the arity of every method.
An example we're using at present takes an XML description of a database schema (our main database is described in 1200 lines without the embedded documentation, 58 tables). It generates perfectly-formatted, commented, readable, and eminently predictable code in five different programming languages, totalling 40,000 lines, as well as high-quality printed documentation. In fact the code is indistinguishable from code produced by a human, except that it lacks human quirks and inconsistencies.
The generator itself is around 4000 lines of Ruby including all the templates, and has been significantly extended by at least six developers, each of whom found it took them less than thirty minutes to learn enough Ruby to read, understand and extend the generator. The generator itself isn't a simple template expander; it understands and analyses the structure of the database, taking only a few hints to decide exactly which operations are required on each table, relationship and index.
The generated code includes:
- SQL DDL (so far only for 1 database product, but additional ones with ease),
- SQL stored procedures for a range of data access operations including all the bulk operations needed for performance (things like efficient subset-replace from a temporary table, etc),
- Beans-style C# objects, collections, and nicely segmented access (CRUD) APIs,
- Composite data type conversion code for the same tables in C++,
- Business logic base classes
- Consistent naming, logging and error management across all generated code.
A further generator in C# augments the generated (and manually subclassed) APIs to produce (sorry, no line count):- WSDL interface definitionss for all these APIs,
- Web Service implementations with location and version brokering,
- Web service client proxy APIs supporting location transparency (including local linkage),
I think you'll agree that to generate all this from such a small description file adds significant value over hand-crafting the same. And that's before we start generating user interface, performance predictions and analytical models, test code and adta, etc.The generator is integrated into our build environment so that the resultant code never gets checked-in (so is not susceptible to modification) and yet it's always available for debugging. We can subclass all the objects where hand-tweaking and additional methods may be necessary.
Because it does the grunt work of handling all the bulk operations on the database, those higher-performance features are more likely to get used - developers wouldn't always bother. In these cases, the performance will exceed that of hand-written code.
Since introducing the generator, we almost instantly found other applications for it (other databases), and also have become much more able to make changes to the schema during the project as needed. Adding a field is a one-line change in one file, not a series of dozens of changes spread across many files, following by a simple recompile. Adding an access method is as simple as adding the index which supports it - the retrieval APIs are implied by the existence of the index.
A couple of times an additional method has been needed, and it's been added to the generator - this method is immediately available for all relevant tables in the database. Again, adding such methods has been as little as a 2-20 line change in the generator.
The simple fact is our project is literally months ahead of schedule, and future projects will be even more efficient. As far as I'm concerned, you might as well have asked me what Java or C++ could possibly do that assembly code couldn't have done - the comparison matches at almost every point, with the possible exception of performance.
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!
Optimum density for the reaction mass is around 0.3 - mercury would be *way* slower than water. Remember you have to accelerate some of it. Try it at http://www.osa.com.au/~cjh/rockets/simulation/ except the server is down (being fixed) at the mo.
Sigh, that URL looked like HTML and slashdot chucked it.
It was http://www.osa.com.au/~cjh/rockets/list/
There's been a water rocket mailing list running for three years now, accumulating 15,000 messages. The home page is at .
:-), and the canonical links from the mailing list.
There's a fine simulator there too (though I say it myself