Generating Code vs. Generating Applications

This started off as a comment to Steve Bryant's response ("On Code Generation") to my article ("Build a Code Generator in Five Easy Steps") but it got out of hand - yes, I am verbose, sue me.

First, I want to thank Steve for the link. He offers some interesting ideas. There are many paths to code generation obviously, and I only described how I did it, not how it must be done. Here are some of my thoughts to his suggestions...I like the use of the AdminAPI because it allows me to load the datasources when the app starts, which means that Flex also automatically populates the tables field which works nicely. It is true that it is not necessarily a required step.

DataMgr is an interesting option for getting the metadata and one I had not considered, though one way or another you still need to get metadata on whatever RDMS's you intend to support.

I also agree with Peter Bell that their are significant limits to using db metadata. It provides simply a limited starting point based only upon what the database knows - which is data type and size...it knows nothing of meaning or intent. XSLT also has significant limitations for round-trip code generation, thus my generator is designed to generate once and customize by hand.

I also want to address one issue because when speaking of ColdFusion and code generation, Peter Bell's name inevitably comes up (and for good reason). However, I think that when comparing the generator that Peter Bell is building to what I am building is a difficult one and can lead to some confusion. I am not picking on Steve for bringing this up, I am just taking the opportunity to add some clarification to my point of view when it comes to such comparisons.

Peter is building what he has referred to as a "software product line" where he builds upon the commonalities between his client projects and creates more meaningful metadata and ways of specifying a limited set of differences between his projects. By limited I am not implying a small set, just that in order for his generator to work it can only generate differences where there is an established means to specify them...thus their is always an inherent limit to what can be specified and new differences will require changes to the generator codebase - this is not the case with hand coding obviously. The overhead of building such a system is immense (I think Peter would freely admit that since his product is still a work in progress) and far beyond the scope of the day to day development work being done by most developers.

Another important distinction is that it also only takes into account a specific application architecture - for instance, in my current position we need to focus on Flex integration and java/WebLogic integration among other things - this isn't accounted for by default in the code generation that Peter discusses because it is likely not applicable to the applications he is building. This is not to say that a generator of the sort Peter speaks of couldn't be created to accomodate these architecture requirements (and others) but as I have stated this is no small task.

I am not saying this to be critical of Peter's work; I have been a big fan of his work for some time. I just think it is important to distinguish between the two very different paths to code generation - in fact, Peter calls his "application generation", while my generator is by no means generating an application...just some basic code that isn't even intended to "work" out of the box but is intended as a head start to your hand-coded application.

Brian, Good comments. Just to clarify, I think the way I generate code is much closer to your approach than Peter's. I tend to generate starter code for an application rather than the more auto-generated application that Peter is aiming for. I still think his observations are valuable for any code generation - though I agree that it is important to note the distinction and I think this entry does a good job of that.

@Steve, Didn't comment directly on your post as I had little to add, but enjoyed it. Nice to see continuing discussions as more people start to generate more of their code! Only small downside with using DataMgr (which I am still considering seriously) is that it won't do a full Diff on columns as it can't handle modifying the data type of an existing field. However I think it is a great system and it is only because I like to get my hands dirty that I'd even consider writing my own db gen piece - I'd recommend Datamgr as the default approach and will blog on that to add another voice as it is a great out of the box solution! @Brian, I completely agree with your core point and would only make one tiny distinction. Firstly, you're right. I call it application generation to distinguish it from code generation. The difference is intent. To me someone who is engaged in application generation is trying to almost eliminate hand coding. Someone who is generating code is trying to save some typing and improve consistency in their code base. Real world is usually somewhere on that continuum. As for the difficulty of creating a Software Product Line, I am developing approaches to make it easier. A combination of Layered Programming and Agile Application Generation which will make the techniques lighter weight and more applicable. In part this has taken me so long because some of the stuff I'm working on is fairly bleeding edge (such as design of evolvable Domain Specific Languages and patterns for DSL refactorings which are more PhD research topics than well understood fields) so it's more work than it would otherwise be. I would also say that the kind of integration issues you are focused on would simply modify the Domain Specific Languages to some extent and the templates used extensively and I'm hoping to publish a book end of Q1 on how to do all of this stuff (and how to figure out when it is worth the effort). However, I still love what you did as it is valuable in itself and an essential first step should someone want to go further. Questions about where to get the metadata and what templating language to user are second order optimizations. Lets get people generating and then we can figure out the details :->