Our OO Verus Procdedural Discussions and New Forum

Group,

IMHO:

The issue of OO versus procedural programming approaches is a subject with
industry and iSeries AD wide ramifications.  Simply put, the issue is the
fundamental building block of all that we do as developers.  This issue and
it?s ramifications are of the highest significance due to these along with
other factors.

1.      IBM and the industry are ?pushing? OO approaches.  The majority of
iSeries shops have not had a chance to fully explore, understand, and work
with OO technology.  It is important to have a good understanding of the pro
?s and cons from a practical real world perspective as they decisions are
made.
2.      To my knowledge, we may be entering an area that is setting a 
precedence.
I?m not aware of too many PRACTICAL and REAL WORLD (not MTV) comparisons
that drive to the fundamental differences between the approaches.  Most OO
literature talks of vague concepts such as polymorphism, inheritance with
animal examples that are not typically enlightening to readers.  This
comparison project that has been started can change all that and provide the
meat to base decisions and may effect the entire industry.
3.      IMHO:  OO is paradigm changing and is not easy to initially grasp 
however
it has the capability to reduce development times by orders and magnitude.
It has the ability to reduce project development times from 2 months to 2
hours or 2 days.  Benefits vary according to business problem, the amount
the problem overlaps with reoccurring solutions.  OO is not a yes or no
thing.  It is a sliding scale much like martial arts with capabilities
ranging from a green belt to a 5th degree black belt.  When faced with
problems, the 5th degree object will yield more benefits to your outcome.
OO is implemented with classes built to work together providing a framework.
OO is not necessarily about a product, it is the fundamental approach one
takes to developing software.
4.      IMHO:  It is my assertion that procedural approaches cannot solve
business problems with anywhere near the productivity and flexibility that
an OO approach yields.  My guess is it may take 2 months in procedural to
solve Nathan?s problem to the level that a OO approach has.  I have walked
on both sides.  My procedural background is Cobol ;  I wish it was RPG so I
could further relate exact comparisons.
5.      OO is not a slam dunk.  OO problems involve wide spread adoptions of
standard frameworks, performance, and learnability.  I am not an OO bigot
however I have seen the explosive productivity benefits of using OO
technology hopefully revealed a bit by the OO prototype.

We stand today at a major cross road for iSeries and industry wide
development with truly paradigm changing possibilities.  I would really
encourage that group moves forward with professional, business driven set of
comparisons utilizing whatever forum advances the mutual case.  Perhaps the
next generation will look back at this work and fully realize its
significance.

Thanks to Joe for the time he devotes to the infrastructure and driving of
this stuff.

Respectfully,

Thanks,  Paul Holm