RE: Efficacy of code generators (was RE: Two persons per product")

Let's change the list as well.  Could you move it to non-tech?

-----Original Message-----
From: jt [mailto:jt@ee.net]
Sent: Tuesday, December 11, 2001 4:17 PM
To: midrange-l@midrange.com
Subject: Efficacy of code generators (was RE: Two persons per product")


Nathan,

I think we're forking from the question of paired-programming (so-called
"Extreme Programming") so changed the subject line.

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 2:05 PM
| To: midrange-l@midrange.com
| Subject: Re: Two persons per product"
|
|
| From: "jt" <jt@ee.net>
| > IOW, programmers are pricing themselves out of the market,
| > IMV.  At some point, tools will replace a lot of programmers,
| > for this reason.  Been going on for a long time now (Synon, Lansa,
| > BCD, MRC, etc.) but the process is only gonna be speeded up
| > unless programmers achieve greater levels of effectiveness.
|
| Code generators are limited to a few common models (patterns).
| It leads to
| bloatware, a multitude of executable objects that do little more than
| implement a common pattern.  The data they interface with may be
| different,
| but the process is the same.

I agree...

|
| If a programmer is paid to implement patterns redundantly (like a code
| generator), then you're better off using a code generator.

I agree, in a sense.  If all your coders do is clone the same programs over
and over, a code generator will do the job a lot better.  This seems to be
the theory behind the tools I mentioned...:  That all systems can be
produced by a limited set of design patterns.

I agree with this theory to a limited extent.  So I'm not over-sold on the
efficacy of code generators.


| Better yet, in
| my opinion is to use a utility, and avoid the bloatware.  For example,
| rather than use a code generator to create database inquiry and
| maintenance
| programs, use a utility like WRKDBF.  Let the programmer do more creative
| work.

Sprout actually ran into a shop that had all their custom apps based on DFU.
He proposed replacing these with programs, to avoid all the data problems
and operational problems.  IIRC, that saw that as too expensive.  I would
have decided otherwise, myself.  I like the idea of using WRKDBF, from a
standpoint of avoiding bloatware.

But then you've sacrificed the advantages of interactive editing of the
data, and are basically returning to running completely batch-oriented
processing:  Key data, edit data, process data against transaction and
master files...

|
| Some of the tools you mention, of course are more than code generators.
| They include their own programming languages, which makes them extensible.

This is my primary beef with these tools.  As soon as you build in the
requirement that you need to learn new languages to implement the tools
effectively, that places an additional cost above the cost of the tool.
I've never seen any actual figures for the cost of the learning curve.  But
in my limited experience (with Synon/Obsydian, and just looking over the
others), the cost of learning these kinds of tools dwarfs the cost of the
tool itself.

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


I think another question that I'd like to see answered is how well these
tools allow you to maintain your existing apps.  I know that you can use
these tools on your existing database...  That's not the same question.
(And I don't really believe that most shops have the option of re-gening all
their existing apps, using the new tools.)

I've been talking to my boss about Synon, and code-generators in general.
I'm waiting on additional info, from a second source.  I'll just say that
code-generators have not, in my experience, been shown to allow shops the
option of "having their cake, and eating it too".



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

This is the key question, IMV.  I think under ideal circumstances,
code-generators will increase programmer productivity by some unknown
factor, perhaps an order of magnitude.  The question, in my mind, is to what
extent these ideal circumstances can be found in TRW.

That's an explanation (a looong one ;-) of why I tend to agree with your
opinion of today's code-generators/4th gen programming languages (and to an
extent OO, though that wasn't mentioned in this thread)...


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

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.