Author: Risto Kavalinovski, Senior Consultant
Are we dangerously tied to specific purpose languages (generated code or code generators), thus unable to solve problems outside the specific reach?
Aside from my experience I based my arguments on my interpretation of “The C++ Programming Language Third Edition” by Bjarne Stroustrup in direction of code generation.
What is code generation?
A programming language serves two related purposes: it provides a vehicle for the programmer to specify actions to be executed, and it provides a set of concepts for the programmer to use when thinking about what can be done.
The first purpose ideally requires a language that is ‘‘close to the machine’’ so that all important aspects of a machine are handled simply and efficiently in a way that is reasonably obvious to the programmer.
The second purpose ideally requires a language that is ‘‘close to the problem to be solved’’ so that the concepts of a solution can be expressed directly and concisely.
Code generation is a practice of creating the necessary code “close to the machine” by meta-analyses of the given problem.
What are the benefits?
For specific areas, it is possible to generate code directly from a high-level specification. In other areas, code can be generated by manipulating shapes on a screen.
For example, useful user interfaces can be constructed by direct manipulation in a tiny fraction of the time it would take to construct the same interface by writing traditional code.
Database layouts and the code for accessing data according to such layouts can be generated from specifications that are far more simple than the code needed to express those operations.
What are the shortcomings?
The connection between the language in which we think/program and the problems and solutions we
can imagine is very close.
For this reason, restricting language features with the intent of eliminating programmer errors is at best
dangerous. As with natural languages, there are great benefits from being at least bilingual.
Code-gen can provide a programmer with a set of conceptual tools; if these are inadequate for a task, they shall simply be ignored. And in that sense, the most serious problems a programmer can face with generated code, are limitations to its modification.
What is the future?
The obvious usefulness of these techniques in limited – and typically crucial – areas can tempt people to think that the elimination of traditional programming by these techniques is ‘‘just around the corner.’’ It is not.
The reason is that expanding specification techniques outside areas with sound theoretical
frameworks implies that the complexity of a general-purpose programming language would be needed in the specification language. This defeats the purpose of a clean and well-founded specification language (code generator).
It is sometimes forgotten that the framework that allows elimination of traditional programming in an
area (code-generators) is a system or library that has been designed, programmed, and tested in the traditional way.
To conclude
Code generators are a natural development in the way of human-computer communication. Arguments on the faultiness of code generators are arguments on a specific implementation. These implementations are bound to evolve.
It may be up to the next generation to say: ”Command computer: Generate a cross section image of the dilithium crystal chamber” – given that the brightest minds of the current generation stop thinking about how to make people click ads.
