Automatic Code Generation

[Rasmus Fogh]

On Sun, 5 Oct 2003, Ian Bicking wrote:

> On Sun, 2003-10-05 at 11:52, Rasmus Fogh wrote:
> > Someone raised the question of automatic code generation a few weeks back.
> >
> > And yes, we (CCPN) are using automatic Python code generation in a major
> > way.  Basically we are making data models in UML, and using automatic code
> > generation to make Python APIs, XML I/O etc. (more below). We can be found
> > at http://www.ccpn.ac.uk/index.html
> >
> > As a general point, automtic code generation would seem like a good idea
> > in special cases where:
> >
> > - a lot of repetitive code can be derived completely from a more compact
> > or problem-oriented description.
> > - The problem is large
> > - You need to keep doing new pieces of code and/or maintain several sets
> > of synchronized files on top of an evolving problem description
> > - You avoid hand-modifying the code, either because you can get 100%
> > automatic generation, or you can 'park' the handcoded modifications where
> > they are read into the automatic generation process.
>
> I would disagree that code generation is a good solution to these, or
> nearly any case.  Specifically in Python, code generation isn't
> necessary because you can build objects and classes dynamically.  So if
> you have a non-Python representation of the object or class, you can
> write code to dynamically create that class, instead of writing code
> that writes code.
>

Building the code dynamically would certainly be an alternative, so code
generation is not necessary (i.e. unavoidable). In our case I think it
makes sense, though. The code to create your classes and the logic to
control it would presumably be much the same in either case, it is just a
question whether to execute the generated code or write it to a file. It
would seem to be faster to generate the code once and for all rather than
each time you need the code. You may get more flexibility by generating
the code as you need it, but seeing CCPN is making data models and data
exchange libraries that should be the same for all users, we specifically
do not want the individual programs to have that flexibility. Finally, it
is probably easier for users to read and debug generated code than a model
+ generating script.

To each his own,

Rasmus

> One possible exception to this may be templating languages, which
> typically compile more directly to Python code, with the full generality
> that entails.  But even in this circumstance I think there are
> considerable arguments against compilation, as the compilation can be
> difficult to manage and errors are not as well reported.  (But
> unfortunately the alternative is an interpreted template, which has its
> own issues)
>
> Analogously I can imagine other situations where logic needs to be
> embedded into the description, though even in those situations code
> generation may not be necessary.
>
> --
> Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
>
>
>