In the article "Coding forward, stepping back," the author suggests that despite encouragement by experts such as Jon Paris, Susan Gantner and Bob Cozzi to evolve and use procedures, we should instead continue with past "legacy" practices. The author cites a comparison between a dynamic CALL and procedural execution to illustrate that although "some" performance improvement at the machine level might be obtained with procedures, the real costs are in the maintenance of the code. A focal contention is that maintenance is faster, and therefore cheaper, with legacy coding because you can "see" everything. There's supposedly no need to check elsewhere, like with a prototype, to understand how the code executes.
The author also claims that this difference between a legacy approach versus use of prototyping, as well as free-format versus fixed-format RPG is largely one of style. This thinking is further "supported" because customers don't care whether it's free- or fixed-format (or COBOL, C, Java, etc.) and management is just interested in profits.
I agree. Change simply for the sake of change isn't good. And yes, change does seem to be constant -- whether it's the only constant, well, maybe. It is also true that this is the 21st century and that management is interested in profits. Is management interested only in profits? That is definitely another "maybe," and for each of us the truth might only be in the eye of the beholder.
So you don't think any of that is particularly revealing, but those statements are things I probably need to know. However, they might to most of us be so obvious that your reaction so far is simply, "duh." Unfortunately, those obvious thoughts are most of the "benefit" I received from the referenced article. Why? Because like so many other commentaries that I've seen over the years that seem to gripe about "change," this one may be more dangerous since it seeks to convince us that it is about style rather than substance and that the old is better than the new.
I don't get it
I do confess, however, that I may have failed the article's tests, particularly the one referencing fixed-format code. You see it was code for a "simple" CALL using parameters whose data type and sizes were also defined as part of the structure. Why do I feel that I may have failed the test? Well, I couldn't tell whether this dynamic CALL (whose performance is likely to be significantly below procedure execution) had been written on a System/3/32/34/36/38, AS/400, iSeries or i5. I also couldn't tell whether it was at a time when RPG II, III, 400, IV or ILE was available.
OK, kidding aside, the author's point that we humans are more costly than the hardware has been true for over 20 years. Certainly all things being equal, it would be poor judgment to waste unnecessary time on software maintenance. However, I believe that how lengthy the required maintenance time is has much more to do with the developer's abilities and familiarity with the respective version of the language and its architecture. This is not to say that those who prefer fixed-format over free-format are lesser developers or vice versa. Granted it would be poor management to assign a principally free-format coder to work on fixed-format software -– or vice versa. But isn't it a matter of extensive familiarity, and why can't we RPGers be comfortable and proficient with both? Surely we're smart enough, and surely we're not too lazy or spoiled to learn.
The author also refers to Moore's Law as though to suggest that I shouldn't care about executing 100 dynamic CALLs instead of using one service program because the maintenance will be easier/shorter. Is the idea that we "support" the monolithic, poorer-performing, and nevertheless difficult-to-maintain legacy code ad infinitum and solve any performance problems -- and they will continually come up -- by throwing more of Moore's memory at the problem?
Let me think about that one for a minute. Let's see, I'm going to continue coding using outdated application architecture, which is likely to require more maintenance, rather than today's because I can "maintain" (not code) it faster. And when I can't extend the application because of architectural limitations of language constructs, well, I don't know what I'll do. But if it doesn't run fast enough I can (supposedly) just keep adding more memory. I wonder what part of the cost of the additional memory isn't in my manager's profitability equation.
The author also complains about /COPY or copybooks, and he is absolutely correct. They were around in the 70s, 80s, 90s . . . and today . . . and tomorrow. Certainly if a coder wishes to type the prototype in -- "everywhere" -- he can. That'll speed up maintenance, I guess, because all of the compiled source code will be right there in the one (monolithic?) member. Of course, if I don't want to type it each time or I really just don't like /COPY, I can still create the prototype in its own source member and then "include" it everywhere I need it. That too will get "all" of the code in one place for me to easily see and "speed" maintenance.
Actually that process works. And if you think you need it all there, go for it. It's been done in the past when RPG had basically no date awareness. Shops built separate members, non-compilable, of their subroutines to check for a valid date or perform date math. Then when one of those functions was needed in a program, you could simply include that subroutine's code -- or let the compiler /COPY it. Of course, you could then see it all and was more efficient than a dynamic CALL, but imagine the maintenance nightmare if a change or enhancement was needed.
I think the idea that I need to see it all in one place is faulty and prevents us from making best use of the capabilities and functionality of "today's" RPG language. Is anyone using external data structures? Why would you since you can't see all the fields in your source code? Better to stick with Input or Data specs I guess. Is anyone using DO loops of any variety? Why make that "style" change unless you can't figure out how to do the same thing with GOTO and TAG?
Choosing between free- versus fixed-format, dynamic versus procedure might better be evaluated by the functionality that's possible, as well as the speed of current development and future maintenance. Yes, machine-level execution is also a factor, but let's ignore it. Do I really have the same ability to provide all the user wants; how many developers can touch the code at any one time (think monolithic versus modular); how flexible and extensible is my program, application and system; and how many lines of code must I write to accomplish the tasks? If we examine those factors, which of course, also translate to user/customer satisfaction and profitability, I believe the scales favor both free-format and procedures.
I do note, though, that my thinking is apparently in the minority. Why I know this is because when I first read the referenced article, the rating of it was 4.70. I checked not long ago, and it was 4.59. I consider both of those to be very high ratings, so perhaps I'm very wrong (quite possible), or the only folks that bothered to provide a rating are those that are also very frustrated by the present -- and future. Be assured, I did not rate the article to prevent skewing the rating.
By the way, free-format RPG is not new; it has a past. Ever heard of RPG with embedded SQL? Since it is only now being heavily promoted around our RPG community, perhaps it seems new. It's been around for at least eight years -- and it's free-format! Gee, I might also be able to leverage what I learned from free-format (and procedures) to help me learn other truly object-oriented languages –- and more importantly architectural concepts -- that can be incorporated into my non-object oriented RPG environments. Rather than gripe about the new, let's spend our energies on embracing and conquering, rather than futilely fighting change.
About the author: Dan Holden is a lead software engineer at Enterprise Rent-A-Car and principal of AskWare Inc. in Saint Louis, Mo.