The Benefits of Code Generation

Writing a runtime framework is a lot of fun. You can use crazy metaprogramming techniques to consume XML files and to pretend you have a bunch of code that doesn't really exist. It can provide for a very elegant solution with a minimum of both framework and implementation specific code, and it can also make it extremely easy to vary the API while you're experimenting with and learning about your problem domain. Unfortunately runtime code synthesis also has a number of problems.

The biggest issue is unhelpful error messages. The error messages that a language gives you assumes you're doing normal things like creating real class files with real methods in them. When you break that contract with the environment, the default error messages can start to become very unhelpful very quickly. It's nothing that can't be solved by adding a level of pre-processing constraints and validations for your DSL statements and some richer error handlers in your code that provide more useful context, but doing that reduces the development speed and flexibility that makes the metaprogramming so enticing in the first place.

Often there are certain limitations in any given language that limits what kind of code you can build up and evaluate at runtime, so some things are either hard or impossible to do right using runtime metaprogramming. Also, metaprogramming frameworks require a certain sophistication of any developer working with them so if you're handing off a code base to developers who aren't comfortable with metaprogramming that can become a sticking point. There can also be a performance penalty for runtime metaprogramming, and if you're delivering code to clients (we're usually doing SaaS but we're doing more build and deploy work recently) there are the IP issues of giving away a framework that allows them to build any application rather than one that just allows them to solve their specific problem.

Finding a Balance
One of the common misperceptions about code generation is that it's all about generating code. In most projects you use a combination of code generation and framework code (whether community or custom) to raise your programming environment closer to the problem domain to simplify the code generation step. The art of Domain Specific Modeling is to find the right balance between framework and code generation. Ideally you'll raise up the domain as far as possible using a framework and then will just generate fairly straightforward code for making calls against your framework API. Generally if there is too much of a gap between the level of your DSLs in the problem domain and your framework, you may find your Model to Text (M2T - the template based code generation approach) templates getting too complex. If that happens, you may have to look at applying some Model to Model (M2M) transforms to your model before the final M2T step. If you're just getting started with code generation this often isn't a good idea as there are a number of M2M transformation languages, but none of them are great and they all take quite a bit of getting used to.

Do you do code generation? If so, how do you find a balance between framework and generated code?