RE: MODERATOR ALERT - Not true in my world

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Paul Holm
> 
> Joe,
> 
> There are several points you fail to see and understand:

<laughing> Okee dokee.

Paul, what you're trying to sell here is a code generator.  I won't even
go into the code bloat such a prospect engenders in Java.  But let's
just take a look at a couple of points in your scenario:

> c) Framework goes on to call ServiceCenterRow.validate where both
> generate and custom validation can occur.

Someone still has to write the custom validation!

> D) Insert of a claim occurs.

At this point, no real processing has occurred!  What you managed to do,
with all this code, is the standard data entry.


> This is the
> industrial revolution for software.  The ability to pump out mass
> application with the easy ability to customize where needed.

That sounds remarkably like the concept of a "code generator" or "4GL".
The idea being that there are frameworks, and the generator created all
the basic bits, and then you just "tacked on" the hard stuff.


> If you truly analyze the time you spend developing an application you
will
> find that the majority is spent on recording task as I've explained.  

Paul, I know what a large application takes.  There are two levels of
programming: the grunt stuff we do over and over again that we assign to
a junior programmer, and the real stuff.

You generate the junior programmer stuff, and you say it can be used as
a framework for the other stuff.

But up until this point, all we've seen is the file maintenance stuff.
Supposedly you retrieved a currency conversion rate, and maybe even did
something with it although we didn't see that.  And even that was hidden
in:

> cc = contact.getField(IContactBuTable.COUNTRY_CURRENCY_CODE);
> getCurrencyExchangeRate(cc.getValueAsString());

Nothing particularly OO here.  This is basically procedural code in
Java, which is not the revolution I had in mind.

> You should
> also understand the majority of Web based applications being developed
> today ARE of a maintenance, or EIS inquiry in nature.  To a much
lesser
> extent, large projects in Java are occurring.

There's a reason for that, Paul!  BECAUSE JAVA ISN'T VERY GOOD AT
BUSINESS PROGRAMMING!

<laughing!>

Okay, so where are we here?  You've proven the fact that you can
generate lots of procedural Java code in order to do file maintenance.
Now let's see your code for MRP generation, or price lookup, or finite
forward scheduling, or batch balancing, or...


Joe