From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assembler)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Sat, 29 Aug 1992 07:46:11 GMT

In article <1992Aug27.135129.24542@usenet.ins.cwru.edu> rfd@po.CWRU.Edu (Richard F. Drushel) writes:
>
>In a previous article, lasner@watsun.cc.columbia.edu (Charles Lasner) says:
>
>>BTW, if HLL theory is that it abstracts what computers actually do,
>>then why the deficiency in so many languages regarding goto?  Do people
>>believe that computers lack program control branch instructions?
>
>	That is something I have always wondered...being a self-taught
>programmer, on the outside of computer engineering looking in, I have
>heard the dogmatic "All GOTOs are bad" philosophy, with nary the
>acknowledgement that the CPU does nothing *BUT* GOTOs.
>
[...]
>	HLLs may be constructed so that, for the user, every program branch
>must be expressed as a conditional.  But the machine-code implementation of
>those conditionals must be done with little more than GOTOs.  I understand
>that GOTOs give you more leeway to write obfuscated spaghetti, but just
>because you *CAN*, doesn't mean you *HAVE TO* :)

A story was related to me (so pardon any specific detail distortion, the 
premise is what's important) as to what actually was the driving force behind
"spaghetti code" that the dogmatic people were referring to.  (This is not to
say they aren't correct in some individual cases, but the following is a
"defense" against some possible "bad" examples they may have pointed fingers
at.)

Back in the "days of Mel" +/- a few years, there were no editors as such, and
in fact programs weren't stored in files at all.  The program had a quite
physical appearance: a deck of handkeypunched cards, usually interpreted on
the top at the time of punching.  While copies could be made with various
unit-record gear around the typical computer center, said copies lacked the
actual type-face quality of the keypunch itself.  Some posters have pointed
out that you could get multi-line output in strange columnar orientation if
you wanted, but by and large, the card had the statement on the top, and as
you prepared your program input, you referred to the printed copy on the top
of the card to keep track of your editing, which was largely localized card
replacement or add/deletes at selected portions of the deck.  In fact, many
people stuck blank cards in at right angles to the deck to mark places where
the changes were being made, etc.  (Also, cards that had been reproduced for
any reason might be run through the *middle* station of the keypunch to
cause a duplication of the card to occur.  Thus, an uninterpreted card was
used to create a clone of itself with print on the top, and replaced by the
clone, and it was discarded.  This was wasteful, but we all did it periodically
for this purpose, and also for selective duplication.  You could get quite
adept at when to stop at the column for a manual change, followed by likely
copying the rest of the card.  Then you discarded the obsolete card and
replaced it in the deck at the former position, etc. as necessary.

This was how programs were created; no defense is necessary, that was the
primitive editing "environment" that was back then.

Most languages, such as FORTRAN, ignored columns to the right of some limit,
such as column 72.  It is interesting that while eventually there were 80
column terminals perhaps to imitate the card, teletypes imitated the 72
column width of the "useful" columns relative to Fortran implementations and
the like.  (Some languages could specify "source margins" as to what columns
were to be ignored, defaulting to 1-72, ignore 73-80.)

A smart programmer would have his cards sequenced, i.e., have sequence digits
punched in 73-80 so that should the cards ever get dropped (yes, that did
happen, especially on big programs that were many feet of cards long), they
could be sorted back to intended order using unit-record sorting machines
that were commonly available.  (A side story: the only known copy of a
PDP-8 program, I think an 8K version of LISP or something was brought to
DECUS as a card dec without sequence numbers, and it got dropped, and never
was put back together again properly, so the program died :-(.)

Sequence numbers are chosen at intervals that are likely to serve your needs
of localized program growth.  Often, programmers would choose poor values
for this increment yielding some localized problems: it wasn't possible to
stick the required cards in-line where needed without violating the sequence
numbering convention.  You could "cheat" a little by almost duplicating the
next card after your insertion, assigning it a higher sequence number manually
to make "room" for the intended edit, but eventually this is not only greatly
distracting to your edit, but it eventually fails when several greatly added
sections meet.

Programmers were loathe to change their source decks for descendent decks
copied with new sequence numbers.  (The utilities to do this existed of
course, but then the print interpretation on the cards gets lost unless you
manually dup the card on the keypunch and toss the unprinted card.  Not a
practical solution for a long deck; it wasn't done; you put up with your large
deck that just got larger as you added features.)

So, how do you add an in-line section of code when you can't?  You punt!

The programs would add a GOTO XXXX where XXXX was some quite high line
number, perhaps semi-associated with the sequence number at the end or nearly
so of the deck as it now has grown to.  There you find the code that would
have been preferred to be back where the GOTO XXXX statement is now, followed
at the end by a GOTO YYYY where YYYY was the line on the next statement after
the GOTO XXXX card.  This implies two other non-obvious overheads:

The programmer may choose to "demonstrate" his frustration, perhaps with an
eye towards theoretically fixing it in a later release "for publication".
Remember, a lot of programmer's work wasn't looked at by anyone else, ever.
A proud programmer might recreate a sequencing that avoided the problem to
simulate a cleaner implementation of the final product while avoiding the
actual hazards along the way, etc.  Towards this end, the closed section
of code physical at the end of the deck would have a master GOTO YYYY at the
end in a semi-formal way, because it was the key statement that should have
never been there.  Thus, in this little insert (that may not be so little)
could be found GOTO YYYY directly to get out of the section, or even GOTO ZZZZ
where ZZZZ was the label on the GOTO YYYY card at the end of the little section
all in support of there being only one extraneous statment there (and of course
an additional extraneous statement back at the GOTO XXXX).  Remember, we are
not talking about a programmer that, allowed to do a free-form edit, would
ever use a GOTO to another GOTO, but in this instance only, it was de rigeur.

The other source of overhead has to do with the programmer's choice of the
level of "intrusion" this mechanical GOTO-implemented edit has on the
intended place for the section (as opposed to the end of the deck where it
wound up.  Remember, multiple iterations of this method make the deck even
longer, since the end is nothing more than out-of-context editing sections
with GOTOs on them to get back to where they would have been wanted.).  The
programmer might choose to stick an "unwanted" label on the next line, which
causes that line to seem to be the object of other statements wanting it as
a branch point.  (This is technically true of course: the GOTO YYYY being the
only case generally; had the problem not existed, this statement wouldn't
have a label on it.)  An alternative was to place a CONTINUE statement after
the GOTO XXXX statement with the YYYY label on it, since this doesn't change
the next active line, and is possible a better choice under the circumstances, 
but does tend to make the deck longer, and might be one more problematic
sequence problem in and of itself.

Regardless of choice, the program is quite confusing: GOTO statements that
seem to branch off to nowhere, but somehow come back, possible to CONTINUE
statements that don't seem to be needed, or possible to the next line with
a dubiously-required label on it.  When you examine the rear end of the
deck, you find disjoint sections of code which goto somewhere else at the
end, "miles" away from where you are now, and whose neighbors are just as
confusing.

The programmers could have resorted to some "formal" techniques, but
excessive modularization for its own sake hadn't been invented yet.  (Computer
Science would introduce that dubiuous concept years later: break programs up
into *small* modules because "it's better" that way.  Notice I didn't say
modules, just an arbitrary definition of "small".  Programmers should attempt
to seek a proper balance of modularity with functionality.  There is often
too much emphasis on size per se.)  In any case, it was understood that the
program wasn't meant to have a subroutine call placed there, but merely the
unwanted overhead of a GOTO that would be matched at the other end by another
GOTO to get back, and that this portion was the only "caller" of the misplaced
section.  (Further, the section was an editing section, not a logical section
of program code; no one writes into subroutine form a portion of a routine.
This always applied, even in the days of this mechanical editing kludge.  Also
all of this garbage encourages lack of documentation, as well as the obvious
maintenance problems.)

So, here we have programmers writing good quality code on average, forced to
turn their programs into what a naive critic would call "spaghetti code"
when in fact, given an editing environment of machines a few years down the
pike, this never would have happened.  Further, the overall quality of the
program otherwise, would often lead to it being maintained even years later
(now on a better editing system where the problem doesn't apply), only to
be a maintenance headache for a newbie who concludes (unjustly so) that his
forerunner, the original author or previous maintainer, was a really bad
programmer.  In all probability, the newbie is the lamer of the two, but
the original guy takes the heat.  Sum up all of these kinds of cases, and
you wind up with a "political movement" that wants to declare GOTOs to be
dangerous because "spaghetti code" exists :-(.

cjl
Newsgroups: alt.folklore.computers