Code Generation always Costs Something
It is nice to see some things remain the same, even if it does mean they haven't improved…
Code Generation always Costs Something
I wrote this a year and a half ago (December 2005):
Open Source Projects & Code Generation Tools
David wrote this one day ago (July 2007)
Code Generation and Maintainability - Developer Productivity at a Price?
Code Generation always Costs Something
I wrote this a year and a half ago (December 2005):
Open Source Projects & Code Generation Tools
David wrote this one day ago (July 2007)
Code Generation and Maintainability - Developer Productivity at a Price?
posted by tadanderson at 11:03 AM
2 Comments:
David wrote: "This isn't to say that all code generators create un-maintainable code, but you can't really evaluate a code generator until after you have had to maintain the code it generates."
In my experience, there's a big difference between whether you have to maintain the output of a code generator or not. If you do, you have to a) understand it and b) face all the normal round-tripping problems between whatever input you give to the generator and the changes you want to the generated code. To my mind, that is more like a wizard: something that spits out lots of code that you have never seen, but which you are expected to maintain.
In Domain-Specific Modeling, you're not meant to have to maintain the generated code. Instead, you work all the time on a higher level of abstraction in models, and the generated code isn't something you look at. This makes generated code effectively be like the assembler that compilers make internally as part of the process of producing the final executable.
To make this work in practice, both the modeling language and code generator need to be made specifically for the kinds of applications you're trying to build. Otherwise you end up trying to make a universally applicable modeling language and code generator, which we all know intuitively cannot work. Anyone who has used code generators in CASE tools or UML tools knows that no vendor-supplied generator can be good for everybody: code simply isn't "one size fits all".
In the best case, the modeling language and generator are both made in-house by an experienced developer in your domain. That way, the concepts of the modeling language are things you are already familiar with, and the code generated looks just like your current "best practice" manual code. An obvious benefit is that you can change both the modeling language and generator when you want, to reflect changes in your domain or your improved understanding of it. And the obvious cost is that somebody has to build the modeling language, generator, and modeling tool.
The good news is that there are tools out there designed specifically for this task: you just input the concepts and symbols of your modeling language, and they give you a full modeling tool for it. Using these meta-tools is orders of magnitude faster than building your modeling tool using frameworks like EMF and GEF - not just when you create the first version, but maybe more importantly also as the language evolves.
At the end of the day, the important thing is that DSM has consistently shown 500-1000% increases in productivity. This is not just in generating first versions, but also over the whole lifespan - e.g. Nokia have been building cell phone software this way for over a decade (see our case study).
Thanks Steve. If you found what Steve said to be interesting, be sure to visit his blog HERE
Post a Comment
<< Home