× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> From: Hans Boldt
>
> Joe, sorry, but I have a *big* problem with your main contention
> that somehow business applications are too complex for OO languages,
> and yet a procedural language is just fine.  The capabilities of the
> typical OO language are clearly much greater than procedural
> languages in many areas:  Data structuring, interface definition,
> modularization, function libraries, etc, etc.  To argue that a
> problem domain that is somehow too complex for OO can be handled
> more easily by a less capable language just goes against plain
> common sense, in my humble opinion.

Hans, we're just going to have to agree to disagree here.  I've written
everything from operating systems to ERP applications.  I've coded in every
language from assembly language to ones I've written myself.  On one end of
the spectrum, I've programmed an 8259 PIC chip, a level of understanding of
operating systems which few programmers ever achieve, while on the other end
I am certified in inventory management, which means I understand the
application requirements of ERP to a level that most programmers rarely
need.

I have 20 years of development background, which includes a heavy grounding
in OO via Smalltalk, C++ and now some four years of Java.  I also have
programmed in several procedural languages, and have written literally
hundreds of programs, besides being the manager of architecture for what was
arguably the single most successful business application package ever
written for the IBM midrange.  The design decisions I made affected tens of
thousands of users over a span of years.

With all this experience, I have given you a concrete example (MRP
generation) of a situation where OO is not appropriate, and why.  Data
driven programming such as that required in business applications requires
either complex hierarchies or a heavy use of composition combined with lots
of branching based on attributes.

Inheritance clearly fails in this situation.  But composition also fails,
because of the sheer complexity of the code.  As you move from inheritance
to composition, you introduce branching logic, and in effect are coding
procedurally within your containing class.  Any benefits of OO are lost in
that transition.

But don't take my word for it.  Write a non-trivial business application in
OO.  I can only surmise that your statements are from a lack of practical
experience.  The fact that you consider RPG a "less capable" language shows
that you haven't yet understood the concept of "the best tool for the job".
And it further begs the question why you're on the RPG compiler team, but
that's a different issue for a different day.

Let me be perfectly clear on this:

OO is not fundamentally better than procedural.  Just as native access is
not fundamentally better (or worse!) than SQL.  Each syntax has its proper
problem domain (with the possible exception of Visual Basic <grin>).
Data-driven business application programming is better suited to procedural
code than to pure OO, in my opinion.  And that opinion is based on 20 years
of development both in application and systems design.

If you'd like to argue the point, fine, but please argue with something a
little more concrete than the unsubstantiated statement that OO is "more
capable" than RPG.  Because frankly, Hans, it ain't.

Joe



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.