Forgot your password?
typodupeerror
Java Books Media Programming Book Reviews IT Technology

Code Generation in Action 262

Posted by timothy
from the automation dept.
Simon P. Chappell writes "Now, I enjoy a good technical book more than the next geek, but it's been quite a while since one left me quite so excited with the possibilities that it presented. Code Generation in Action is beyond interesting, it is a masterful tome on its subject matter, written by one who is obviously an experienced practicioner in his craft." If "code generation" isn't a familiar term to you, this enthusiastic overview on devx.com is a concise introduction to what code generation is about, though it makes no pretense of ambivalence about its importance as a programming tool. Read on for the rest of Chappell's review.
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.

Summary

This 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

  1. Code generation fundamentals
    1. Overview
    2. Code generation basics
    3. Code generation tools
    4. Building simple generators
  2. Code generation solutions
    1. Generating user interfaces
    2. Generating documentation
    3. Generating unit tests
    4. Embedding SQL with generators
    5. Handling data
    6. Creating database access generators
    7. Generating web services layers
    8. Generating business logic
    9. 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.

This discussion has been archived. No new comments can be posted.

Code Generation in Action

Comments Filter:
  • by burgburgburg (574866) <splisken06 @ e m ail.com> on Thursday September 04, 2003 @12:41PM (#6870088)
    And I can take it or leave it if I please.

    Richard Hell and Codeoids

  • good stuff (Score:5, Interesting)

    by DreadSpoon (653424) on Thursday September 04, 2003 @12:43PM (#6870118) Journal
    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).
    • by SpamJunkie (557825) on Thursday September 04, 2003 @12:48PM (#6870173)
      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 one form or another already.

      Ya, I've done some code generation myself. I used a text editor and my brain. How does everyone else do it?

      I thought about using my wang instead of my brain but he just types screenfulls of the V word.
      • by kisrael (134664) on Thursday September 04, 2003 @03:11PM (#6871656) Homepage
        Ya, I've done some code generation myself. I used a text editor and my brain. How does everyone else do it?

        I thought about using my wang instead of my brain but he just types screenfulls of the V word.


        " V", huh? I feel sorry for your romantic partners. My wang can type " VFR"...
        " VFR4" if I'm really excited.
    • Re:good stuff (Score:3, Insightful)

      by zero_offset (200586)
      Ugh. XSLT is a nightmare.

      We farmed out a project to a company which used a ton of "elite" off-shore resources, and they sent back a project which relied heavily on XSLT. Granted it made sense on paper -- prior to their involvement, the data was already available in XML format. But the net result was a nightmare to debug, maintain, and upgrade. XSLT reminds me of the old saying about APL -- it's a "write-only" language.

      Ok, I concede it's not actually as bad as APL, but it isn't nearly as easy to debug as r

      • Ya, I'll admit XSLT is a pretty hard language to work with in the readability department. Especially if you look at my XSLT scripts in AweMUD, which were my first large XSLT scripts. ~,^

        It probably wouldn't be bad at all to just use a DOM-based parser in Perl or Python or something and use that to generate the output.
        • It probably wouldn't be bad at all to just use a DOM-based parser in Perl or Python or something and use that to generate the output.
          This has been too long of a day. Now I'm thinking about "DOOM-based parsers". Kind of like that old "sysadmin DOOM hack" where you could take out processes with a shotgun, but for code...
    • Code generation is definitely something programmers of large/complex projects should look into.

      Maybe, maybe not. I have used code generation to great effect, by making tiny C files for each of the database tables that provide c structs and simple operations such as insert .

      Why am I doing this? Because there's no high level interface between C and the database. Code generation is often needed because two system just can't mesh comfortably. This is a fault in both systems.

      Let me illustrate with a quote

      • Used it in a web-enabled database setting, as well.

        Created a crude domain specific language where display control and data type are contained in a hungarian-style prefix of a string that is the field's name.

        Had some control information (are we updating/inserting, what table, key field for updates, how many SQL statements) in another string that went into a hidden field.

        Result: a library that transformed the Request.Form collection in one pass into an arbitrary number of SQL statements against arbitrary
    • Object relational bridge packages commonly require code generation or xml files in order to be used. I have been working on one that doesn't use code generation or xml files. My question is, wouldn't developers rather use purely object-based packages, if they could, rather than code generators? I believe purely object-based packages could work for most Object/relational tasks and simple compilers. The code becomes more portable and maintainable and doesn't require the extra training for use of the code gen
  • Software Engineering is not just there yet. It is a nice concept, but not pratical. Rational Rose does it to a certain extent.
    • Nobody is talking about completely automating whole development. But there are two things where code generation helps immensely: 1) "mundane code", like accessor/mutator methods , class/interface definitions, standartized header comments, object mapping - this is covered by generators built into the Rose and similar products. Very helpful. 2) Ability to specify business rules in more efficient form (be it XML, some proprietary language, etc) and generate code appropriate for your framework. This is techni
    • by johnnyb (4816) <jonathan@bartlettpublishing.com> on Thursday September 04, 2003 @01:18PM (#6870464) Homepage
      Actually, it's very much there. It's not a _replacement_ for development, but there are many parts of coding which is benefitted by code generation. I often write tools to write code for me. Once I had to write a color-picker in HTML (VERY repetitive code), so I wrote a code-generator in Emacs Lisp and it saved me several hours. Several implementations of this concept exist:

      * Templating (see Alexandrescu's book on Modern C++ design)

      * Macros for those in the Scheme/Lisp world (these are GREAT and AWESOME)

      * Compile-time programming (only available in LISP as far as I'm aware through the eval-when construct)

      * Custom program-generators

      And then there's the related concept of partial evaluation that, while excellent, has received very little attention by the commercial sector.

      Now, many code-generation facilities could be done better with good libraries, but this isn't universally the case. Delphi is probably the best at putting in libraries/properties what others put in code generators, and their software is much easier and better because of it.

      Macros and compile-time programming are two of the best ways to do this, but Scheme and LISP are the only ones that do this reasonably.
      • Amen to LISP/Scheme macros. Java and C++ have reimplemented so many other Lisp ideas you wonder why attention never turned to the preprocessor. After 15+ years of C++/Java and OO we would still all be better off programming in Lisp.
      • Compile-time programming (only available in LISP as far as I'm aware through the eval-when construct)

        Also possible with template meta-programming in C++, which is one of the reasons recent expression template libraries and their ilk are getting such good performance.

        • Not to the same degree it is possible in Lisp. For example, in LISP, I can actually, say, read a file into a variable for compilation. With C++ I would have to read it at run-time, even if it's completely static.

          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
    • I've spent the past 7-10 years working with different code generation approaches. My latest R&D efforts meld a variety of the techniques I'd used in previous efforts to provide a code generation engine that has proven flexible enough to produce RDBMS schema scripts, C++, Java, etc.

      Even better, I've been able to work towards a higher level abstraction which allows me to change the architectural "glue" while maintaining a consistant application developer API. (i.e. Choose amongst different RDBMS serv

  • by Trigun (685027) <evil@nOSpaM.evilempire.ath.cx> on Thursday September 04, 2003 @12:46PM (#6870147)
    Code generation is a time-saving technique that helps engineers do better, more creative, and useful work by reducing redundant hand-coding. In this world of increasingly code-intensive frameworks, the value of replacing laborious hand-coding with code generation is acute and, thus, its popularity is increasing.

    Why not put a little bit about code generation in the review. Even a little blurb like "It builds the mundane portions of coding" would have helped out a bit.

    • Eh? This is different than I would expect. In the "formal" computer science definition would be something like generating code (often times machine code or byte code) in compiler context.

      Also, in computer software design, it has another definition. Namely: Generating real code (C, C++, Java, whatever) from design templates (like from UML).

      Now, these people are overloading the same term?? These make me even more confused.

    • by register_ax (695577) on Thursday September 04, 2003 @02:00PM (#6870944) Journal
      I concur.

      [rant]
      What the hell is up with these book reviews? I equate book reviews with SCO. All I see is a large body of reviewers making unsubstantiated claims to a book that tickled their fancy in a personal sort of way. They say basically, "this book tickled a nerve, but I will not say what I already know that led to that nerve being in place already." Of course it turns out then to be some haphazard therapy session where the reviewer begins to delve into themselves while completely ignoring their audience!!!

      OK, I know /. may not be extremely high with the English majors, but how about we don't post such things submitted by such arrogant posters? (is it possible?) I don't claim myself as being a master of prose, but you won't see me trying to do something I knowingly can't.

      One more point, the reviews most commonly given are little more then amazonian [www.amazon] reviews. They rave about how great something is, realize that only constitutes of 2 senteces, and proceed with immediately filling in the blanks with worthless prose to create content.

      And lastly, I don't receive book reviews on my main page because of their vapid nature. This means that /. is losing on my potential business. I would love to see them prosper, but they have to create something that is interesting. Slashdot is all about bringing the obscure to the masses, but I hardly see that through their book reviews. What is the freakin deal with OReilly's cookbooks? Are there any really, really bad OReilly books at all? We all have hordes of them or wish we had complete collections. We know what a cookbook is and they don't really differ that much between subject.

      I am trying to prove a point here, that reputation and common sense through the title allow for little differentiation between your preconceived notions about the book and what the book is realistically about. I want books to come to the forefront from the dirges, such as the recent classic The Elegant Universe: Superstrings, Hidden Dimensions, and the Quest for the Ultimate Theory [amazon.com] (Feb 2000) by Brian Greene, or "been around the block more then once" Men of Mathematics [amazon.com] (June 1937) by Eric Temple Bell. My point being, either book is known to those in the "know," but is rare to be known by budding scientists (high school students) and younger folk. I won't let this branch off into a rant in poor public schooling and child upbringing. I only want to see objective viewpoints of why the book may be helpful to me, not why it made you change your perspective on life! FSCK!
      [/rant]

      Thank you for being patient.

  • by Anonymous Coward
    This book looks like a poor excuse for management drivel! If we could just get rid of those pesky programmers ... ah! Code Generation! Couple this with the move to push everything offshore ... and voila! no more pesky programmers. Now if we could just get them to finish the powerpoint compiler the development team was working on .... PHB
  • by Anonymous Coward on Thursday September 04, 2003 @12:52PM (#6870221)
    And Lisp has been doing it for years, as has, to a lesser extent, C++ (and Ada) templates. And the good thing about Lisp metaprogramming is that it is in the one language - lisp.

    Having 1 language generating another - Ruby and Java - is the recipe for confusion and complexity.
    • by Anonymous Brave Guy (457657) on Thursday September 04, 2003 @03:09PM (#6871629)

      Yeah, honestly, these upstart newbies yaccing on about code generation as if it were some sort of new idea. Lex think for a minute and bison other books before we get carried away, shall we?

      (And "active code generation" used to be called "high-level languages" and used fairly often by stronger programmers who didn't like cut-and-paste. Maybe that's not buzzwordy enough any more, though.)

    • Having 1 language generating another - Ruby and Java - is the recipe for confusion and complexity.

      Yep. Just take a look at C++: the "regular" language and templating language are very dissimilar, making it very difficult for someone to understand someone else's "clever" template.
  • Wild (Score:3, Funny)

    by mao che minh (611166) * on Thursday September 04, 2003 @12:53PM (#6870233) Journal
    "Code Generation in Action"

    They make the visual of some pale, skinny nerd with a "Got Root?" shirt on, banging away on a keyboard in a poorly lit dorm room sound exciting.

  • by Fnkmaster (89084) on Thursday September 04, 2003 @12:54PM (#6870240)
    But we built a very large code generation system as part of my old company's electronic trading system. It used the JavaDoc system and a custom JavaDoc parser we built to generate oodles and oodles of very repetitive code from the base business objects, such as XML parsers and translaters and the like. It was a big time saver, undoubtedly. The big problems we had were versioning and its interaction with our build system, and more importantly, the fact that the code generator itself becomes very complex to read, such that only one or two developers are capable of making changes to it.


    My rule of thumb is if I find myself writing code that bores me silly and thinking "a frigging monkey could be taught to code this piece", I will strongly consider writing a program to write the program for me. Be warned about the maintenance and readability issues though in larger development projects where there are a lot of mediocre programmers around. You can always assign those mediocre programmers to hack on monkey-easy code, but you can't get them to hack on a code generator, so carefully consider the nature of the development organization you are dealing with, and the tradeoff between available "high-value" time and resources vs. "low-value" (i.e. monkey coder) time and resources. This perspective has been brought to you by my pointy-haired side.

    • You might want to check out XDoclet [sourceforge.net] next time rather than write your own parser/generator. It's pretty widely used now and has lots of tags for many common uses like EJBs, Hibernate, web.xml generation for all the major appservers, etc. It's also integrated with Ant and it looks like Sun is going to be borrowing some ideas for use in Java 1.5+.
      • Well, we used XDoclet as well. Actually, it was EJBDoclet originally, back when we started using it - this was several years back, mind you. EJBDoclet became a subset of our build system. But our custom JavaDoc modules wouldn't really have benefitted much from anybody's framework, honestly, and we had by then 90% decoupled our system from the EJB way of doing things. For example, we auto-generated EJB session beans that used direct DB access for bulk updates and retrieval, because entity beans were insa
      • XDoclet is awesome, but it makes a fundamental mistake IMHO. XDoclet requires that you embed specific technology dependencies into your app's source code. The javadoc tags are specific to EJB or JBoss or whatever, so if you ever want to switch to a different tech for something you have to clean out the old tags and insert the new tags into every file. That's exactly what things like EJB have been trying to avoid, and as with EJB, XDoclet doesn't quite get the job done.

        Instead, XDoclet should let you speci

    • There's an open-source implementation of a very similar generation system living at http://sandboss.org [sandboss.org]. It does everything from bean classes to database schemas, and unlike many code generators it's not tied (implicitly or explicitly) to any particular output like EJBs or XML. Although written in Java, the underlying generator architecture is designed to spit out C code just as happily as it spits out Java. The Sandboss generator infrastructure is part of a larger framework for building message-based enter
    • If the complexity of your generator is too much for people to maintain, it sounds like you're still working with ad-hoc hard-coded generators. It's helpful, but as you say, it creates a whole new set of code to maintain.

      There are better approaches.

  • by gbvb (304328) on Thursday September 04, 2003 @12:55PM (#6870241)
    if you ever read the "Pragmatic Programmer" book about software developer practices, it mentions that they used code generation for many things. Code generation definitely helps when you have many similar but not same implementation.. But, in Java or any other object oriented languages, inheritence can be used to avoid similar looking code (which is what code generation would do).
    But, even here, I think the UI pages, or template based generators definitely help. There was a tool by DevelopMentor which used to generate code for ATL. It was based on templates..
  • by GillBates0 (664202) on Thursday September 04, 2003 @12:55PM (#6870244) Homepage Journal
    I've been doing R&D work with compilers (Ada/C(++)/Java(bytecode generators)) for quite a while now, and the first thought that occurred to me was that this is an article/book about the code generator pass in compilers.

    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.

    • Except that you could apply the same techniques to create c/c++ source files, header files, etc. The whole concept is to create a "tiny compiler language", that does the job you want it to do. Heck, you could even generate assembler if you wanted.

      It's about bringing the power of #include and #define to other environments, as well.

      Remember, programs that write programs are the happiest programs in the world.

    • A code generator is a compiler. It takes some source and produces an implementation of the source using a more primitive language.

      I wrote a code generator for EJBs. The template that was passed in was very much the source as a very high level language. The output was Java code.

      I wrote a Pascal compiler for a virutal machine. The source taken in was Pascal, the output was VM code.

      The two were very similar except the gramar for the code generator was much simpler so I didn't need a complex lexical parser.
    • by kmo (203708) on Thursday September 04, 2003 @02:03PM (#6870969)
      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.
      I think you're being too fussy. Anything that generates code can reasonably be called a code generator. You are just most familiar with the backends of compilers.

      Code generation can allow a developer to compensate for missing abstractions in the underlying language or architecture. For example, it's almost trivial to write generator for a Java type-safe enum class [sun.com]with a couple of pages of java tied to a Velocity [apache.org] template for an enum. You just have to be sure that your build process regenerates the class if your input changes. The input could be something as simple as
      color {red, green, blue}

      It's then easy to add features to your enum infrastructure that aren't in Bloch's class and have them show up in all the project enums (like correct serialization and localization).

      The GUI builders that spit out code fragments are just the tip of the iceberg when it comes to code generators. Imagine a utility that could generate the plumbing to make EJB or RMI methods directly accessable from a Windows DCOM client, without it knowing or caring that it's talking to Java on the other end.

      Or automatically generating classes for Customer, Order, and Product from an existing database table, and seamlessly loading, caching and saving their instance data without the application knowing or caring that it is persistent.

      Automating this sort of tedious programming is what code generation is all about.
      • Code generation can allow a developer to compensate for missing abstractions in the underlying language or architecture.

        Thank you; that was the most insightful comment I've seen here all day.

        Code generation, like design patterns and such other trendy things, is just a technique you can use with weaker languages or designs to gain some of the power of stronger ones, if you don't have the option to use something more expressive directly. As such, it merits serious consideration as a tool in the toolbox,

    • Don't get your panties in a bunch! :)
      I remember when Microsoft was launching all of their visual programming products. Visual programming purists complained (correctly) that these products had nothing to do with visual programming- they were just IDE's that included visual form designers.

      The more obscure definition is going to lose. But guess what- it doesn't really matter.

      Like Juliet said, "What's in a name? That which we call a rose/By any other word would smell as sweet."
    • I do compiler work too, and I think you need to relax a bit. The term "code generator" means "some device that generates code". Just because you misuderstood it at first (as I did) doesn't mean it's wrong.
  • I wrote a generator that took a sql file and generated a light java database persistance layer. My reasons for doing this, in Ruby and not Java ,boiled down to the horror of manipulating Strings in java vs. the ease of it in Ruby.

    The other advantage using one language to generate another is that there is less confusion about what code is part of what. In my case I had ruby in the generator and java and MS sql in the text blocks that were being generated so it was easy tell thing apart.
  • Am I FUD? (Score:2, Insightful)

    by mcc (14761)
    Code Generation is for people who don't understand or are too lazy for abstraction, and it will ALWAYS have the problem of, what if you want to go through all your projects and change one single thing about the generated part of your code? What if you have a hundred tiny projects, each of which contains the generated code snippet that needs to be changed? Let's hope either the change you want to make is very simple or you are very good at regular expressions.

    If you are able to clearly separate your code in
    • Code Generation is for people who don't understand or are too lazy for abstraction, and it will ALWAYS have the problem of, what if you want to go through all your projects and change one single thing about the generated part of your code?

      While I completely agree with your statement, I don't think it wholly applies to cases where you are using code generators to do things like generate an XML config file, or other such cases where you are using different technologies that don't talk to each other well. X

    • Re:Am I FUD? (Score:3, Insightful)

      by querencia (625880)
      Code Generation is for people who don't understand or are too lazy for abstraction

      The article that timothy suggested as background reading ( here [devx.com]) points out that code generation is most useful when you're forced to use a framework that requires lots of simple-minded "scaffolding-style" code. EJB is the prime example.

      In other words, I agree with you --- if code generation is useful, it's probably because the infrastructure you're using was poorly designed. But that doesn't mean you don't have to u
    • Re:Am I FUD? (Score:2, Interesting)

      by eggsurplus (631231)
      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).
    • Re:Am I FUD? (Score:5, Insightful)

      by smagoun (546733) on Thursday September 04, 2003 @01:44PM (#6870745) Homepage
      You're assuming you run the generator once, and that's it. That's what many people do, and it's wrong. The generator should be part of the build cycle. If you want to change the generated code snippet, change the generator!

      While I agree with you in principle - that better abstraction is usually the way to go - that's not always possible in the real world. For example, sometimes you have to produce an API for someone else, or hook up to their API. In those cases, better abstraction isn't always an option. Sometimes your boss says "you're using EJB" and you're stuck with it. In those cases a generator can be a big help.

      The cool thing about integrating a generator into your build is that you get the benefits of abstraction without many of the drawbacks. The generator becomes your abstraction, so you can make modifications in one place. Sure, using a generator requires a little more thought than cut-n-paste. So does proper abstraction. The two aren't all that different, and both approaches have their place.

    • by tmoertel (38456) on Thursday September 04, 2003 @02:22PM (#6871157) Homepage Journal
      mcc wrote:
      Code Generation is for people who don't understand or are too lazy for abstraction ...
      Baloney.

      Code generation is a practical, efficient tool for solving many problems where OO-style abstraction need not enter the picture. One such class of problems is building interfaces and glue code from external specifications.

      A few years ago, I wrote a simple code generator that reads the SQL DDL for a large database and generates an object-based interface to the database. Client coders could then use the object-based interface to access the database. The advantages of this approach proved to be numerous:

      • Single, authoritative reference specification. The object interface was always in sync with the reference, which for this project was the database schema.
      • Richer compile-time error detection. The projection of the schema into the object interface was fully available to the type system so that many kinds of client errors could be caught at compile time, not run time.
      • Reduced opportunity for errors between subsystem boundaries. Because the object-based interface was generated by machine from the actual database -- and not derived from some programmer's understanding of the database -- there were fewer opportunities for impedance mismatch across the boundaries of the application code and the database. (Studies of errors in complex projects have shown that errors are more common between subsystem boundaries, and so this benefit is important.)
      mcc further states:
      But I cannot think of any case in an object-oriented language where it would be both less work and more maintainable to write a code generator than to just abstract away the parts that would be auto-generated.
      If you can't think of any such cases, it's because you're thinking too small. Look at the bigger picture. For starters:
      • When the number of variables affecting the desired code characteristics is large enough to make hand-coding (at any level of abstraction) impractical. E.g., FFTW [fftw.org]: "FFTW uses a code generator to produce highly-optimized routines for computing small transforms."
      • When your code must conform to an external reference specification that changes rapidly enough to make hand coding (at any level of abstraction) impractical. (See my example above.)
      • When the requirement for correctness is so stringent as to make hand-coding methods impractical, mandating code generation from a formal specification.
      • When you must target an output language whose native abstraction capabilities are too crude to capture directly the degree of abstraction that is merited. Believe it or not, most popular OO languages fall into this category for many commonly occuring problems. Hence the popularity of design patterns. (Compare, e.g., with the abstraction capabilities of modern functional programming languages like Haskell [haskell.org] and O'Caml [ocaml.org].)
      Make no mistake about it, code generation is a practical, effective tool that every programmer should understand. To dismiss it out of hand is a costly mistake.
      • OK, I'm clearly of the opinion that a lot of "code" should be descriptive instead of procedural. It just doesn't make sense to explain the steps to create a GUI, when you can simply describe how it should look and act, and have the computer figure out how to best implement it. (Of course the actions bound to events would generally have procedural code behind them.)

        But I'm not very clear on the advantages of code generation versus descriptive code. One example I like to use is glade versus libglade. The ad

    • Yep, you're FUD if you have ever used a compiler.
    • Ummm - how does this differ from just building class libraries for the redundant stuff, and instantiating objects? (or building subroutine libraries, and including and calling the functions from your programs?)

      Seems like 6 dozen of one, and 72 of another...
    • Re:Am I FUD? (Score:3, Informative)

      by ketan (3574)

      Code Generation is for people who don't understand or are too lazy for abstraction, and it will ALWAYS have the problem of, what if you want to go through all your projects and change one single thing about the generated part of your code?

      I take it you've never used a compiled language? In an abstract sense, that is a code generation. Actually, so are interpreted languages: you give them a high level expression and it turns it into executable code that it runs for you instead. Have you ever set up a

  • I use XDoclets a LOT. I mean A LOT. It does some really cool stuff for us, from dealing with MBean interfaces to just about anything else that you can think of.

    It's also very tightly integrated with ant [apache.org] and maven [apache.org], the two build tools that are used in just about every project I'm involved in.

    You can find out more about it here [sourceforge.net].
  • Ruby not Java (Score:5, Informative)

    by Colonel Panic (15235) on Thursday September 04, 2003 @01:07PM (#6870363)
    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..., but with the majority of the code-generation examples being for Java-related technologies, I wonder why Java was not selected instead.

    I think the author makes it pretty clear why he chose Ruby instead of Java. Essentially, in order to parse text (which is one of the primary functions in code generators) you would have to write 2 to 3X more code in Java than you would in Ruby. Java is not an optimal text parsing language - first off you have to find a regex engine for it. That leaves you with choosing one of the scripting languages: Ruby, Perl or Python.

    Here's what the author says about the cons of using Java for code generation (page 41):

    * Java is not ideal for text parsing. (I would agree)
    * Strong typing is not ideal for text processing application (again, I would tend to agree, strong typing only gets in your way)
    * The implementation overhead is large for small generators. (you'll be writing a lot more java code than you would in Ruby to get the same thing done)

    Overall, I'm finding it to be a great book, and the use of Ruby for implementing the examples is a plus as far as I'm concerned.

    As far as integrating Ruby into the build process goes, I recall hearing something about a project that uses Ruby to drive Ant.
    • Find a regex engine for Java? You mean like the one that is included in JDK 1.4?
    • Java is not an optimal text parsing language - first off you have to find a regex engine for it.

      Like, for instance, the built-in java.util.regex package?
    • That leaves you with choosing one of the scripting languages: Ruby, Perl or Python.

      Why is it that when the term "scripting language" is brought up, PHP is so universally forgotten?

      It's excellent at text parsing, (which is its native purpose) widely supported, and incredibly flexible.
      • Re:Ruby not Java (Score:3, Insightful)

        by spRed (28066)
        PHP has nothing to do with text processnig. It is highly specialized as a page-based web language.
        That makes it great for small dynamic sites (which it is frequently and effectively used for) and crap for everything else.

    • Re:Ruby not Java (Score:2, Informative)

      by aziegler (201013)
      Earlier this year, I helped review this book during the publication process. At one point, the question was raised whether Ruby was the "ideal" language for this. In my opinion, the answer is "absolutely yes." Ruby -- and Python, if you can get past its syntactic oddities that I can't get past -- is "executable pseudo-code."

      -austin
    • This hourly build [ultralog.net] is driven by Ruby and Ant for the exact reasons that you mention - Ruby's great at parsing text (or XML using REXML).
  • by msuzio (3104) on Thursday September 04, 2003 @01:10PM (#6870385) Homepage
    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 [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 ;-).
  • not impressed. (Score:3, Insightful)

    by Pinball Wizard (161942) on Thursday September 04, 2003 @01:11PM (#6870402) Homepage Journal
    As engineers we build time-saving applications for others but never think to apply the power of computers to our own problems.

    Huh? Software engineers use more software than anyone else. We have tools for our tools. I found the above statement bordering on the ludicrous, and almost stopped reading at this point.

    Code that is copied and pasted to multiple places is difficult to maintain properly across all of the copies. Active code generation does not suffer from the same maintainability issues as copy-and-paste coding. When you need fix something, you apply the bug fix to the templates used to generate the code, which then propagates the fix to all of the code maintained by the generator. This design ensures that no code that needs fixing is left scattered around and forgotten.

    That's why we use functions and classes. Then, when you change your function, the changes are magically propagated to all the places in your code where that function was called! Copy and paste programming has been frowned upon pretty much since the days when the goto was declared bad programming practice.

    It really sounds like this book is just putting on a fancy name for an incomplete set of good programming practices. Really, what is covered here that Design Patterns doesn't cover in a much more thorough and professional way?

    • Obviously you understand that it would be just silly of them to push copy-paste practices so what do you suppose they meant?

      I'll suggest that they probably meant copy-paste-modify rather than just copy-paste. Very similar code is necessary in places like the db abstraction and object mapping layers for db backended apps and while the code is very very similar (ie, every single object needs to know how to add/update/remove/retrieve itself from the database), the individual elements and table layouts are di
    • That's why we use functions and classes.

      That's true, but functions and classes don't express all, or even most, of the patterns that are present in our applications.

      See "Aspect Oriented Programming" (google for it) for a set of extensions to some common languages. By seeing the problems they solve, you should get a better idea of what things functions and classes can, and cannot, solve.

      -Billy
  • by Dr. Zowie (109983) * <slashdot@defor e s t . o rg> on Thursday September 04, 2003 @01:11PM (#6870403)
    The obvious case is a generator that writes "C" code -- after all, "C" was intended as just a metalanguage like Gnu's RTL, but for the earlier BCMP compiler. It's arguable that generated C code is more true to the spirit of the language than is hand-coded C code.

    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.

  • Heck, I've been doing this for years, generally in the area of test automation.

    There are usually two cases:

    1. The need to automate the generation of some type of code or script for a large number of test cases, where the scripts would otherwise be generated manually.

    2. The need to generate tests to excercise implementations from what can best be described as a machine readable description of interfaces and exchanged data types.

    The second case is rather interesting in that all the information in most

  • by russotto (537200) on Thursday September 04, 2003 @01:12PM (#6870408) Journal
    I work on a large Java project where we use entity EJBs. Code generation isn't an _option_ here, it's a necessity. We have hundreds of tables (over 500) and each of them has an EJB. Writing out the infrastructure for each and every one by hand would be a huge and boring waste of time. I think the necessity for code generation actually points to a problem with design of EJB itself, but that we're pretty much stuck with.
    • by BigGerman (541312) on Thursday September 04, 2003 @01:33PM (#6870617)
      there is a _huge_ design problem with EJB.
      To me it manifests itself in the ass-first design:
      if I work with a framework, the typical scenario for OOP would be: framework provides interface, I implement it with my classes so they can play in the framework.
      With EJBs, it is another way around: you define an interface and the container/framework creates classes and implements your interface for you!
      Code generaton became so popular with J2EE for this very reason: there is _always_ a step where you need to produce a lot of redundant EJB artifacts so you might as well automate it.
  • by brooks_talley (86840) <brooks@frn[ ]om ['k.c' in gap]> on Thursday September 04, 2003 @01:15PM (#6870437) Journal
    ...it's really important to use them properly. "No pretense of ambivalence," indeed! What, are reference materials supposed to be ambivalent?

    From http://www.hyperdictionary.com/dictionary/ambivale nt :

    1. [adj] uncertain or unable to decide about what course to follow; "was ambivalent about having children"
    2. [adj] characterized by a mixture of opposite feelings or attitudes; "she felt ambivalent about his proposal"; "an ambivalent position on rent control"

    Is that really what anyone would expect from a reference material? I think the poster wanted "...no pretense of objectivity."

    Not that I care that much, of course.

    Cheers
    -b
  • by Rogerborg (306625) on Thursday September 04, 2003 @01:17PM (#6870457) Homepage

    I worked at a telco where we generated C code on the fly from high level Structured Definition Language [etsi.org] for the main call control processing.

    It was a great idea... in theory. In theory, it was impossible for the implementation to get out of sync with the detailed design (the SDL). In theory, there's no difference between theory and practice, but in practice there is. Some of the features that we had to add simply couldn't be modelled in SDL, plus there were performance issues, and it produced ugly source.

    It was used for fifteen years (yeah, pre-ANSI), but it eventually collapsed under the weight of all of the hacks that were required to work around the limitations. We eventually had to admit that the behaviour of the complete source (generated plus all the stuff around it) was now so different from that defined by the SDL that it was no longer worth putting up with the limitations of the SDL.

    In the end, we just took a snapshot of the generated code and set developers free to actually fix it rather than hack around it. At that point, there were only a few people left who even knew SDL, so there were very few tears shed. The rest of us cheered, and the product got significantly cleaner as we refactored the bejeesus out of all the generated C and removed the hacks.

    I'd recommend giving code generation a try, but don't be ruled by it. Once the product is mature, if the code generation is limiting you, then don't be afraid to drop it and fix the lower level generated code.

  • Most of the examples of code generation I've seen around are basically kludges around insufficiently powerful high-level programming languages. Datatypes and representations should be able to be generic in the programming language; this enables directly coding at the desired level of abstraction. Check out ML or Haskell for one cut on these ideas.

    That said, I've been doing CG for a long time :-). The M4 macro preprocessor is a fine tool for this task. See e.g. my student's M4 CG for XCB [pdx.edu]: a classic exam

  • by pb (1020)

    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.

    Try writing it in Java, and I'll wager that you'll find out why. It'd probably be quicker to write a code generator to write it for you. Use the right tool for the job.
  • 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?)

    Just a heads up about integrating Java and Ruby:
    There is a tool called rjni (Ruby JNI), from the README:

    "What is rjni?

    rjni exposes the Java Native Interface to Ruby. This allows the programmer to instantiate Java objects, manipulate them, def
  • by KenSeymour (81018) on Thursday September 04, 2003 @01:28PM (#6870552)
    A quote from the Sun web site:

    J2EE technology and its component based model simplifies enterprise development and deployment.

    But now I hear that we need code generation to keep up with all the mundane tasks made necessary by the use of EJBs.
    So we build a code generator and we have to maintain that.

    This is on top of all the J2EE design patterns you are supposed to do because the world would come to an end if you just accessed a database table using JDBC directly.

    Once in a while someone should look at the assertion that it would be harder to maintain a lot of imbedded JDBC code in your application than it would be maintain the 5 or so classes you need for each business object in order to maintain architectural purity.
  • by SWPadnos (191329) on Thursday September 04, 2003 @01:34PM (#6870626)
    For those who are saying that the term "Code Generator" isn't applicable - it is. Consider a C++ compiler. It may generate asm code, which then gets converted into machine code.

    (generic) C++ -> (specific) asm -> executable bits

    (obviuosly, the C/C++ compiler doesn't need to generate asm, but it's still code generation if it does)

    Code generators just take this a level higher, so the code "life cycle" looks like this:

    (generic) Diagram / CG description -> (specific implementation) C++ -> (specific machine) asm -> machine code.

    Code generators have a great potential for easing coding and documentation. Just like GCC has many backends to generate code for different processor architectures, the code compilers can have different backends to make source code in different languages (C, C++, Fortran, whatever). Even better, you can run a different translator and get documentation out of the "source" - in HTML, DocBook, XML, or any other format you want.

    There are tools to let you make UML diagrams (Google for "Executable UML" for great goodness), and generate real-time C code for an application, a C++ app simulator that runs on a PC, and documentation for the system, all from the same diagram. The tools are expensive (like $15k-$30k), but for large projects, they can be a great savings.

    I saw a program called BridgePoint (from Project Technologies [projtech.com]), which was able to generate embedded, real-time code that was as efficient (more in some areas, less in others, but it averaged out the same) as hand-optimized code done by expert programmers. It all depends on how goo dyour translator is (and this program lets you write your own).

    Some books on the subject:
    "Executable UML: A Foundation for Model-Driven Architecture", by Stephen J. Mellor and Marc J. Balcer
    "Executable UML: The Models are the Code", by Leon Starr
    "Real-Time UML: Developing Efficient Objects for Embedded Systems, Second Edition", by Bruce Powel Douglass
  • true story (Score:3, Interesting)

    by geekoid (135745) <dadinportland @ y a hoo.com> on Thursday September 04, 2003 @01:35PM (#6870635) Homepage Journal
    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!"

    • I wrote a 'software generator'. It worked so well, they laid of 3 coders, and yes I was one of them.

      Gawd, that sucks.

      Can you share any details?
  • Could be a little OT...

    Generating a lot of repetitive code can be done by the computer, but can't that be taken care of at a layer that the end user need not worry about -- by defining the higher level concepts at the language level?

    Here is an example: In Perl, there is a module called Class::ObjectTemplate. It is a template that can be used to define classes. A code can work as follows:

    package MyClass;
    use Class:ObjectTemplate;
    require exporter;
    @ISA = ("Class::ObjectTemplate");

    attributes("a", "b", "c", "
  • by spideyct (250045) on Thursday September 04, 2003 @01:49PM (#6870800)
    The .NET Framework has great built-in support for code generation [microsoft.com], 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.
    • ... people round these parts don't take kindly to any positive talk bout things from redmond.

      yer liable ta start a fight with that kinda talkin.
  • Object relational bridge packages commonly require code generation or xml files in order to be used. I have been working on one that doesn't use code generation or xml files.

    My question is, wouldn't developers rather use purely object-based packages, if they could, rather than code generators? I believe purely object-based packages could work for most Object/relational tasks and simple compilers. The code becomes more portable and maintainable and doesn't require the extra training for use of the code gen

  • by evilpenguin (18720) on Thursday September 04, 2003 @02:16PM (#6871105)
    Metaprogramming can be a useful and time-saving technique. It can also really mess up maintenance and future refactoring of a project. The time saved one developer isn't a good measure of the utility of a technique.

    When I first learned lex and yacc, I got tempted to turn every single useful C/C++ library into a scripting language. "Think how much time I could save!" I thought.

    Well, while I still think developing an application specific language (to basicially make pseduocode functional) is an occasionally useful technique, what I found was that it usually made project transfer and maintenance more difficult and more expensive.

    Using XML and XSLT to do the same thing as lex and yacc doesn't inherently add much. The exception would be the evolution of an industry standard DTD for, for example, common UI constructs. I can see value there. But rolling your own metaprogrammer strikes me as rarely of real benefit. The metaprogram becomes another thing that must be documented, explained, maintained, and transitioned. It adds something that may not be easy to integrate into a present or future automated build process.

    I guess I'm coming down firmly on both sides here. My point is that the cost/benefit analysis for a single developer doesn't necessarily align well with the cost/benefit analysis for the project as a whole. I think we have all seen projects that are in "tool and library hell" where developers have included their favorite libraries and tools willy-nilly (a technical term I like very much -- so concrete, so precise) so that no one can actually get the project to build. The GnuCash project was like that for the longest time (and it is still a bit messy if you ask me).

    Faster isn't always better or cheaper.

    In other words, I have seen metaprogramming do more harm than good in my experience. And the few successes come when the metaprogrammed portion was well analyzed and understood, and a standard could be made that would apply to an entire enterprise and not merely to a single project. More often than not, the inclusion of metaprogramming became the first reason to rewrite an application -- no one wanted to figure out or maintain the metaprogram. So they chucked it.
  • by game (62990) on Thursday September 04, 2003 @02:17PM (#6871117) Homepage
    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.
  • I started writing Visual Basic programs that generate VHDL code about 8 years ago. If I could get my act together and tighten up (read: productize the GUI) the program that generates Viterbi decoders, I could probably sell the thing.
  • Code Generator, n.: A program for generating code that is buggier than itself.
  • Code generation can have a legitimate place. I guess there are two logical ways to use it. Given a processor that transforms "metasource" into "source", either you maintain the metasource and never hand-edit the source, or you run the generator just once to create a rough framework, and then discard the metasource and maintain the source. I've done both, saving time and aggravation.
    But code generation can be a sign that the wrong language is being used. The author recognizes this, but points out that
  • by heironymouscoward (683461) <heironymouscoward@yahoo. c o m> on Thursday September 04, 2003 @05:29PM (#6873397) Journal
    Is GSL (aka GSLgen), part of the RealiBase OSS toolset from iMatix [imatix.com].

    Yes, I'm biased, I use it extensively. Extensively.

    Write your metamodel in XML, build code generation scripts, generate anything from interfaces to database layers to entire applications.

    I took some of the examples from CGIA (which is an excellent book, I read it and I like it and I recommend it heartily) and converted them to GSL - simpler, clearer, more obvious.

    If you are a professional programmer you need code generation. This is simply a basic technique, like editing text with a visual editor and not edlin. And of all the code generation tools out there, GSL is by far the most flexible and powerful, mainly because it was designed from the ground up, and has been used and evolved over about 10 years specifically as a code generation tool (unlike XSLT which does the job but with more weight and less elegance).

    In my journal, I include a GSL script that generates a complete C interface layer for MySQL, turning a simple description like this:

    <table name = "history" description = "Message History" >
    Holds all messages received and sent. The command and body are parsed
    from the smstext.
    <field name = "id" domain = "recordid" >Record id</field>
    <field name = "groupid" domain = "id" >Parent group</field>
    <field name = "userid" domain = "id" >Parent user to/from</field>
    <field name = "incoming" domain = "boolean" >Incoming message?</field>
    <field name = "appl" domain = "msisdn" >Application MSISDN</field>
    <field name = "text" domain = "smstext" >Message text contents</field>
    <field domain = "audit" />
    </table>

    Into a complete abstract interface.

    Whatever: code generation is a cult technique that deserves a place at the center of every serious developer's toolbox, and this book is possibly the first one that I've seent that may achieve this.

    Enjoy.

There's a whole WORLD in a mud puddle! -- Doug Clifford

Working...