|
You're probably right... I just sort of made that up as I went along, but I was simply trying to illustrate that constructs such as level breaks are easily reproduced in the modern paradigm.
I'd like to clarify that I do not necessarily think cycle dependent programs are inherently evil, but rather that it takes siginicantly more effort to understand the implications of cycle dependent features. First and foremost, the cycle forces the developer to make use of indicators to drive their logic. Now, I'll admit that as far as indicators go, the Lx and Mx indicators are pretty descriptive as to their function, but one must still have a full understanding of when and how those indicators get flipped. There is no opcode that describes these activities, so clarity of intent is not expressed in the resulting code.
Additionally, I personally find doing MR logic in the cycle to be counter-intuitive. When I want to know if fileB has record subset matching the key from fileA, it feels much more natural to me to use chain or setll to determine if this relationship exists. It feels UNnatural for me to have logic in my program that says: If I've read from fileA, but not from fileB yet, then do nothing. The cycle has forced me into a design that feels awkward and counterintuitive.
FWIW, I'm not trying to take anything away from anyone. If the cycle works for you and your shop, then good for you. Just don't be surprised if someday you can't find seasoned veterans of RPG who can maintain this code....
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.