a companion discussion area for blog.codinghorror.com

I'd Consider That Harmful, Too


#1

One of the seminal papers in computer science is Edsger Dijkstra's 1968 paper GOTO Considered Harmful.


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/10/id-consider-that-harmful-too.html

#2

The Language Log website is interesting – thanks for the link!


#3

Someone should tell the Codebetter.com folks about writing persuasive articles instead of insulting everybody that’s not part of their cult.


#4

http://catb.org/jargon/html/C/considered-harmful.html

Amusingly, the ACM considered the resulting acrimony [from publishing “GOTO Considered Harmful”] sufficiently harmful that it will (by policy) no longer print an article taking so assertive a position against a coding practice.


#5

What is an early Return, or an early Exit For other than
a tightly scoped GOTO?

Exactly. Which is why I try to avoid them, too.


#6

Yeah, but that’s still nothing compared to the time some guy went topless at ACM SIGGRAPH: http://www.siggraph.org/programs/archive/reports/conference/2005/articles/papers/fast-forward-paper-session

Two years later the organizers were still traumatized.


#7

I’m fairly certain though that adding “considered harmful” to any post on programming.reddit.com guarantees at least 30% more votes.


#8

I’ve often pondered writing an “oxygen considered harmful” article filled with accurate and not misleading facts, just to see who would try to suffocate themselves and who would attempt to breath pure oxygen just to prove that they don’t think its harmful.


#9

@Jon:

Because if you really, really, really know what you’re doing, and you really, really, really need the performance boost that GOTO can sometimes provide (http://kerneltrap.org/node/553/2131), it’s good to have in the language. That being said, I never use it. Maybe it should generate a low-level compiler warning, and you should have to disable it with a compiler switch or a #pragma-type thing…


#10

I prefer this comic:
http://imgs.xkcd.com/comics/goto.png


#11

Jon Raynor,

Just like most instruction languages, MSIL fundamentally only has “goto” (aka “jump”) as it’s branch enactment. An “if” is re-phrased as “jump if” or (more commonly) “jump if not”. Do/while are re-phrased as “if” with appropriate loop control logic inserted. “switch” is re-phrased as either a series of “if…else” (most common) or an offset address jump table.

You only need to see how often “goto” turns up in decompiled MSIL code to realise that if a decompiler can’t tell the difference, there probably isn’t a difference.

“goto” was included for completeness, being the fundamental building block from which all other loop controls can be functionally constructed, to leave it out, is to make the statement “we are smarter than you”. No development team, no matter how high-profile, wants to make that statement (except Java).

Meanwhile, “goto considered harmful” should really be understood as “a high ratio of goto compared with lines-of-code is considered harmful (because readability drops off rapidly)”.

Jeff Atwood,

I’d be interested to hear your comparison of “goto” versus “exceptions”. I find it an interesting comparison myself and I’m still undecided if either should be labelled inherently evil.

Most people who praise the idea of exceptions; spit on goto.

But what is an exception if not a much more complicated, non-local, stack-linear version of a goto?

Of course there are numerous differences, but which ones are good?

  • A goto is local, you can’t jump out of the current stack-frame - an exception can jump to any point on the existing stack; worse, the stack will be unwound as it goes and this very act may trigger an exception that exceeds your catch clause level and jumps elsewhere.
  • A goto translates to a single intruction, it’s effects are easy to predict and even easier to emit in code. An exception generates an indeterminate number of instructions, it’s difficult to say, especially where a GC is involved, what will happen - even the compiler (or the VM in the case of C#) often takes considerable time to figure out what to do.
  • A goto states explicitly where the next instruction will execute. An exception? Who knows! Are there objects to be destroyed? Is there another catch clause you didn’t see in your human-frailed browse of the stack-frame? Is there a library callback inbetween the exception and your catch that might silently drop it and resume?

Go on Jeff, “exceptions versus goto”. You know you want to.


#12

I think Strunk White summarized it as “cliches in writing considered harmful” :slight_smile:


#13

GOTO(arrow symbol) is more natural than if/then/else when I draw flow chart before writing code.
So I think GOTO is more useful in graphical environment than text environment.


#14

It’s almost impossible for most of the programmers alive today to understand the world as it was when Dijkstra wrote that paper.

In 1968 the vast majority of source code was on PUNCHED CARDs (or punched card images stored on some media). Indenting or unindenting a paragraph required repunching all of the cards for each of the lines being shifted!

Changing the logic with a GOTO might involve just punching one card, and could be done in an hour or less. But reformatting a large chunk to not use the GOTO might really take days! (Write out the entire code section again on special coding pads that got sent to the keypunchers; wait for the punch cards to come back; proof-read all of them very carefully; submit a deck to insert the new, revised code into the PANVALET source data base; wait for that job to come back; submit another deck to compile-link-and-test overnight; etc., etc.)

So naturally, the more any given program or subroutine had been maintained, the more GOTOs and “spagetti logic” it acquired, until it was virtually unreadable
and unmaintainable.

It’s undoubtably true that programmers used more GOTOs before Dijkstra and fewer of them in the years that followed. And it’s certain that code quality (correctness and maintainability) improved along with that. However, I submit that it would be impossible to tell how much of that was due to the Dijkstra paper, versus how much of that was due to the introduction of time-sharing terminals that allowed programmers to edit thier source electronically in real time.


#15

One of the patterns I use to avoid ugly GOTOs is the do {…} while (0); loop

For some strange reason, my colleages all seem to think that this structure looks weird.

Example psuedocode:

do {
open__input_file();
if (failed)
break;

allocate_buffer();
if (failed)
break;

open_output_file();
if (failed)
break;

read_input_data ();
if (failed);
break;

... etc.

} while (0);


#16

Exceptions and GOTOs are very different things. Exceptions should be used for exceptional situations that you don’t want to deal with in the standard program flow, GOTOs are a sloppy way of writing the standrad program flow.
Yes, there’s people that uses exceptions for non-exceptional situations and that is bad (and very inefficient). But this doesn’t make GOTOs better, using GOTOs stays wrong, using Exceptions as a substituite for GOTOs is twice wrong:

  1. because you are misusing exceptions
  2. because you are using GOTOs.

#17

I’ve often pondered writing an “oxygen considered harmful” article filled with accurate and not misleading facts

Ah yes, reminds me of the perils of Dihydrogen Monoxide…

http://www.liveleak.com/view?i=3a9_1175530605

From the excellent and highly recommended Penn Teller series “Bullshit”.

http://en.wikipedia.org/wiki/Bullshit!


#18

The main point of Dijkstra was that with a goto in the code, you can’t proof mathematically that the code is correct. That’s still true today in OO languages.


#19
  • A goto is local - Not in the languages Dijkstra was talking about that is why it was potentially so bad to use them

The whole point of the paper was to show that the easy solution (goto’s) were a bad idea in the long run since the code was unmaintainable, and many programmers of the day used them in non-standard ways … what happens if you jump into a for loop …

A goto used properly as an optimisation in a clearly defined manner as an alternative to an exception or similar can be good but in most other cases it is a kludge where another statement would be better, clearer, and easier to maintain

The main thrust behind “Goto considered harmful” considered harmful is that yes goto’s are mostly bad but if people are put off ever using them then they can write less clear code simply to avoid using them


#20

The only time I see goto statements are in open source code…I know what that tells me!