Re: RPG - I'm not dead yet!

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 :).

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.

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> Seriously, that is what I've found over the years in non-trivial systems, having written them in both RPG and Java.

(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).

But see, changes of that level are COMMON in real world business applications. You buy another company, you re-define your cost basis, you change your accounting methodology. Any of these can be massive changes to the underlying system and unless you're either a genius (and were able to see the future) or an idiot (and you wasted time coding for every possible contingency) it's highly unlikely you coded for it. Instead, you made assumptions in order to design your system and now the underlying business model has changed. Sicne OO models the real world and procedural code simply denotes business rules, the changes in procedural code are easier.

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

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. I would, however, use it for a GUI in an eyeblink. And OO is not all that fuzzy to me: inheritance and polymorphism do most of it for me.

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

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.

Well, by this argument no programming language can be the champion of any other, every language must be taken on its own, and comparing programming techniques is sort of silly because the devil is in the details. Okay.

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. We also have a variety of other languages, including COBOL, C and C++, but really we're talking RPG vs. Java, and under that umbrella, RPG is easier to change than Java.

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*"?

That is sort of the topic of all these lists, so yes my conversation is focused there although it also extends to the more general category of business application development, as opposed to embedded controllers, gaming, nuclear physics or digital processing.

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.

That's interesting, because I program almost daily in several different languages, including RPG, EGL, Java and JavaScript. It is that experience that leads me to like OO for GUI and procedural for business logic. But I can certainly respect the notion that that's at least partly due to my own internal biases and the fact that I have a long history in dBase and C and assembly language and RPG (and Smalltalk and C++ and Java...)

:)

Joe