NOTE: The following is an OPINION and does not have any bearing on how easy or hard a particular language / application is to use.
Those of you who follow the midrange.com lists probably are aware that I’m not a big fan of application code generators.
This includes (but is not limited to) …
- Case Tools (AS/SET, Synon, etc)
- EGL
- SQL Pre-processors (RPG SQL, COBOL SQL, etc)
- JSP (to a limited extent)
- Various 3rd party application generators
The reason is simple … the code you write is not the code that executes.
In all the cases, you write in some form intermediary language … which then gets translated into a different language source code which ultimately gets compiled and/or executed.
- AS/SET & Synon translate into RPG (or COBOL).
- EGL gets translated into Java and/or COBOL.
- SQL RPG & COBOL gets translated into RPG & COBOL (but not the SAME code you wrote).
- JSP gets translated into Java.
So what’s the problem with this?
- In most cases, the generated code is extraordinarily complex and convoluted. This makes it very difficult (if not impossible) to debug directly.
- If the code generator changes in a significant way, your application could generate totally different code … which, in a good development organization, would necessitate a full regression test of the application to ensure it still functions the way it did before.
- Often, you are tied to the tool that you used to develop the application … you will need that tool to make any future modifications to the code (assuming the company exists and the tool is still supported).
- Many code generators use their own code repository … which makes it difficult to integrate with change control systems.
- The generated code is often not very modern.
- RD for Power can’t seem to cope with RPG SQL very well (I assume the same is true for COBOL SQL) …
- If generation time errors are encountered during the compile, the errors are not reported correctly.
- If you have a syntax error during the actual compile phase, the line number that RD Power picks up does not correspond to the source code you submitted for compile.
- Although it’s possible to have the source code saved during the generation phase, I’ve had problems with file member locks if I try to RD for Power reference that source member.
Many people will argue that using a code generator is faster & easier than writing an application from scratch thus allowing you to spend more time concentrating on the business logic instead of the language details … which is true … but in order to be able to debug flaws the business logic, you’re going to need to know the generated language.
Another thing to consider: code generators shield you from the real programming language … and your skills in the programming language might (and probably will) suffer. You won’t necessarily always have the code generator available … at which point you’ll have to fall back to your original programming skills, which might have atrophied.
Granted, sometimes there’s no other option …
- You really have no other options if you want to write RPG SQL code. When you compile, I suggest you include *ALL debug views, so you can switch to the list view to see when the SQL CLI is invoked (although you still won’t get a clear idea of what SQL is being executed).
- JSP generates Java … but there’s an option to keep the java source that’s generated, so you can debug it directly. And the generated Java is fairly closely aligned with the JSP itself.
- EGL provides a very robust development environment, including debugger, that allows you to debug the written code instead of the generated code … but you need the tool perform the debugging and (I think) you can’t use a 3rd party JPDA debugger.
Now some might argue that a code ‘wizard’ is a code generator also … but I disagree. Wizards are supposed to give you a good starting point in the specific language … they are, at least in my experience, next to useless when it comes to ongoing maintenance.
What’s the alternative? Well, I would suggest that you invest in a developing a good framework for your system that doesn’t rely on code generators (wherever possible), build it with modern programming techniques, and heavily leverage modularization, so you have a good base to start with.
One other thing you missed. When not writing in the native language, you loose some of the features in that language and/or at the mercy of the tools that you have if you want to use a feature of that target language that isn’t implemented (or isn’t meant to be done by design) in the tool. For instance on the drag-and-drop controls for ASP.NET Webforms it is much harder to control the outputted HTML to achieve a specific goal that would be very simple if you write the HTML code yourself.
You will not get any disagreement from me. Code generators are good for one thing – rapid throw away prototypes. Period. End of story.
One could argue that unless you are writing machine code that there is always a translation from the code you write to what is executed though. Hence compiler code generation bugs and even optimization steps take what is truly executed a fair distance from that code you wrote. Never mind processors like ia64 with many parallel look ahead optimized code generation.
But generally I agree for many modern processor architectures and high level languages like “c” that are close to the machine instructions.
I’d add to this category the SQL code generated by query-building tools such as Crystal Reports or PeopleSoft’s PS Query. At my last project I got a lot of code cut-and-pasted to me from people who had built a query in PS Query and didn’t understand why it wouldn’t run efficiently (or, sometimes, at all). The SQL was nasty crap with very little control of fine detail, especially if you were off the beaten path of what they expected you to do.
Another reason is that code generators are the wrong answer to the question of how to be more productive. You do this not by generating the code (which you had to type without the generator etc), every time again. But you design the code such that you ONLY HAVE ONE instance of that code. This way the productivity gain is not fixed (you can produce screen apps really fast but this little detail which is very important takes two weeks), and you get more and more productivity adding more (generic) code. However, for this you need at least one good developer. Not a trained monkey. However, like all software tools, the vendor sells tools to management. And management likes to hear things like “no programmers needed just monkeys which you can pay peanuts”. Stupid stupid management, there’s the answer to all your IT troubles. Don’t blame the vendor, it’s your boss. Who has never seen one line of code in his life. And simply doesn’t care because it’s not their money.
I have been saying this for years… Synon may be simple to write programs with on the front end but the RPG and CL it outputs is unreadable! I always wanted to slap around MAPICS for the use of it when looking at the source.
-John Andersen
Great contribution! I personally always avoid the use of code generators. The generated code always reminds me of the last plate of spaghetti at an Italian restaurant. Only written itself is also well understood. Even if it saves time.