The death of GOTO

[Storebought]

The death of the GOTO statement

And the rebuttal:

1 Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.
2 The easiest machine applications are the technical/scientific computations.
3 The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.
4 FORTRAN --"the infantile disorder"--, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use.
5PL/I --"the fatal disease"-- belongs more to the problem set than to the solution set.
5 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
6 The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
7 APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums.
8 The problems of business administration in general and data base management in particular are much too difficult for people that think in IBMerese, compounded with sloppy English.
8.5 About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead.
9 Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
10 Many companies that have made themselves dependent on IBM-equipment (and in doing so have sold their soul to the devil) will collapse under the sheer weight of the unmastered complexity of their data processing systems.
11 Simplicity is prerequisite for reliability. [Handwritten annotation]
12 We can found no scientific discipline, nor a hearty profession on the technical mistakes of the Department of Defense and, mainly, one computer manufacturer.
13 The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity.
14 By claiming that they can contribute to software engineering, the soft scientists make themselves even more ridiculous. (Not less dangerous, alas!) In spite of its name, software engineering requires (cruelly) hard science for its support.
15 In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included.
16 Projects promoting programming in "natural language" are intrinsically doomed to fail.

Isn't this list enough to make us uncomfortable? What are we going to do? Return to the order of the day, presumably

http://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html

[○∙◄☻¥tπ[╪AV┼cVê└]

You seem to way overestimate the difficulty of programming. It is a lot easier than pure mathematics research.

[Gabu]

Looking at the dates on those pieces of writing, I think we can safely say that their predictions of doom and destruction fortunately did not come true.

[True Federalist]

That's because the use of GOTO is largely gone.
It's use in early computer languages was because they didn't have nice built-in structures such as for loops and else clauses.  Even when they were retrofitted onto those languages, there was a large base of existing code (and of existing programmers) that continued to use GOTO's instead of the structures.

[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.

[True Federalist]

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.

[Gabu]

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.

[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.

[Gabu]

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.

Well, yes, it's not impossible to read code that uses a "goto" statement instead of an abstract type of loop or branching statement; it's just more difficult.  Plus, there really is no real reason to have explicit uses of "goto" in code anymore unless you need to really, really optimize something to absolute death.

[Erc]

My first exposure to programming was BASIC, and I sort of missed the Goto when i was first started looking at C++.  And, in a way, it can make the programming simpler for some sorts of programs.  But I can definitely see the problems with it, and don't miss it anymore, especially now that I know how to use OOP.  It may be a bit slower, but the less obfuscation the better imo, even at the expense of some speed.

[○∙◄☻¥tπ[╪AV┼cVê└]

My first exposure to programming was BASIC, and I sort of missed the Goto when i was first started looking at C++.  And, in a way, it can make the programming simpler for some sorts of programs.  But I can definitely see the problems with it, and don't miss it anymore, especially now that I know how to use OOP.  It may be a bit slower, but the less obfuscation the better imo, even at the expense of some speed.

C has a GOTO statement, there's just generally no reason to use it.

[Gabu]

My first exposure to programming was BASIC, and I sort of missed the Goto when i was first started looking at C++.  And, in a way, it can make the programming simpler for some sorts of programs.  But I can definitely see the problems with it, and don't miss it anymore, especially now that I know how to use OOP.  It may be a bit slower, but the less obfuscation the better imo, even at the expense of some speed.

Yes; without the goto statement, you can't do something like this:

#include <stdio.h>

void function1(void)
{
  printf("I feel so rejected.\n");

label2:
  goto label3;
}

void function2(void) { goto label1; }

void function3(void)
{
label1:
  goto label2;
}

int main(int argc, char *argv[])
{
label3:
  printf("PLEASE GOD MAKE IT STOP\n");

  function2();

  return 0;
}

I'm just about ready to gouge my eyeballs out and I'm the guy who wrote that.

[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.

[True Federalist]

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.

Actually that depends on the machine.  While it's not true of early computers or of modern RISC architecures, CISC machines such as the VAX had machine language equivalents for loops and if/elses.  Partly that was because machine designers were looking for ever more features to add their architechtures without considering the speed implications of adding more instructions to the instruction set, but it was also due to the fact that there a period during the 60's and 70's where the ratio of processor speed to memory speed was higher than it was before or since, making the use of specialized instructions so as to reduce the number of memory accesses a way to increase overall speed.