RPG and Programming

The rather slow acceptance of freeform RPG since its inception has been intriguing to me. For that reason, a recent discussion on  the RPGIV forum has been interesting. Bob Cozzi, a well-known RPG expert, posed a question about how long it took to actually code the implementation of freeform to Hans Boldt, who evidently was on the team at IBM that developed the original implementation.
Hans said that it only took about 1 PM (person month?) to actually code it, but considerably more time was spent in planning. I can believe this. The planning discussions must have been particularly interesting.
One of the biggest things that have slowed acceptance of freeform was the non-implementation of MOVE and MOVEL. This is also the opinion of Cozzi and others in the field. Mr. Boldt touched on this and other issues.
Boldt’s first design included implementation of all opcodes. Others in the group, one in particular, argued vociferously against it. Boldt eventually came around to their way of thinking. As he said, “That design point meant we didn’t have to worry about those goofy multi-part factors.”  (I’m not clear on what that means, exactly. But anyway…..)
Once that was established it was just a matter of deciding which to implement and which not. GOTO was thrown out because, as stated in Nicklaus Wirth’s famous title for Edsger Dijkstra’s article on GOTO, “Go To Statement Considered Harmful”. I could quibble about that, but since it’s been probably 4 or 5 years since I last put a GOTO in a program, there wouldn’t be much point in arguing.
With MOVEL and MOVE however, Mr. Boldt doesn’t understand why people are so attached to those opcodes. He says, “It’s hard to see how these opcodes can be missed given the other options available by free-form opcodes.”
To a certain extent, I agree with his comments. I myself have used MOVE/MOVEL very seldom in the last several years. New opcodes have for the most part been very workable. Using EVAL and many BIFs, I get along very nicely. When EVAL gets a little tedious, I often create data structures to put together data in the desired patterns.
The problem is, I am talking about new code. Old code from the 70’s, 80’s and early 90’s did not have all this neat stuff available. About all you had for data manipulation was MOVE and MOVEL, along with their cousin MOVEA, along with perhaps data structures. From my observations over the years, I would say most programmers did not avail themselves of the help even data structures could provide; they did their work with MOVE(L). We are not talking about an easily disposable opcode like FORCE; we are talking about opcodes that appeared in almost every non-trivial RPG program before RPGIV, and most of the trivial ones. They used the opcodes to change data types (from alphanumeric to numeric and back). Above all, they used MOVE to manipulate strings, piecing together long strings from five or six (or more) smaller ones. One can complain that this is a very kludgy way of doing things, but this is all we had to work with. I would suspect that there are millions, if not tens of millions, of MOVEs in the legacy code sitting on today’s AS/400s (or whatever we’re supposed to be calling them today).
So what do we do in freeform once MOVE is taken away from us? As pointed out in the post I referenced yesterday or the day before, we must choose among 10 or 15 alternatives, depending on what we want to do - which in a sense is a demonstration of the power of the opcode. There is no easy conversion; it is not the same thing as changing  KEY   CHAIN    MASTER  to CHAIN KEY MASTER; . I don’t think even artificial intelligence could do even close to a good job of determining the best conversion; Linoma tried, but some MOVEs are just untranslatable without human eyes and brains to analyze them.
Therein lies the problem. If you rule out MOVE in freeform, a human must determine the best way to translate it to freeform. It simply isn’t financially practical to spend resources changing massive amounts of fixed-format code to freeform by hand, and the utilities available for automatic conversion do not do a clean job. You can use Linoma’s software; you can use Websphere’s conversion facility, which does not handle the MOVE and does not even attempt to do the indentation; there may be other utilities around. In the end, to convert legacy code, you can convert it to a degree automatically, but you will still be left with MOVEs to contend with by hand. You end up with ugly flipflops between free and fixed format that may even be harder to read and deal with than the original fixed format code.
It is very nice to say, that when we modify a program, we will also change it to freeform. But that is a slow way of converting what might be hundreds, or even thousands, of programs on your system. Remember, converting a MOVE to something else is not the same as reformatting a CHAIN; it must be carefully tested.
So, while freeform may ultimately win out, it could have been done a lot more readily if MOVE had been implemented in freeform. The more I think about it, I wonder if someone’s ego got in the way, someone who said, “I am going to teach these plebeians how programming SHOULD be done, instead of using these operations that no other reputable programming language uses.”  (Down, XFOOT, down!!!  Don’t bite him!)
And to think it could have been avoided by allowing the conversion of  MOVE  STRING1   STRING2  to the freeform equivalent:  move   string1    string2.