× 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.



On Sat, Jul 9, 2011 at 8:54 AM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
This has certainly gone far afield.  It's now more of an abstract
discussion that has run much of its course.  Let me just expound
on a few places where you seems to be confused or surprised
by my positions. After that, the air is starting to get very thin :).

I can agree with that. I do get carried away sometimes. Maybe I need
more outlets for "geeking out"....

It's easier to change in a procedural system.  Data hiding makes
wholesale systemic changes harder.  That's my bottom line and I'm
sticking to it! <grin>

Fair enough. I don't have a Java-centric view of OO, so I don't feel
like OO (even in Java) has to entail such jealous hiding of data.
Encapsulation zealots can use ILE facilities to turn RPG into a
similarly over-hierarchical and over-opaque system, but I fully agree
that it tends not to turn out that way, certainly not compared to
typical systems built in Java.

Sicne OO models the real world and procedural code simply
denotes business rules, the changes in procedural code are
easier.

Interesting. I don't consider OO to model the real world. That's
just a subjective perspective issue, I guess. I think people are
taught silly "life-like" examples when classes and inheritance are
explained. (Here we have an Animal class; Cat and Dog both subclass
Animal; GermanShepherd and Poodle both subclass Dog; etc.) Then
people develop the notion (which I believe is mistaken) that to do
OOP, you have to make your problem fit into that type of hierarchy,
and failure to do so (regardless of the language used or the quality
of whatever you *did* implement) means you have not used OO.

I know this seems counter-intuitive, but in my experience the
closer a system models the real world, the harder it is to
change when the real world changes.

I don't find this counter-intuitive.

Do you not consider prototype-based OO "real OO"?  Also,
[...] not all class-based languages encourage the same OO
style as Java.

I guess I limit myself by my perspective: business applications.  I
would never write a business application in JavaScript, which is a
pretty prototype-based language.

Fair enough.

 And OO is not all that fuzzy to me: inheritance and
polymorphism do most of it for me.

OO is not necessarily fuzzy to any one person who has an opinion about
what OO is; the fuzziness comes from the fact that many different
people who each have a definite opinion often have different opinions.
But maybe this is again me straying from the "business apps" box,
where no doubt Java-centric thinking is far and away the predominant
flavor of OO thinking.

Then to return to my world, the IBM i, I basically have RPG and
Java. And in a pinch, PHP, although I don't consider it supported
the same way I consider RPG and Java to be supported.

OK, fair enough.

 We also have a variety of other languages, including COBOL,
C and C++, but really we're talking RPG vs. Java [...].

I fully accept that RPG and Java are the dominant players on the i...
but I think it would be great if that were to change. I think one
reason I keep talking in broader, "thin-air" terms is that I would
like the i ecosystem to open up further. I think that would be good
for the platform and for the community.

John

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.