RE: Efficacy of code generators

Jim,

Thanks for your views.  See inline...

jt


| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Jim Franz
| Sent: Tuesday, December 11, 2001 7:19 PM
| To: midrange-l@midrange.com
| Subject: 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.

I agree.  But having studied the code generated by Synon/Obsydian and the
JDE program generator, I'd have to assume that today's code generators are
definitely bloatware generators.  ***I KNOW*** the theory:  you don't get
into the code of these tools, so what do you care.

Glad compiler-writers don't take that same view...!

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

***I KNOW*** better, yet salespeople still make sales by either stating or
implying this.  It's just a bill of goods, to me.


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

I'm not sure you're catching my drift here...  I'm getting ALL the compilers
for about $6K...  I've been learning RPG for 23 years, and still learning...
I think my time invested is worth a lot more than $6K.  I haven't attended
classes in RPG, other than the local community college, but I have no doubt
you could probably spend close to $6K getting a good set of classes/seminars
over a career.

I'm not opposed to using a tool to do a screen in a day.  What I'm saying is
how much time and money did it cost to do THAT FIRST SCREEN...  (And I
compare that to the fact that I hand-tool a screen in a day, also.)  All I'm
saying is there are definitely two sides to this code-generator issue, and
the learning curve shouldn't be ignored in the discussion.


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

Absolutely...!

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

Again, absolutely...!

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

And these are the issues that most shops face...  Day in and day out...  No
matter if you use a case tool or a hammer and chisel...;-)  I'm familiar
with Synon/Obsidian, but not Cool:2E...  What I observed with Obsydian is
that the learning curve increased rather than decreased.  JMHO.  Maybe
Cool:2E has reversed that trend...  Maybe there are better tools out
there...  I dunno, for sure.

***I KNOW***, for sure, that there is a considerable expense with the
learning curve involved in these tools.

|
| Jim Franz
|
|
| _______________________________________________

<moved from:>

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