On Fri, Jul 8, 2011 at 11:21 AM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
[John Y., not john e]
I disagree. I think whether something is hard or easy to change is
mostly in the design. A *truly major* change is going to be hard in
any system.
[Joe Pluta:]
Here we have to agree to disagree. In my experience, the real
world throws changes that can't possibly be foreseen. You write
a system that does exactly what you want. And then the company
merges with another company and one of your fundamental design
assumptions goes out the window (maybe you are thrust into multi-
currency, or you have to deal with coproducts when you didn't
before - the possibilities are endless). Sometimes new
government regulations kill you - my favorite was when the payroll
tax was split; that kicked the crap out of lots of payroll systems.
Nothing you have said above applies only to OO systems. Everything
above could be just as hard to change in a procedural system, or
harder.
Future proofing is part science, part art and frankly part luck.
I agree with all of that sentence wholeheartedly.
Highly OO systems - especially systems with lots of data hiding -
are often harder to modify in this situation. That's because most
business objects are inter-related, and almost without fail you end
up with a calculation that needs more data than it did originally.
You either have to include that data in some object that didn't need
it before, or you have to add it to a global session object, or you
have to change the signature of a function. And after a few
changes like this, you realize that your hierarchy is out of whack,
and it's time to refactor it. And that's when major changes are
very hard.
(A) I do think this describes many large Java-based systems.
(B) I think I understand what you are getting at, but it was amusing
for me to read the words "or you have to change the signature of a
function" because this is an issue common to any kind of modular
programming, not just OO.
(C) I think rabid OO fans would simply say that if the change you have
to make is so painful, then either your design wasn't good enough, or
you were very unlucky (and thus would have gotten caught out
regardless of what you used to implement it with).
With procedural code it's very easy [...] because you're not as
locked into the rigidity of what is passed between layers. Now,
this is my own personal experience, and as you note, composition
rather than subclassing mitigates this problem to some degree,
but it's still easier to modify a procedural program than a highly
segmented object hierarchy.
I never said anything about composition versus subclassing. That was
john e. (It so happens I tend not to like subclassing, so we happen
to all be more-or-less in agreement on that.) But I suspect we have
all seen procedural designs that just plain suck, and were an utter
mess to make any kind of change to. (None that were our doing, of
course, just those schmucks before us. ;)
[John Y.]
Not all OO systems are based on a "class hierarchy".
Well, this is technically not true. All OO systems require classes.
I'm surprised you would say this. Do you not consider prototype-based
OO "real OO"? Also, even among languages that call their OO mechanism
"classes", there is great disparity in the details; enough that not
all class-based languages encourage the same OO style as Java.
More fundamentally, OO is just a very fuzzy and ill-defined term:
<
http://mumble.net/~jar/articles/oo.html>
Now, you may be able to design applications where every class
is a root class and has no superclass and your entire design is
composition. I've never tried it and I have seen very few
non-trivial systems that didn't have some degree of subclassing;
it's the fundamental technique to implement code reuse.
I can't disagree that big Java-based systems tend to have deep,
unwieldy object hierarchies. But I can disagree that this is
intrinsic to OO design. In fact, Java's very propensity for deep,
unwieldy object hierarchies is one major reason it gets so much
ridicule from users of other OO languages (who embrace OO, but are not
too fond of Java). I really believe that the Java language, culture,
and (typical) education encourages and proliferates that style of OO
design. OO really doesn't have to be that way.
[Joe Pluta]
And I'm not the only one who thinks procedural languages have
their uses, Java may be the number one language, but C is
number 2, and there ain't no objects in C.
[John Y.]
Ah, but who would use C for their business logic either? C is not
meant for things that RPG is meant for. That is not why C is still so
popular. C's popularity is not an argument for "procedural language"
popularity (or relevance or importance or what have you). C provides
no coattails for RPG to hang onto in a discussion comparing languages.
[Joe Pluta]
Why certainly it does. If OO was the perfect solution for everything,
then you would program everything in C++ not C.
Putting aside that C++ would somehow be *the* language to use *if* OO
were the perfect solution for everything; you've apparently missed my
point if you think I was in any way implying that OO was perfect for
everything. I also fail to see *your* point. Your "certainly it
does" refers, I guess, to my "C provides no coattails for RPG to hang
onto".
Let's go over this again. What I wrote implies
1. I accept TIOBE's finding that C is still popular.
2. While C is a procedural language, not *every* procedural language
is well-suited to the things that C is good for. Example: Try
writing a compiler or an operating system in RPG.
3. While C is a procedural language, C is *not* well-suited to
everything that some arbitrary procedural language is good for.
Example: I'm sure you can find an RPG program you wrote which would
be a bitch and a half to write in C.
My point is that C cannot stand for (carry the banner for, or be the
champion of) all procedural languages, certainly not for RPG. And
vice versa. If RPG actually does fall to 0% share, that has *no
bearing whatsoever* on C or on any other procedural language. None.
Whatsoever. And no matter how much C rises or falls, it is
*completely independent* of the rise or fall of RPG. This is what I
mean by "C provides no coattails for RPG to hang onto".
C++ would have long overtaken C much the same way that C# has eclipsed
VB, but it has not.
This is getting a bit off track, but the fact is you can't just
substitute languages willy-nilly based on some broad categorization.
C++ does not have the same relationship to C as C# has to VB.
Actually, I'm not even quite sure what relationship C# has to VB.
Yeah, both Microsoft. But how was C# meant to displace VB? Are we
supposed to say Java eclipsed Pascal? Do we say that Smalltalk failed
to displace Fortran? (Please don't tell me C# is somehow "VB with
objects". C# was designed specifically to be similar to C++ and Java,
and run on .NET.)
The reason C++ hasn't "overtaken" C is that C++ is considered by many
to be simply not that great a language design. Folks that are
interested in system-level stuff find C++ doesn't offer a lot of
advantage over C, certainly not enough to justify the extra
complexity; folks that are interested in OO find that Java is a
cleaner, simpler route to OO. Even in the "more OO support than C but
faster than Java" niche, other languages are starting to encroach. So
really, C++ is squeezed pretty hard from multiple directions, and is
actually doing impressively well given the competition.
Back toward the main thread:
[Joe Pluta]
There are problem sets which OO is good for, and others where it is not
and for most of the latter RPG is the best fit.
Most of the latter? Really? Do you mean "most of the latter *that
needs to be tackled on an IBM midrange*"?
If your only point is that OO is no silver bullet, fine. But I don't
think anyone is arguing (seriously) that *everything* should be done
with OO languages, or even in an object-oriented way (regardless of
language).
Hmm. Then you don't read the "Java will replace RPG" comments that are
everywhere.
I do see them. I don't think they are everywhere. But I am not such
a rabid RPG fan that I feel threatened at all. And comments of that
nature that I do see are never accompanied by well-reasoned arguments.
Just Java fanboy talk is all.
A related argument is the "SQL must replace native I/O" discussion.
SQL fanboy talk. Doesn't bother me. (Plus, it can be entertaining to
see some of the truly amazing contortions that people put SQL through
when they want to achieve something that is easily achieved using RPG
or other means, but either can't or won't use anything but SQL. I'm
sure it is just as entertaining for them when I do something
convoluted to avoid SQL (which I must admit, I am not very good at).)
I just have a problem with any argument that says one technique or
language is intrinsically better than another. In context, each tool
has its strengths and weaknesses. And in my opinion, the ability to
respond to major external stimuli is a strength for procedural languages.
In my opinion, this apparent strength comes mainly from the fact that
most of us find procedural programming the easiest and most natural.
I certainly do. And more than just that, the language *does matter*,
even within a given paradigm. The language that we happen to think in
most easily is going to be the one that seems to respond best to
"major external stimuli". I believe there are meaningful objective
differences, but they have to be quite large before they can overcome
our own biases.
John Y.
midrange.com
