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