Goto Considered The Best Programming Practice Ever Invented

This is a "joke topic", but an interesting point can be made. What if a group of Goto-favoring developers said Goto's were great, and they were productive by all observable standards. This is how many see their unpopular or "not in style" techniques and paradigms. They are comfortable with them, yet rejected by the mainstream. Nobody has proven Goto's objectively worse in a mathematical sense. We just don't like the way they "feel" to us, but have a hard time turning these into something objectively observable. They hurt our brain, but not theirs. So, why complain about goto proponents?

To extend your metaphor, it is instructive to look at the firestorm that erupted in the 1970s when this topic first arose, and also at the repeat flameware in CACM when this was brought up again in just recent years.
- (The latter was truly remarkable; everyone thought it was a dead topic from the past, yet CACM got zillions of letters, more than in decades, and had to forcibly shut down discussion after two issues and announce a new policy of never allowing the topic to arise again!)
In the 1970s, structured programming was a brand new idea, and a lot of people doubted that all programming could be done without gotos. It wasn't what they were used to, so at best they were doubtful. There was also, of course, tremendous amounts of misunderstandings: "how can I program in assembly/Fortran without GOTOs? That's impossible!", which is true but they didn't understand the point.
The modern bloodbath in CACM was interestingly different; by now everyone knows that, in languages like C etc, GOTOs aren't necessary, and everyone is used to (mostly) avoiding them. There were still zillions of flames, though, because of the just-will-not-die misunderstanding that, of course, yes, you have to ultimately tell the machine how to branch, and yes, if you're programming in assembly you have to specify those branches, etc.
Another part of the reason was the usual purists vs pragmatists. The latter would point out situations in their favorite language where avoiding GOTOs caused some kind of issue such as lessened readability, and the purists then proceeded to roast them alive for being neanderthals who "didn't get it".
Lastly, there was simply a lot of misunderstanding of each other's points, excess pedantry, digression, throwing weight around, ego, and all the usual dross of the human condition that comes up in flame wars.
There is every reason to believe that all of these factors figure into the current battles between the procedural weenies, OO weenies, beyond-OO weenies, relational weenies, etc. So now that you've brought up this analogy, remember historian George Santayana's maxim: "Those who cannot remember the past are condemned to repeat it." (and don't forget Schrader's Corollary: "Those who study history are doomed to stand by and watch it be repeated - in real time.")

In the end goto's won not necessarily because they were necessarily objectively better, but because it became a stigma to use them and it is easy to verify "violators". OO (and other paradigms) are not so easy to verify since many shops which claim to be OO simply make procedural classes.

There was never any study which showed that goto fans were slower or had more bugs than block fans. I personally prefer blocks, or mostly blocks, because indentation offers visual clues about flow for my eyes and because it introduces consistency that I otherwise cannot identify in goto's (if there are goto patterns, I have not seen them documented). But I would not say to a goto fan, "you are wrong, you old fart!" However, I might try to convert them because I would not want to maintain their code. Or, at least work out some compromises.

Suppose that person or group went to every page that touched on more modern forms of flow control, or any page slightly related to it, and put the same argument on all those pages. "Why can't you just use the simple goto? It worked fine when all we had was BearSkinsAndStoneKnives, it still works now."

I think after a while a pattern would emerge such that the arguments can be factored into discrete topics. Then a topic link can be inserted in place of the viewpoint text. If they are responding to similar claims, then perhaps the duplication is in the original rather than the response.

The WikiWay would be for the emergent pattern to be refactored into discrete topics referenced from other, relevant, pages. The AntiPattern which inspired this page is the practice of repeatedly placing the text of the same unclear argument with minor changes on many pages. Often the pages on which it appears are marginally relevant at best.

{I do agree that there was poor factoring overall, not just anti-OO stuff, but I disagree that it was irrelevant.}

Also, you will likely offend goto fans by automatically presuming that their technique is more primitive than nested blocks just because it came first. New == Better is not a very solid position. For example, web-servers have returned us to a mainframe-like mindset. Calling goto's bear-skins would be unwise, likely to trigger a FlameWar.

So let's remove any wisdom we may have accumulated over the years in case some of it might offend someone.

ArgumentFromAuthority has its place. However, it should not be the primary determinant of truth. For one, it is hard to separate personal preferences from absolute, external truth.

I wonder what Djikstra's position on ArgumentFromAuthority was. Besides, GOTO is just a language specific wrap of the JMP assembly instruction . Perhaps AssemblyJmpConsideredTheBestProgrammingPracticeEverInvented? is more universal? Hrm. . . Then we get into VacuumTubeRelayConsideredTheBestProgrammingPracticeEverInvented?. . . but that devolves into BabbagesRotorsConsideredTheBestProgrammingPracticeEverInvented? which devolves into LogicConsideredTheBestProgrammingPracticeEverInvented?. . . which ironically seems true, but only for a different definition of logic. Besides, that devolves into the caveman's SwitchingRocksConsideredTheBestProgrammingPracticeEverInvented?. . . My Kingdom for a universal abstraction taxonomy!

I am not sure what your point is here. It seems to have some kind of "slippery slope" argument that could be applied to anything. For example, one could take OO's origins in Simula-67 and extrapolate that to mean everything should be forced into a physical model even if we don't need a physical model.

Well, I was trying to make fun of the idea that GOTO is the best programming practice - because it's so archaic. It would be like arguing that ApplesAndOrangesAreTheOnlyMathYouNeed?. GOTO is a foundation that functions and methods are built from, trying to apply it at a high abstraction level is like trying to apply quantum physics to world literature. On a more serious note though, I think arguing for GOTO is a symptom of the big problem - that abstractions are always relative. While 99.9999% of the time GOTO is the wrong choice, other things like get() and set() encapsulation aren't as clear.

To follow this analogy, calling something the "wrong choice" is not helpful unless you can show that it is the wrong choice without ArgumentFromAuthority. Remember, the opening statement assumed that goto fans were just as productive as block users.

Re: "Those who cannot remember the past are condemned to repeat it."

Has anybody saved example discussions for historical purposes?

Not so historical, but there was an amusing episode about a year ago:

http://www.ussg.iu.edu/hypermail/linux/kernel/0301.1/1477.html

It is nice to see the gap between dogma ("I just saw a goto and gasped"), and the detailed arguments in defence of a fairly liberal sprinkling of goto in the Linux kernel code.

Of course, an OS kernel is not a "normal" project.

Conditional forward gotos with a one-to-one relationship with their target can be replaced in a very immediate and straightforward manner with an if construct:

 if (condition)
goto target;
 ...
 ...
 ...
 target:
 ...

becomes

 if (!condition)
 {
...
...
...
 }
 ...

which most people would consider cleaner and easier to read. Such was the case of the "goto gasp" in the Linux kernel. The above aproach works regardless of the presence of any returns or gotos in the skipped statements because the if construct translates directly to the goto statement that is used in its place in the Linux code suggestion. However, I would say it's frivolous to make such remarks in a place where gotos are acceptable, since this is a very simple use of goto and the code is very short: its presence is a matter of habit.

Personally, I think that if a project benefits from the use of gotos, it should use gotos. Java is a language where the goto statement is not available. However it has labeled blocks and labeled break and continue statements, which the C language lacks. I believe that the language designers put these features there because they knew from experience that structured programming is not always ideal. My own experience confirms that: being a Java programmer, I have had a handful of situations where these special Java features proved invaluable. Intrestingly, they all arose in input stream processing.

Both sides have merits, the best thing to do is to learn where to use each.

CategoryBranchingAndFlow