RE: Java versus RPG on iSeries -- JAVA400-L

Thank you for your comments. They were both well constructed and
educational.

I don't quite see the difference between middleware and business
applications that you do. Of course, I work
for a company that focuses on middleware. But we do have 300,000 employees
and we're full of applications,
middleware, tools, etc. I think there's no clear difference. Both our
middleware and applications seem to change/
morph/intermingle, etc. with equal regularity. Sitting in the "middleware
trenches", I think its a lot more complex
than that. We've got legacy data (only its at 10,000 sites we don't have
control over), applications, tools, rules, object
hierarchies coded to moving standards, etc. just like any other
application. If anything, it might be worse, because
there is no chance to control the 'front end'. Anyway, its not important
that we agree about that.

My take on your comments is that you might be missing one small piece of
the 'ah-ha' of OOP. I'm not in anyway
suggesting that you are... for all I know you are 10x the OO programmer I
am. That doesn't matter either... we're
really only having this conversation for the benefit of the whole group and
in that, there is value in the analysis.

It seems to me that you focus a lot on the object hierarchy. My opinion is
that object hierarchies are almost always
overdone. They impose a rigid requirement that one object is like another.
Unfortunately the OO press (until a couple
works recently) seemed to love to focus on this concept. Perhaps because
of this, many OO programmers seem to like
to jump into 'hierarchy discovery' mode. The problem is that when you
focus on doing this, too often an attempt is made
to stick a square peg into a round hole.

If you build an object hierarchy that is more than three levels deep, its
rare that you haven't done something wrong. The
exception to that is probably exception classes. :-) With a deep object
hierarchy... you are right... when things changes
(and class1 isn't so much of a class2 anymore because of changing business
rules) you're hosed (its all relative... whenever
fundamental understandings change, you're somewhat hosed).

A far better OO model is the use of interfaces to define types, relatively
light object hierarchies and the use of composition
over inheritance. With that model, you are in a much better position to
deal with rolling requirements over time. I'm
continuously amazed at how often we're called upon (my team here that is)
to do things that seem very, very hard at first
glance. And then when we analyze the needs in light of the application
flow that is well established (not the object hierarchy,
but the object interactions that define the application) how quickly and
easily we accomplish those goals. And nearly always
without breaking existing functions (something that procedure programming
is classic for).

It seems to me that for this reason alone, frameworks like San Francisco
are often ill-fated to begin with. They want
to build a 'stack' and often there's just no 'stack' that works.

Disclaimer: I'm actually not qualified to comment on SF (and certainly not
the ODMG). I saw it only from the
'outside' and I do *know* that many people that worked on it were smarter
than me. Its only from that outside perspective
that I offer this opinion of why I, personally, would not be surprised that
its not more successful.

Richard D. Dettinger
iSeries Java Data Access Team

Democracy's enemies have always underestimated the courage of the American
people.
It was true at Concord Bridge. It was true at Pearl Harbor. And it was
true today.

Rochester Post-Bulletin
Tuesday September 11, 2001

>----------------------------------------------------------------------------------------------------------------------------|
|
|
| To: <java400-l@midrange.com>
|
| cc:
|
| Subject: RE: Java versus RPG on iSeries
|
|
|
|
|

>----------------------------------------------------------------------------------------------------------------------------|

> From: Richard Dettinger
>
> 0) What is a business application? Yeah, I'm serious... I guess I don't
> know.

A business application is a living, breathing entity that changes in
response to the changing requirements of a real, live business. The rules
change, sometimes drastically, in response to external conditions.

> 1) What makes middleware a highly definable problem set?

Middleware is in large part a transport layer, and as such handles
translation, be it from one layer to another in the application, one tier
to
another in the network, or one data format to another, such as XML to HTML.

> 2) What makes business applications not highly definable problem sets?

Again, it's the dynamic nature of the business problem space. A person
today is a vendor. Tomorrow they may be a customer. Unless I understand
that today, my class hierarchy may require a major overhaul tomorrow.
Unfortunately, today there is no base to work from: no two businesses can
agree on what a "calendar" is, much less a customer. And thus, OOP may
require a lot of rework when the business paradigm shifts, whereas a
procedural program simply requires rewriting the affected piece.

This is not top say it cannot be done, Richard! It's just that I have seen
very few valid implementations.

> 3) What makes business applications complex and changing? And the
> middleware problem space isn't changing?

The static nature of middleware makes it very amenable to the rigid
definition requirements of a proper OOA/OOD/OOP development cycle.
Formatting HTML is a static problem set. Defining, say, order pricing is
not.

> 4) In what possibly way is OOP "in general" a bad idea where the problem
> set is complex or changing? That seems like the ideal environment for
the
> OOP paradigm.

I disagree. It depends upon the level of change. If it's merely
implementation level, then OO is great. OO is in fact very productive once
you define your hierarchy. But if your hierarchy changes regularly, then
OOP is a bad programming choice. And while you may possibly be able to
develop a hierarchy that is so flexible and extensible as to support any
possible business rule changes, the amount of effort required may outweigh
the benefits of the OOP development process.

OO is nice when you can reuse your own code. But OO really shines when you
can build on the work of others, thereby eliminating the prodigious startup
costs associated with an OO project. Unfortunately, there is no common
ground on which business application developers can stand to share object
definitions.

Richard, this is simply my take on it. I believe that with a proper focus,
a consortium of business application designers could possibly develop a set
of interchangeable business objects that would form the base of an OO
business framework. This could then be used by application developers as a
basis for the next generation of application design.

Unfortunately, this has been attempted twice that I know of (San Francisco
and ODMG) and neither was particularly successful. Until application
designers can agree on these fundamental objects definitions, I think OO is
simply an added layer of complexity to the business application development
process.

Perhaps my experience is tainted by being involved with some of the most
successful RPG business applications ever written. I guess I know what RPG
can do, and I know what happens when people attempt to migrate business
applications to the OO paradigm. But I'm amenable to changing my opinion.
Once I see people achieving the same level of success with Java as we have
had with RPG, then I'll rethink my position.

Joe

_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.