|
A hearty Bravo! One of the most important points I got out of this article, and it should be, was the discussion about programming skills. Back in the trenches, roll out is key, key. Keeping up a high effort level, that's a whole other program, especially on a Monday! Rob > -----Original Message----- > From: Reeve [mailto:news@xxxxxxxxxx] > Sent: Monday, February 16, 2004, 8:24 PM > To: 'RPG programming on the AS400 / iSeries' <rpg400-l@xxxxxxxxxxxx> > Subject: NOTO (or "no GOTO in FreeForm RPG"): The Empire Strikes Back > > <snip> > > Huh? Understanding a SELECT group is not intuitive?!! This is hardly > complex stuff here. If a SELECT group is too difficult for you, you have no > business being a programmer. > > </snip> > > > > Huh? Shoulda worn Nomex today...I'm sure the "you" in "you have no business > being a programmer" was the editorial "you"! And what should we say to > those correspondents making the weekly requests about coloring source code? > I can't decide if this is vigorous discussion or youthful impatience. > > > > My customers (many of the most prestigious names in the industry) have > purchased over 200,000,000 lines of iSeries ERP code I've written myself > (that number includes quite a bit of reused code, /COPY, etc.). This is > about business: my customers appreciate the functionality, style, > consistency, and stability in my application. In context (interactive > programs), my use of GOTO fits a very specific requirement, and I believe > the customers changing on my code long after I've left the premises > appreciate its unambiguous style (maintenance programmers are not known for > having a long attention span). Business is what I have, and TCO is the > primary reason organizations buy my application from me (a one-man company) > and an iSeries to run it. I stopped writing magazine articles (that you're > paid for once, usually) in 1980 so I could concentrate on writing code I > can, and have, sold and installed dozens of times. > > > > When I was in training for IBM, my final systems project was perfect with > one exception: the instructor said this System/3 OCL wouldn't work: > > > > // file name-master1,label-master ..as a direct file > > // file name-master2,label-master ..as an indexed file > > > > I neglected to mention to the instructor that this technique was in > production at several CCP accounts. Sales training, you know...John Milton, > if you're out there...stand corrected and sit down! (I've wanted to get > that off my chest for a long time). How much of what your instructor told > you have you rejected in the last 15 years? Plenty, I hope. > > > > I have had customers (all very nice people) who will look high and low for a > paper RPG manual to figure out SELECT, and they'll try to figure out what > that little "c" does in the middle of those I-just-don't-get-them "D" > specifications. And when they can't find a source member in QRPGSRC, it's > because I've deleted it (or at least that's what their voicemails say), and > then there's a certain amount of angst when the QRPGLESRC member pops up in > mixed case, with expressions, on their 80-column green screen. No, I'm not > referring to you, RPK! > > > > The reason the iSeries hasn't enjoyed the wild success of other platforms > isn't because of the use of GOTO's; it's because IBM's midrange offerings > were later to market than most other players to the GUI/browser environment > and offered (present tense, too) no integration to common business > applications available and popular today (Linux doesn't meet both conditions > yet). Modern programming constructs are required to support a more > sophisticated UI, but iSeries purchase decisions are frequently based on > applications and not on the availability of qualified data structures, etc. > API's haven't been around forever, gentle reader, and we're much better off > for having them available. > > > > Programmers are limited by what IBM provides, and IMHO IBM won the battle > but lost the war by enhancing the S/36 instead of pricing the AS/400 right, > developing an effective conversion tool, and dumping the 36 altogether (I've > stayed 36-free for a career). In the history of IBM's midrange family (my > history goes back 29 years), RPG has made real advances not in the last 29 > years but mainly with the advent of the iSeries, and I salute George, > Barbara, Hans, et al. for their contributions (I can't say it in Python). > > > > I don't think I'm tilting at windmills here. I believe the proper use of > GOTO reduces deep, complex, error-prone levels of nesting and eliminates the > requirement for switches, flags, and other non-structural techniques. > > > > I see many emotional arguments ("best practice", "Programming 101", "dying > out") against GOTO. "Best practice" doesn't mean "only practice" or "right > way", of course, and I wonder how many other "best practices" go into the > dust bin. I suggest the real problem in programming training is that it > usually teaches coding techniques and a programming language, not > programming skills. And I offer the possibility that the problems created > by GOTO mishmashes can be trumped by the problems arising from the use of > more complex (not "more elegant") coding structures to control program flow > (application logic is a distinctly different case), all in the interest of > worshipping the False Prophet Of Noto. Programming errors are a fact of > programming life; the key is minimizing them, and then making them easy to > identify and fix for the Unknown Programmer In The Future. > > > > Let's see what Google says about programming "best practices": > > www-106.ibm.com/developerworks/eserver/articles/hook_duttaC.html?ca=dgr-nxw0 > 2BestC > > > > First on the list: "Use a source code style that makes the code readable and > consistent." > > Way, WAY down on the list (around #25): "GOTO should be used sparingly" > > > > Dijkstra, Rubin, and McConnell have comments regarding GOTO; they're worth > reading. > > > > Back in the Dark Ages (apparently when I learned to code), program > readability was important. One of the big considerations was keeping a > meaningful hunk of code on a single page, so excessive page-turning by the > programmer was eliminated. Now, we have WDSCi and can flip CRT pages, but I > have to believe that trying to determine a program's function by flipping > around, even assuming the programmer is hip enough to use WDSCi's outline, > is not good. Obviously I have to brush up on my "best practices"; I'm > hoping to see "write it so the next programmer will understand it" somewhere > on the first page. And then we have the concept of a proper program, with > one entry point and one exit point (golly, if I don't understand SELECT, how > can I know this?); depending upon how far you decompose your code, this > construct could be hard to design properly...or should we design our systems > to be like PARS? > > > > The flap over GOTO's is a canard: the real problem is what's NOT used by, or > understood by, far too many programmers: prototyped calls, procedures, > embedded SQL, stored procedures, activation groups, BIF's, expressions, > WDSCi, that funny QC2LE binding directory, basic debit-and-credit > accounting, and industry knowledge. All of those features coexist very > nicely with GOTO! Besides, it's not the GOTO's, it's those pesky, > poorly-positioned TAG's that cause the problems. > > > > There's a lot of ease-of-use and functionality built into my example > (below), and a careful examination of the GOTO's will show no occurrence of > the GOTO "deadly embrace"...I hope... > > > > Tag1: > > Tag2: > > Goto tag1 > > Goto tag2 > > > > ...which is, I believe, the major problem with most uses of GOTO. An > extremely useful syntax check could have been a warning of deadly embrace > GOTO's; I'm highly confident such a feature will be absent from the next > "Vote for your enhancements" survey from the RPG team. > > > > Interesting...I just noticed only one TAG per main (non-HELP) panel. Do I > get any points for having a high GOTO/TAG ratio? > > > > Refactoring pieces is easy; it's doing the whole thing that's nasty. Nomex > on... > > > > Tag1: > > Display format > > Display file error > > Do something to recover and to redisplay > the format > > If cmd1 > > Display help > > Do something to recover and to redisplay > the format > > If not valid-command-key goto tag1 > > > > ***These lines are a group > > When cmd2 > > Inquiry1 > > Goto tag1 > > When cmd3 > > Exit > > When cmd7 > > Inquiry2 > > Goto tag1 > > When cmd12 > > Goto tag1 > > > > Application code > > When error > > Goto tag1 > > > > Tag2: > > Display format > > Display file error > > Do something to recover and to redisplay > the format > > If cmd1 > > Display help > > Do something to recover and to redisplay > the format > > If not valid-command-key goto tag2 > > > > ***These lines are a group > > When cmd2 > > Inquiry1 > > Goto tag2 > > When cmd3 > > Exit > > When cmd5 > > Inquiry3 > > When cmd7 > > Inquiry2 > > Goto tag2 > > When cmd12 > > Goto tag1 > > > > Application code > > When error > > Goto tag2 > > > > ...and so on... > > > > Considerations: > > The HELP panel is not required to use command keys, which is why it's coded > outside the implicit SELECT. The command keys are accessible from the main > panel or from the help panel. > > > > There are multiple panels in every application > > > > Each panel has a combination of standard and unique command key options. > > > > There may be a shortcut on the main panel to jump directly to other panels. > > > > This is a refactoring exercise; no alteration or reduction of user function > is allowed. If there is a better path, I will take it. But "better" is an > emotional response too! > > > > -------------------------- > > I've failed to mention the self-documenting nature of the GOTO/TAG > construct, possibly because I've failed to take advantage of that useful > feature myself. I'm paying too much attention to style; all my tags are > named TAGnnn. > > > > At this point, I have to GOTO the sandbox and then GOTO dinner. Or is it > DOU *FULL and DOW NOT *HUNGRY? > > > > -Reeve > > > > > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l > or email: RPG400-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. >
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.