Re: HTML and PDF Reports -- WEB400

David wrote:

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.

You did say "trying to fix the problems in the code", which I took to be in
the generated code. See my later points.

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.

Thanks for the info.

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.

Don't know about AS/SET. What I can tell you is that the 2E generators have
not changed significantly enough in the last 18 years that a programmer
worth half his salt couldn't figure out.

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).

No doubt. But, that has proven to not be the case, in my experience, unless
you are talking about generating to a completely different language.

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).

I don't get that (well perhaps I do). There are those who are still happy
coding in what I consider little more than RPGII on the i today. How did
coding in the native language help them. It didn't. Snoozing and losing is
completely down to the individual. Anyone who wants to keep up with
technical changes can and will.

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.

Not if the tool you're using will already go there, and do it well.

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.

See, that's my whole argument. You did get defensive, and went on the
offense about how you can write better code than the generator can.

More efficient. That's just a really foolish position to take. These machine
are so bloody quick today, and the compilers are so good at optimizing code,
that there's no excuse for spending twice as long developing a solution that
will skim 0.000001 secs of a transaction.

Anyway. What if you want to generate that business logic in C++ or Java
instead of RPG? I can do that today, in about 2 seconds, and get exactly the
same business rule in a different language. How many hours, or weeks will it
take you? That's if you'll even do it by hand.

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.

See my first point. If you are maintaining the code directly, you are doing
the wrong thing. If you don't have access to the tool, I pity you, and the
people who made that business decision, because it will fail!!

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.

HOLD ON. You made it a matter of pride when you started going on about how
much better the code YOU write is not two paragraphs ago.

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.

Sorry, I disagree. If my business logic is sound, and I trust the generated
code, then why should I care about the implementation details. Like I said,
the same business rule code can be generated to multiple languages, RPG,
C++, C++ on SQL Server, C#, Java. Changing where I want the business rule to
reside, doesn't change the business rule. And again, I bet I can do it way
quicker than any hand coder.

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.

I'm not going to argue this one with you. I also think it's important to
know the implementation details from a personal perspective. I just don't
think you HAVE to to be able to get a job done.

Crispin.