[TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary

[Rich Morin]

> On Mar 9, 2023, at 15:18, segaloco via TUHS <tuhs at tuhs.org> wrote:
> 
> GOTO is one of those paradoxical things where I would only trust the most sophisticated engineer to know when it's acceptable to use a GOTO but on the flip side would be suspicious of anyone claiming to be an engineer that uses any amount of GOTOs...
> 
> Were any of the various GOTOs in languages ever meant to be any more than providing the same level of control that branch statements in assembly do?  Was there ever some vision anyone's aware of concerning a sophisticated, dependable use of GOTOs?  Since my first days poking around learning C GOTO has been mentally filed away as an assembly vestige for folks in transition, not a dependable construct in its own right.  Any alternative camps out there?

COBOL's ALTER statement is kind of analogous to a computed GOTO, but it adds a dangerous aspect of "action at a distance" (i.e., monkey-patching which invisibly modifies the control flow of the original code):

	"The ALTER statement changes the transfer point specified in a GO TO statement"
	https://www.mainframebug.com/tuts/COBOL/module7/Top18_COBOL_ALTER_statement.php

	"The ALTER Statement"
	https://www.microfocus.com/documentation/visual-cobol/vc60/DevHub/HRLHLHPDF803.html

The problem, IMO, is that the compile-time program flow can be invisibly altered at run time, by code anywhere else in the program.  So, there is no requirement that a given branch, GOTO, or noop statement will have its compile-time semantics.  If used with restraint, this be used to optimize code paths, but it can easily be overused.  

Just as a GOTO is a surfacing of the assembler branch instruction(s), the ALTER is analogous to an old assembly-language trick (aka hack): dynamically modifying "br*/noop foo" commands.  FWIW, I didn't use either the ALTER or the trick in my own code, but I did keep them in reserve (:-).

In one of my earliest COBOL projects, the code came to me with an infestation of ALTER statements: specifically, a hierarchy of IF statements with ALTER statements at various levels.  This was used at startup time, to configure the remainder of the program.  All very elegant, but really overkill for the task at hand.

As I explained to my boss, the ALTER statements made the code really difficult to understand.  With his permission, I removed the nest of ALTERs and reworked the remaining control flow as needed.  I was greatly assisted in this by the fact that I could retain the DATA DIVISION as-is, and merely implement the (rather prosaic) control flow that we actually used.

And no, I don't want to return to either assembler or COBOL (:-).

-r