|
> From: Hans Boldt > > If you're maintaining old fixed-form code, stick with it. <snip> > I think we're still waiting for compelling reasons for such features. This is why you and I differ so greatly, Hans. I stand for the traditional development shop that has hundreds of thousands, if not millions, of lines of traditional RPG code. The folks whom, if it weren't for them, you and I would not have our current jobs. You, on the other hand, are adding features to your new language which these legacy shops cannot use unless they start embedding /free and /end-free in their code. (And please don't tell me it's not a different language. Anything that requires a compiler switch to change syntax is a new language. If it wasn't, then embedded SQL should also be considered RPG. And any generous interpretation of that got chucked out the window with the concept that you will add BIFs to free-form that aren't supported in RPG.) Not only that, you continue to resist a %MOVE BIF that would remove 90% of the difficulties associated with moving from fixed to free-form. Why? Because it's not elegant enough for you. It would generate ugly code. So, your opinion of beauty is sufficient for you to deny a feature many could use. And they call me arrogant. However, I'm willing to work with you. I'm proposing a solution that will allow fixed-format shops to begin to make the transition to the new format. It's a sort of half-way point, with fixed columns, but the new syntax for the non-opcode portion. Nothing fancy, a simple transition. For when a program reaches the point where it would benefit from new BIFs, but I don't want to remove the MOVE opcodes just yet, or pepper the entire program with /free and /end-free. Then I replace the MOVES with the appropriate EVAL, with the ability to use %MOVE on those that I really don't want to spend the time testing. And then finally, I can throw the switch and reformat everything from fixed-format-extended to free-form! This, to me, is an awfully sane and lucid argument, and it helps all of those legacy shops out there. So, in essence there are millions and millions of lines of old code out there that would greatly benefit from a couple of VERY MINOR features that allow a simple, staged transition from RPG IV to free-form RPG. This benefits legacy companies for reasons of maintenance, standards, training, retesting, just to name a few things. But you don't consider these compelling. You don't really care about legacy shops. I do. That's why we think differently. However, it's painfully obvious to me that the majority of the posters on this list agree with you. Evidently they, too, no longer worry about shops that have little or no time for education, older coders who don't really want to learn new things, and backlogs up to their ears that prevent a wholesale conversion of MOVEs to %editc(num:'X') for what would in effect be zero gain - and in fact would require some pretty serious additional testing. I don't know about the READERS of this list, the lurkers. Maybe they, too, no longer worry about legacy code. Perhaps the majority have been convinced by the erudition of the elite group that old code doesn't deserve these new BIFs, and that all new code should be written in free-form, regardless of your shop standards. Regardless of the fact that it would require retraining, and probably redevelopment of all your skeleton programs. Regardless of the fact that older programmers might not make that leap. But if that's the case - if this list has become one where the majority of the discussion is about new BIFs that only free-form can use, where legacy code is considered "old code" that doesn't deserve to be upgraded, where traditional RPG is thought of as a dead language, then I really have little to contribute. You will have become elite. And I folks, while contentious, abrasive and arrogant at times, am anything but elite. Joe
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.