Re: Efficacy of code generators

> Code generators are limited to a few common models (patterns).
> It leads to bloatware, a multitude of executable objects... implement a
> common pattern.  The data they interface with may be different,
> but the process is the same.

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) We say that about our iSeries all the time, and it
should apply to our user software as well.
If your generating "bloatware" then you should look at the tool & how you
use it, just like we look at our own RPG code.

> This seems to be the theory behind the tools I mentioned...:  That all
> systems can be produced by a limited set of design patterns.

Any salesman that says "all" is not to be beleived, and we should know
better.

> maintenance pgms, use a utility like WRKDBF.  Let the programmer do more
> creative work.

... with great care to unedited data and it's effects.

> the cost of learning these kinds of tools dwarfs the cost of the tool
itself.

So! Learning RPG dwarfs the cost of the compiler! Taking a week to turn over
a complicated screen dwarfs the cost of doing it in a tool in a day (or
less).

> Also tends to encourage poor use of the tool, which can result in even
more
> dysfunctional code, and systems.

I think it's the programmer, the training, the management that leads to such
code.


> | The cost of these proprietary languages is relatively high.  The
> | performance of the executables is relatively poor.  Programmer
productivity
> | is about the same.

I've seen otherwise. Tools tend to fit certain type of projects. It requires
management
as well as programmer committment. As in any IS implementation, poor
training, user
fear/resistance, inadequate time/budget will kill any project.

Jim Franz