A code generator is a piece of software, often template-driven, which creates a large amount of application program code from a small amount of information entered by a programmer. The generated code is then processed by a compiler or other language processor just as if it was written by a human being.
(This definition is not to be confused with the code generation component of a true language compiler... that's something else entirely.)Code generators are wonderful things, especially when you have a lot of boring, similar code to write. The MobiLink Synchronization Model Wizard is one example of a valuable code generator, especially the most recent version that comes in-the-box with SQL Anywhere Version 12; MobiLink setups often include hundreds of scripts that are exactly the same except for differences between one table and another (columns, primary keys, etcetera).
When In Rome
By definition, no part of a code generator is present at runtime. That means runtime error messages are expressed in the context of the output created by the code generator, not the input created by the programmer. In the case of the MobiLink wizard, error messages are expressed in terms of the output SQL, not the spreadsheet-like input to the wizard.
And that's the main reason a code generator should be disposed of as soon as possible, right after all the boring bits have been successfully generated. If the debugging is going to involve the generated code, then the fixes should be made to the generated code... When in Rome, do as the Romans do... When in SQL, code in SQL.
This is reinforced by the fact that special cases are always going to be difficult if not impossible to express as input to a code generator. No matter how sophisticated a code generator is, there are going to be cases that have to be hand-coded in the output language, not the input.
A worst-case scenario involves a custom-coded code generator, especially one created and used by a temporary contractor... those really should be disposed of as soon as their usefulness diminishes. There will always be more people who can work with the output code than those who can maintain and operate the code generator.
3 comments:
So you are saying the following?
1. You only should use a tool when you are (at least in general) able to do the work without it. - Or to state it another way: You should only use a tool if you understand what it does.
2. And it you don't follow that rule, be prepared to feel unable to get out of any coming troubles unless you learn to understand what the tool has done...
Yes, that's why I've always preferred "two-way tools":)
Regards
Volker
In a template-driven world, perhaps you are right Breck.
However, how about a model-driven world? The model could contain a complete definition of what the biz requirements were (from data model to appliction logic) - press a button and Presto! All necessary database code and application came out the other end.
Way back in the dark ages (late 80's, early 90's) I worked on a tool that did exactly this.. called Synon/2E. It was incredible... I've missed it.. I havent seen anything like it since.
Hi Ron,
The "model-driven" approach to MobiLink development is encapsulated in Sybase's other development platform: Sybase Unwired Platform (SUP).
SUP's development paradigm deals with logical programming objects such as "Business Objects" that you code "methods/actions" for, that "synchronize" with an abstract "Business Information System". The SUP architecture still relies (in part) on MobiLink/UltraLite technology under the covers, but you wouldn't recognize that fact immediately when you are developing with it.
Cheers,
Post a Comment