RPG and Programming

Continuing with the article in which an RPG programmer describes why he loves freeform RPG so much, we find #3:
“’Eval’ is optional in free-format unless right-adjusting a character string or half-rounding a number. ‘Eval’ simply serves as a placeholder in fixed-format when writing extended factor2 assignment statements. It satisfies the compiler’s need for a non-blank value in the op-code column block (save for the exceptions noted above).”

Now, there’s a good reason!
EVAL is the logical equivalent of the LET keyword in BASIC.
That is, saying LET x=5 is the logical equivalent of EVAL X=5.
In BASIC, you can simply say, instead, X=5. Now, in freeform RPG, you can simply say, X=5; (and don’t forget that semicolon!).

BIG WHOOP. I’m sure not having to key in those four characters when you want to assign a variable a value will vastly improve your productivity. For me, actually keying in a program is the easiest part of programming. Even for a hunt-and-peck typist like me, keying in EVAL takes less than 2 seconds- one second once I’ve got that combination memorized by my fingers. If I don’t have to key 200 EVAL opcodes, that would save me about 1.5*200/60= about 5 minutes, not much in the larger scheme of things, since I would be taking anywhere from 5 to 20 seconds (for a particularly long line with multiple nested parentheses), maybe more, per line.

And then there’s #2:
“Longer field names are more easily accommodated, especially the typically more wordy subfield names in qualified data structures. Longer, more complex expressions can be written on each line. Once written they are more easily understood, since they’re likely not so spread across multiple continuation lines.”

I have to quote a line from one of my favorite books, “The Psychology of Computer Programming”, by Gerald M. Weinberg. Some of the language references are dated, since it was published in 1971, but its essential points remain valid. In the chapter “How Can We Study Programming”, he presented this beautiful line of PL/I code to consider what programming insights could be done via introspection:

ANGLES(I)=2*ATAND(SQRT((S-A(IND(I,1)))*(S-A(IND(I,2))))/(S*(S-A(IND(I,3))))));

Weinberg comments: “Now, a single case such as this contains many insights into problems in computing: the proper size of statements, the choice of data structures, the arrangement of different parts of a program, the use of parentheses rather than other techniques for decomposition, the design of compiler and execution-time diagnostics, and techniques for learning and teaching programming.”

Indeed. The very least it should teach us is that being able to create long, complex expressions is not necessarily a virtue. When you have to resort to dissecting three or four (or more) elongated lines of almost 75 characters each, you probably need to break up the statement, so you don’t lose the next programmer (or yourself, six months later) in your beautiful mathematical expression.

With the EVAL statement, very often (especially when piecing together a long string), I and others will often have to put together a long string of concatenated lines (with a + sign); we are forced to break them up, so will often line up the code, indenting and spacing it so the reader can see the field relationships readily. If we had nearly unlimited space, there would be no incentive to break up the line into manageable pieces. Being able to create long lines of parentheses four levels or more deep is not an advantage. We are not trying to derive complex mathematical formulas; we are attempting to write a legible program.

If you would say that you would keep the lines short, then the above “advantage” disappears.

This entry was posted on Saturday, June 21st, 2008 at 3:44 pm and is filed under Gerald Weinberg, Programming, RPG, RPG Freeform, RPGIV. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.