Crispin wrote:
Of course without a good understanding of the generated code,
trying to fix problems in the code is going to be a nightmare.
Sure, but you certainly SHOULD NOT be modifying the generated code.
You SHOULD BE going back to the tool and resolving the bug at the
higher level generators afford you.

Never said anything about modifying the code. I'm talking about
DEBUGGING the code ... solving LOGIC errors.

In my experience (granted, somewhat limited to a single vendor's product, but I have seen the output from other vendors tools), the
code that is generated is horrendous and next to impossible to
debug.

I'd be interested in which vendor that was.

AS/SET primarily. Synon to a very limited extent.

I have worked with multiple tools that generate code. The fact that
they generate code the same way every time means that they are MUCH
easier to debug. I know what the generator will generate, what the
program flow will be. I DON'T have to change my thought process to
match another coders coding style.

Well, you know how the code will be generated NOW. What about tomorrow? AS/SET went through a few revisions where the generated code changed significantly between re-generations.

One of the theories (as I have been told) behind a code generator is
that the user written structures stay the same, but the generated code
can change as technologies change (although I haven't seen this much in
practice).

PLUS, if you write code in a code generators language ... how are your
skills in the generated language going to grow? In my experience, if
you don't actively develop in a language, your expertise in that
language will diminish ... along with your ability to debug it (in other words: If you snooze, you loose).

And that's why we're arguing about which technology is better to get
a business application to the Web, rather than getting it there.

The first task in moving your business application to the web is to
decide which tools you're going to use.

I've used generators for almost 20 years. I write WinC/Java/5250/HTML
clients. I write JDBC/ODBC/SQL Server/DB2 backends. I put the
business logic where it makes sense. I can change where each piece
goes on a whim.

I've used code generators in the past too ... and to be perfectly
honest, the code I've written by hand is infinitely easier to write,
debug, and maintain (by me and others). It's also more modern and
efficient.

I don't care that I use a tool. I use the tool to get the job done.

Maybe so ... but the next guy who has to maintain that code (who may or
may not have access to the tool you used) probably will.

I cared when I first looked at generated code 18 years ago, because I
was an RPG coder, and I wanted to keep my job as a programmer. I see
too many people get defensive when it comes to something else writing
the code for them. I think these people need to get over it.

I really don't understand that statement. It's not a mater of pride or
ego ... it's a mater of being able to provide support to the end user
community. If the logic is written in a higher level language than RPG
or Java, and RPG or Java is the generated code, you need to have
complete understanding of what is generated. Generated code is (generally) harder to understand. Thus it is harder to debug. If it's hard to debug then it's going to be more difficult to provide support to the end user.

FWIW: I've worked with people who knew how to program AS/SET and nothing else. They had ZERO ability to debug RPG. The only way they were able to solve problems in the generated code was to put debug statements in the AS/SET action diagrams, regenerate the code, and re-run the code. Since I was primarily expert in RPG, I was able to debug the generated code FIRST. I was able to solve problems 50 times faster than they were.

david



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.