The death of GOTO

[muon2]

The GOTO statement (or equivalents) is really quite alive, and cannot die. At its most fundamental level it must exist in the machine code since the program counter that keeps track of the place of the next instruction needs a mechanism in jump out of sequence. Since it is required in machine code it also must exist in all the assembly languages that are the only mechanism to create machine code.

The question then moves to higher levels of programming. Since most programming languages have a need to emulate assembly language instructions at times, the GOTO (or equivalent) still exists in those higher languages. For example Visual Basic (VBA) still keeps the GoTo Statement, and the Excel 2000 Bible section on VBA fundamentals says this about it:

"Programmers generally frown on using a GoTo statement when not absolutely necessary. Using GoTo statements is contrary to the concept of structured coding. In fact, a GoTo statement makes the code more difficult to read because it's almost impossible to represent a loop using line indentations. In addition, this type of unstructured loop makes the procedure more susceptible to error. Furthermore, using lots of labels results in spaghetti code -- code that appears to have little or no structure and flows haphazadly."

Note the use of "not absolutely necessary" in the above quote. It is necessary sometimes to use GoTo. The most common reason is speed. The closer the higher-level language looks like assembly code, the easier it is for a compiler to minimize to use of excess instructions. Thus, a program using GoTo can be made to run faster than an equivalent structured code - if the programmer knows what they are doing.

In practice, large programs value maintainability over speed, so structure wins out over spaghetti. But there are still plenty of critical code applications that still benefit from judicious use of GoTo.

[muon2]

Even now, most acceptable uses of GOTOs could be transformed into structured programming, if the appropriate structure were available.  However, these structures are numerous and individually of little use, it doesn't make sense to code them just to get rid of the humble GOTO.

What muon2 was talking about is that it's impossible to remove the "goto" type of statement entirely, because anything that disrupts the linear execution of commands must use some sort of "goto" statement.  There are no "while", "for", etc. loops, nor are there "if/else" statements, in machine language, which is what all programs eventually become.  There's only the "goto" sort of command.  Loops, branching statements, etc. in high-level languages like C++ and Java are all simply abstractions that make you unable to royally screw up your program flow through the misuse of "goto" statements.   They all get translated into "goto" commands that are executed if a certain condition is true when you compile your program into machine language.  So, in this way, it is true that full elimination of the "goto" statement is simply impossible.

However, that does not mean that the explicit call of a "goto" statement in a high-level language should be allowed.  I'm personally of the school of thought that it shouldn't be.  While it's true that you can get some marginal benefit in speed if you use it, the danger is way, way too large unless you know exactly what you're doing when you do it, and even then, it makes code very unreadable to have no indentations or anything to set the contents of a loop or a branch statement aside from surrounding code, especially if you have multiple nested types of these statements.

Experience watching those around me makes me tend to support your argument. And for most applications it makes sense.

However, I've been programming since 1969, and the GOTO statement was mandatory back then. I was exposed to flowcharts (with branches equivalent to the GOTO) since 1964 and played with them before I had access to programming. From my exposure to branch statements early on, I have no problem reading linear code. This has been a great boon when I've had to write real-time data acquisition code, device drivers, and direct machine code.

When I teach advanced electronics I always include a discussion of the branch in digital machines. I find that knowing what really goes on in the computer is a great aid in understanding problems that may arise in actual use.

[muon2]

Some observations:

It is interesting that the natural tendency of people to describe small to moderate sized tasks is to use conditional and unconditional branches. For instance in Monopoly the instructions to go directly to jail, and to go directly to GO, use the language equivalent of a GoTo statement. The original flow chart was a tool that captured that type of usage. For short task descriptions a structured approach to language is awkward to read.

For large organizational descriptions, a structured approach is the clearest. This is due to the the natural tendency to divide the large organization into subunits. At that point any description of tasks is clearest if the subunits can only interact in limited ways. The restrictions of points of entry and exit to subunits is the definition of structured design.

If truly optimal readability were desired one would restrict the maximum number of instructions in any one subunit, and require that interactions between subunits were fully structured with no branches. Then within the small space of a subunit permit a local branch that cannot take one out of the subunit.

The problem is that language rules do not easily allow the distinction between branches within a small set of tasks and across a large set of tasks.