RE: MODERATOR ALERT

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Paul Holm
> 
> Choice the wrong approach and pay for it for years!  You have asked
for
> concrete examples which I have provided to you in past posts.

Paul, there is no easy way to do this, so I'm going to be blunt.  The
reason I didn't respond to your last post was because you seemed to miss
the point of my post where I separated business programming into file
maintenance, executive inquiries and transaction processing.

The vast majority of your patterns handle only my first category of
applications, essentially master file maintenance.  No matter how
complex, file maintenance is file maintenance.  You've written one Work
With program, you've written them all.  And OO probably can be made to
handle that portion of the load just fine, provided one is willing to
back away from JDBC and provide a real security layer.

Basically, you're talking about the very first layer of business
programming, that of entering and validating data records.  I'm not
trying to minimize the issue; what you're talking about is certainly an
important part of any business application.

But it isn't what I talk about when I talk about business applications.
I'm talking about the hard stuff, which I've expressed over and over
again: pricing calculations, finite forward scheduling, batch balancing,
MRP generations, WIP calculations, standard costing, all of the stuff
that doesn't come from the database, the stuff that differs from client
to client, from customer to customer, from day to day.  It is this level
of programming that I have yet to see anyone properly design an OO
framework for.

In business application programming, issues like subfile paging and
field validation are secondary.  It is assumed that all the critical
information has been parsed and validated.  Now it is time to actually
PROCESS that information, and it is this level of programming where OO
is less than satisfactory, in terms of productivity, performance and
flexibility.  I am convinced that there is no way you can program an MRP
generation process in Java in the time I can do so in RPG.  And after
you're done, I am confident that I can throw some real world wrinkles
into the business requirements that will take you far longer to
implement in your OO environment than it would take with my procedural
programs.

It is simply a matter of the nature of the language.  While you are busy
trying to determine the object hierarchy of material requirements and
identifying the interface for the factory class that converts order
entry detail lines into soft allocations, I'm already writing the
calculations and working on the detail, because I can use those records
as is.  By being as close to the database as RPG is, I don't have to go
through the intermediate layer of defining objects and their attributes.
Your only hope to even stay with me is to simply execute raw SQL
statements in your factory to directly derive the objects from the
database and then figure out some way to order them in collections.
With million-record MRP generations, that's no small feat, by the way.
And by the time you've done that, I'm already processing the results
(not to mention the fact that mine probably runs a lot faster).

In a procedural language, such programming requires an intimate
knowledge of the database, a detailed understanding of the business
requirements, and some really solid programming skills.  It's a
completely different process than creating yet another "Select and
Display" program.

I could go through a similar analysis of the pricing issue.  Here, the
area where the system breaks down is the sheer number of possibilities.
You end up with either an unwieldy and brittle hierarchy, or else you
devolve into writing procedural code inside of your objects.  And once
you've done that, to me you've basically just accepted the worst of both
worlds.

Paul, I don't discredit your abilities, your credentials, your
experience, or your accomplishments.  I think you've done a terrific job
on one segment of the business application spectrum.  I'm simply
restating my opinion that in situations where non-repetitive programming
is required, OO is less flexible and less productive in meeting
day-to-day business requirements than procedural languages and
particularly RPG.

Joe