I said in a recent post that I didn't believe in 100% code generation in the near future.

 

The recent discussion about the worth/necessity of some volume of custom code to do clever IDE integration of a DSL got me thinking harder about whether I feel strongly about the notion of "Full code generation".

 

This phrase gets bandied about quite a lot as a selling point of Domain-Specific Modeling (particularly over traditional UML modelling) and as a concept I'm always drawn to it - even if only from the point of view of doing what folks often say can't be done.

 

Now discounting GUI builders where I wasn't in control of the code generation, my personal experience of using DSLs to build production software really started back when recreating all of the metadata and templates for a web content management system that generated ASP pages.  That was certainly up in the high 90s percentage range for code generation as we only had a couple of hand-written pages in total, but the generated code was really very repetitive with just combinatorial problems to solve.

 

However, lately my viewpoint has of course been heavily skewed by the fact that the DSL I use and extend on a daily basis is a DSL for building DSLs (and I say "use", not just "build" because by the process of bootstrapping we build a large proportion of our DSL-building tools with themselves).

 

I'm absolutely guessing here, 'cos we're in an intermediate stage on our current build cycle so I can't measure, but I'd say we'll generate about 70% of the code in the designer I'm currently working on.  This is a big step up from where we were in previous builds.  Looking at my approaches to implementing the code that's currently not generated, I'm finding that I have about a 20/80 split between extending the DSL and generators to create my new functionality and adding the new code manually.  So if I'm right here, we might get up to about 75%.

 

That's a pretty poor hit rate for a DSL guy I hear you cry.

 

I'd say it could be much higher with two strategies:

 

In all honesty, I might have taken a bet on that last 25% and done one or both of these things if we weren't bootstrapping.  Building a DSL with a half-in-pieces DSL toolset that then builds itself is a great proving strategy, but it is nothing like as productive as using finished or even CTP-quality tools.

 

We're very much still learning about the best work processes for this level of bootstrapping.

For the keenly interested, currently we do about half of the modelling using a DSL built on the previous stable version and the other half by editing the raw xml of the new DSL (defined in itself).

 

So the $64K question is "Would getting to full code generation really change my current worldview?"

 

Many folks suggest that with full code generation comes the ability to largely ignore the generated code and focus solely on the models.  The comparison with compilers is often made here as these days relatively few people have to pay attention to intermediate code or assembler.

 

I buy the spirit of this, but I don't believe the practice would work out for me either now or back with my web content management system.  Not enough of the other supporting systems that are involved in software development are prepared to understand my custom abstractions.  I'm talking debuggers, profilers, browsers, symbol stores, style checkers, refactoring tools etc. here.  Code generation and compilers are such a small part of the picture of development. While we don't have all these other pieces, then I think the difference between 75% and 100% is largely meaningless.

 

What we have at present is a damn good productivity tool, the best I've ever used in fact, but not a sea change in software development.  This has already turned into an a bit of a novel so I'll break here and return to the topic of what needs to change anon.