RE: Efficacy of code generators

Nathan,

You put me in a bad way here, because I've been gently chided (someone other
than david) for putting too much non-tech stuff on this list.  The
coin-flip, today, came up "reply on same list as original post".

(See inline.)

jt


| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Nathan M. Andelin
| Sent: Tuesday, December 11, 2001 9:52 PM
| To: midrange-l@midrange.com
| Subject: Re: Efficacy of code generators
|
|
| From: "Jim Franz" <franz400@triad.rr.com>
| > You speak as if common interface patterns is a "bad" thing.
| > Easier to train users, easier for new programmers,
| > easy/cheaper TCO (total cost of ownership)...
|
| Good point.  Patterns are a good thing.  The question is when to
| use a code
| generator, when to use a utility, and when to write your own program?
|
| A pattern, when implemented as a utility, may be better than
| generating new
| code.  For example, the IBM middleware that generates the 5250 stream is a
| utility.  It transforms predefined structures directly into the user
| interface stream.  In contrast, Webfacing uses the same structures to
| generate new code (Servlets, JSPs, and Java Beans), which in turn generate
| the user interface stream.  No additional function (as far as I can tell),
| just a lot more code to manage, maintain, and run.

This is my contention, also.

|
| Code generators have a place.  However, my opinion is that they are often
| promoted and used for purposes that would be better handled by utilities
| and/or custom written code.

I tend to agree with you again.  But I think it's primarily an interface
problem.  Meaning: a compiler is, in essence, a code-generator.  The
interface to the compiler (the language) defines your ability to implement
functions without knowing the underlying details AND the degree to which you
can optimize performance.  I think most compilers to a great job of reaching
a balance between these contrary objectives.

IMHO, most code-generators don't.  (I have similar beef with OO.)  The
emphasis is so skewed towards insulating the programmer from underlying
details, that the result is bloatware...  Even more, in the process, an
added layer of abstraction is introduced.  Now many will say that's
precisely what's needed to gain programming efficiency.  You need an added
layer of abstraction to model business processes.  My experience has been
the opposite.. that coding in ANY language is already sufficiently
abstracted from the reality of business processes.  IMV, that's why you end
up with so much code that doesn't parallel what the business does, very
closely...  (Actually, this paragraph doesn't reflect my views very well,
and this would be another loooong thread, in itself.)

I asked the question whether today's code generators have progressed much,
in this regard, since I looked at them in detail a few years ago.  Whether
other code-generators are vastly superior to Synon/Obsidian and the one JDE
used to generate their green-screen apps.  Maybe they have...  Maybe not.

Either way.. doesn't mean they couldn't do MUCH better.

|
| Nathan M. Andelin
| www.relational-data.com