Sessions at Code Generation 2011 on Friday 27th May

To model, or not to model, that is the question. Should we always model, no matter what? Or never model, if we can possibly avoid it? There are far too many people in each of these extreme camps. Some are so zealous they see modeling as the one true way; they hope to reach nirvana orchestrating a stunningly beautiful, visual representation of their design. Others are so narrow they can't conceive there might lie value beyond code written in a general-purpose programming language; they hope to reach nirvana coding in a highly-expressive, optimally-concise notation. In the middle are the pragmatic, those who know that what's best depends a great deal on the task at hand and hence is unlikely to lie at either of the extremes. Unfortunately the whole domain is shrouded in misconceptions perpetuated by extremists. Together we'll explore the social and technical underpinnings of modeling.

Building a code generator is usually seen as a large effort that you can only afford to do when you can reuse the code generator in multiple projects. Therefore a code generator must be generic, making it harder and costlier to develop.

In many projects we encounter patterns of the same code in many places. The traditional way to capture these is to develop frameworks, libraries etc. Especially frameworks tend to be complex and take much effort to develop. As an alternative, a special purpose code generator can be developed that generate the patterns.

We think that this kind of special purpose code generators is often beneficial: the resulting code is much simpler, easier to understand and easier to debug. And developing and changing the generator is often easier and less work than changing a framework.

The goal of this goldfish bowl is to investigate this use of code generation on a project specific basis.

Panel