On Mon, Jun 27, 2011 at 11:31 AM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:
"These are fine benefits to RPG IV, and to me, the cost of
using them(versus traditional RPG/400 or earlier) is
extremely small. (Well, the issue of whether /free is more
readable is subjective, but if you *do* like it, the cost of
using it is small.) But these things are not ILE."
Subjective? Really? You don't think there's a reason why
all other languages are free form? Surely that's a hint?
People who learn RPG (including new programmers maintaining legacy
code) have to be able to recognize the columns. Anyone who has
programmed in assembly (after which traditional RPG is styled) is
comfortable with columns. It's just a matter of what you're used to.
Free form by itself doesn't make things easier to read, especially if
misused by other programmers. As someone else mentioned, there is
nothing to force proper indentation in /free format. Perl is famously
free form and famously difficult to read if the code is written by
someone other than yourself (or yourself from a few months ago!). At
least with the columns, you know things are going to be in a
particular place, so you can always just look there.
And there are plenty of languages that are free-form but not at all
easy to read until you learn them. Average programmers do not just
walk up to Haskell, Lisp, or Perl and go "oh yeah, this is very
obvious and clear!".
But the notion that there is no virtue in RPG IV syntax vs
RPG/400 is a complete mystery to me. Expressions, date
calcs, BIFs, string handling, etc. etc.
I never said RPG IV syntax was without value. I said that not only is
there value, but it is the PRIMARY value of RPG IV (as opposed to the
ILE features). I said that there is very little *COST* to extracting
that value. Longer names are already a MONSTROUS benefit in and of
itself!
But more to the point - if you accept that the performance
difference is a no-op then on what basis can you possibly say that:
Exsr calcPrice;
is more obvious than:
itemPrice = CalPrice( itemCode: quantity: discCode );
I don't say that the first is more obvious. But I do say that the
first *can* be similarly easy to read and maintain. Now that we can
use better names, the name will provide a better clue what the
functionality is supposed to be. If you have to fix or enhance your
price routine, you will have to go to your price routine anyway.
Look, ultimately, I never said ILE is bad. I have gone out of my way
to say I *like* the *idea* of ILE. My point is that IBM's
implementation of it is not as smooth or convenient as it could have
been, and as Joe Pluta points out for one particular gripe of mine, it
has actually gotten better. (Though it doesn't help me for the
foreseeable future as I'm stuck on V5R2.)
John
midrange.com
