"Please don't fall into the trap of believing that I am terribly dogmatical about [the goto statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!"
They're gotos with restricted semantics, just like every nearly every other control flow mechanism.
The restricted semantics makes it interesting without going into "an authority said they're ok". Abstracting so that you can more easily reason about (and you can explain to others so that they can more easily reason about) the full state space something can operate in is a not terrible definition for engineering in general.
Lol, they're common patterns even in asm. I've programmed plenty of systems that don't even really support C that well, and you end up doing the same things.
> Please don't ever code on a project I care about.
What a visceral reaction to me saying that `return` isn't an inherent truth but rather an artifact of network effects! I never would've expect this level of vitriol for this comment.
It's important to ask "Compared to what?" The Fortran prominent in that era was a mess of unmaintainable spaghetti code. Structured programming is generally a much better programming paradigm compared to spaghetti Fortran and that was Dijkstra's point.
Just because Hindley-Milner cannot catch all possible type-related problems, that doesn't make it a bad idea. Likewise structured programming cannot replace all uses of goto, but it would be ridiculous to go back to spaghetti code as the default setting.
I had a really cool internship fifty years ago (when I was sixteen.)
The group was doing pioneering electrocardiogram recognition (now the commomplace monitor beep beep beep). We had a bunch of scary-smart M.D.-Ph.D doctors figuring things out.
And I got to try to make sense of all their code and make it work together. I remember putting copies of Dijkstra's Damation article all over the place so those guys would read it.
They did read it. They liked it. They talked about it.
And then they started to be able to debug their stuff and get it working together.
Ok, if you desugar structured programming you get gotos... I fail to see both what is news and what is the point.
Of you can use gotos in a way that do not break the structure, yet removing it from the language makes your usage correct by construction. Does the author not see value in that?
I think goto is a good thing to have, although (outside of assembly language) it would mostly not be needed since other ways would work better. The example given there probably should not need goto (since it is just a simple loop), although if it uses goto, that isn't much of a problem anyways.
A break and continue statement is basically like a goto, and in some cases is more convenient since it automatically knows where the target is and you do not have to add a label there yourself. But, a return statement is not really the same as goto (although some instruction sets, such as MIX, implement it as such).
There's also techniques to convert unstructured flow into structured to aid in checking for correctness. Here's a random example I found looking for ways to deal with goto:
—E. W. Dijkstra