That came about during the best practices show. One of the panel speakers, while making a disclaimer that he is not hands-on, said that he does not believe in code generators. At that point I just thought it was funny as it goes along the line “Why people who do not wash dishes think that dish washing machines are not needed?”. But after the show I met a few people and some thought that application generators should be avoided. I was not able to find out “why” though – it was more of the way they felt rather than a argument. So why do they feel that way?
I do not know. Let us do a mall exercise first. Open a new Flex project and create a new FDS application project. Before you even write a single line of code Flex creates 30 files and 120+KB of code in background. You can see them by adding –keep switch to the compilers command line. Before you are finished with login screen you have 100 files in the generated folder. Is it good or bad?
It is expected. It is good in a sense that you do not have to write this code yourself. It is good that it will be compiled rather the interpreted giving you the best performance possible.
Code generators are essential part of every IDE product and there is not need to debate this. Every productivity language/compiler (starting from Assemblers to C to C++ and the modern ones) has some code generators built into it. Most of software development tools I know are using code generators of some kind. Another example – if you are the programmer who are just filling the blanks in someone’s framework as oppesoed to being a creative writer – you are also a code generator to some degree.
There are good and bad code generators, but they are not solving their problems, but rather helping you in solving your application’s problems. They are just the power tools that implement best practices for solving domain problems.
People take domain-specific problems (either in the form of code annotations or just a as a standalone resource like UML in which you embed a host language) and generate the code that you can see and modify. You are doing it every day. For example, Flex processes annotations embedded in the ActionScript and MXML. So when you use [Bindable], [Managed] , [Event] or just include CSS references you are telling Flex code generators that you want certain patterns applied to this code fragment, and Flex generates a bunch of files in the background. You really have to be hands-off to use and denounce code generators in the same time.
Code generators are getting better and better. Bugs are eliminated, the language flexibility increases, new domain problems are added and automated. The best optimizing compiler produce better code (efficient, compact or anything in between) then any human. With alphas and betas of Flex, I’ve been studying the code in the folder generated . After a wile, the entire process became completely transparent to me.
Our code generators belong to the 3rd generation. They work in background, generate and insert the into “invisible” locations. You do not need to see this code or build the resulting code separately. They perform hot deployment and provide automated and visual test code. You apply your code changes directly in the mix of the application code and domain annotations. You never have to see generated files – or at least not more often then you have to see files generated by Flex. For certain types of applications one person can be as productive as 3-4 developers. He does it faster and with less effort. The concepts of code visibility and rules of generated code invocation are identical with Flex even though the products are coming from different environments, but after all these are common best practices of the modern software development.
I think the problem is that most of the people think of generated code as source. Let me give you another example. We take a Java file with some SQL or other annotations and run it through our code generator. It produces the DAO and Assembler classes, multiple DTOs, deployment descriptors, deploys the jars and places all low level artifacts that you do not need to touch (ever) in your Flex project. That is where most code generators stop. We made sure that our generators are fully open; you can add templates for generating other type of code and modify the existing ones.
Over time, your reference implementations will have templates for databound datagrids, forms, master/details forms, reports, TreeGrids and other TEST samples for people to try the power of really fast development. The main target with the products are metalanguage files disguised as MXML extensions. However, people can take test the code and happily embed it in application. The changes come and they have to propagate these changes manually – and they say the process does not work.
That process indeed does not work – but it’s not the code generator’s fault. It just means that while the tool was working with annotations in Java and users somehow expected it work transparently on Flex side (and we did not have any annotations there yet). In order to achieve the synchronization between Flex and Java, you need another code generator that would allow you to process Flex annotations in the Flex compiler. We requested that feature in compiler over a year ago, and I was told it is in the plans for Flex 4 
. However, as soon as Flex compiler goes open source, it should be fairly simple to embed your own code generators that would enable synchronization. For now, when we need to augment Flex with business domain functionality like business expressions a la Excel or Powerbuilder, we run source-to-source generators that are transparent to the developer.
Sincerely,
Anatole Tartakovsky
PS. I wrote these notes on the flight home. These morning I thought about other things, and I believe I got an idea why some people do not believe in code generators:
1. They were much younger than me. Coming from the times when bytecode referred to bytecode of CPU, quest for Productivity Holy Grail is automatic for me. And experience with preprocessors, RADs, 4GLs and metalanguages allows me to see different implementations of generators as probably the most powerful way to incorporate best practices . Here is how I see it: It is ok to teach people how to recognize patterns and communicate among themselves using these patterns. A code generator is a way to communicate these patterns to the computer in the best possible implementation using the input provided by people using the patterns.
2. Somebody needs to explain people the difference between code generators and source code generators. A lot of people went to preceding Flex 3 sessions where they saw dialogs based code generation for PHP. They automatically associate (that’s what people do best after all) the CRUDe source generator with the similar functionality provided by domain extensions of our code generators. Well, if I’ll ever be invited to participate in a keynote, I’ll try to explain it to more people so there won’t be any confusion