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




Joe,
It all depends on how you organise your code.
In Java, or any OO language, the possibilities to obscure your code flow are endless.
Deep class hierarchies are a bad thing, and makes the software inert.Also, classes have nothing to do with OO. E.g. Javascript is OO, but does not have classes (and subclasses of course).
Mostly it's better to do composition, instead of subclassing.Also, subclassing breaks encapsulation.
In general, to use OO effectively, you have to think more upfront.
Bottom line, changing anything fundamental, being class hierarchy or database layout, is always a major undertaking.With OO, however, you have better tools (the language), to seperate the fundamental (difficult to change) part from the rest.

But of course, we still agree to disagree.
Also FYI (you started pissing), i have lots of experience with OO and procedural.I have years experience in Smalltalk (90's) and Java.To experience real adaptability, try Smalltalk.
You are right however, that for bigger systems, you really need a static language, not dynamic ones.
But interesting that you say that OO programs are difficult to change, and difficult to understand.This (adaptability and understandability) is the prime selling point of OO.So it's all BS then...

Date: Thu, 7 Jul 2011 06:49:14 -0500
From: joepluta@xxxxxxxxxxxxxxxxx
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: RPG - I'm not dead yet!

On 7/7/2011 4:10 AM, john e wrote:

This is not correct, OO has nothing to do with flow.
An OO language has constructs which help with encapsulation, or "information hiding".Not much more, but nothing less.You can program "procedural" if you want, in Java, whatever that means.If you mean "imperative", there is no difference (you can make one big main method if you want).

It's far too early in the morning to argue about semantics. Procedural
programming has definite differences in flow control over OO
programming. It's not the language; as you note, you can program
procedurally in Java. However, in a procedural language there's
traditionally less concern about creating hierarchies of classes than
there is in OO. And it's those hierarchies that control the flow of the
program. You can call it encapsulation, but the problem is that with an
OO language you often have to dig deeply into the hierarchy to
understand the flow whereas with a procedural language it's
traditionally easier to find a specific line of code.

The point is that I find it a lot easier to react to major external
forces in a procedural language. In an OO environment, if it turns out
that your class hierarchy is no longer valid, changing the fundamental
class hierarchy is a major undertaking (heck, renaming a class is almost
impossible - that's why we still have the AS400 class in JTOpen!).
Whereas in a procedural language, it's often as simple as grafting
together a few bits from different programs, adding some new
functionality, and calling the new program.

My point: procedural languages react better to stress than OO
languages. And that's purely my opinion after many years of working
with both. Your mileage may vary <smile>.

Joe
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.