Scripting languages strive to be typeless, suitable for gluing different components, use flexible data structures and they are interpreted, enabling execution of programming code from the variables, ass well as from programming pieces named scripts. Why don’t we use scripting languages in building of code generators, or, even better, simultaneous development of generators and target applications?

Ideas in the beginning:
– if web applications in scripting languages (like Perl, PHP etc.) produce html documents, why don’t we produce application scripts too?
– different program scripts that make web applications often do the same work, but using different data structures (e.g. from data entry forms). Why don’t we make a variation mechanism to produce scripts that work with different data structures?
– usage of scripting languages in generative programming (insted of object-oriented languages) because of their flexibility in different data types manipulations
First generators were written in Perl because of its character string manipulation possibilities to produce different web applications in Perl and ASP. These applications were used mostly in remote database content management, on-line questionnaires and student’s tests.

GSM (Generator Scripting Model) was established. GSM introduces graphic diagrams to represent generators. Specification diagram represent the hierarchic structure of application specification, while specification itself consist from attribute-value pairs. Metascript diagram (later Configuration diagram) defines assembling program files by connecting specification data and code templates (metascripts).
Except generating of web applications in scripting languages, GSM was used in generating Java and C++ applications. Some generators were written in Java.

GSM basic model was extended to support late binding of code templates, similar to concept of dynamic polymorphism in OOP. This enables more precise specification and skalability of generators, because new code templates can be added without changing generator configuration.
The C++ library for building generators was made. These generators (written in C++) are based on generative objects, that support polymorpih features.

SCT (Specification-Configuration-Templates) model was established. It inherits the basic concept and graphic diagrams from GSM, but enables fully configurable code generators. There is no more need to program generators, because all of its functions are defined in configuration, which could be easily changed. We use Python in implementation of SCT generators because of powerful object-oriented features of that language, keeping the type manipulation flexibility of scripting languages. SCT generator uses mechanism for dynamic instantiation of SCT frames which makes generator maintenance much easier (only top-level frames should be modified).

SCT enables rapid generator development and easy generator modifications. Different output types (and output files) could be achieved using same program specification. Domain of generator model usage was extened to building student’s examinations which include program code in target programming language (e.g. C++) together with different student’s tasks and generation of solutions.

Autogenerator generates and executes the programming code on demand. In fact, Autogenerator uses the possibility of scripting languages to evaluate the programming code from variables.