Ok; I've now read the actual paper.
There is certainly some of that.
I think that a lot of his argument is that once you have a label that is the target of GOTOs, it becomes non-deterministic how you have reached that point if you're trying to analyze the "dynamic" behavior of the program - it all looks fine there on your programming form ("static"), but actual analysis is hard at runtime.
So, yeah, I guess that that's a thing. But it's largely a result of how programming languages were implemented and used back before 1968. If you look at BASIC and Fortran 4 (or 66) (the languages that I'm somewhat familiar with), there were no code blocks, and the only looping construct was a counting FOR-loop-like thing. There wasn't even ELSE...
BASIC had if (condition) then <linenumber> - so if/else code would look like:
100 IF (B > 0) THEN 200
110 REM B <= 0 (else clause)
120 C = COS(-B)
130 D = SIN(B)
130 GOTO 300
200 REM B > 0 (if clause)
210 C = COS(B)
220 D = SIN(-B)
300 REM end of if/else
Fortran let you put any single statement after your IF, so it'd look more like:
IF (B<0) GOTO 200
C else clause
C = COS(-B)
D = SIN(B)
GOTO 300
C if clause
200 C = COS(B)
D = SIN(-B)
300
Those are pretty awful. It's hard to say whether Dijkstra's point was more "don't use crappy languages" (which is how such arguments tend to be stated now - "my language has this great feature that allows better clarity in the expression of ideas!") See also Timeline of programming languages - Wikipedia
(Just for completion, here's C/C++):
if (B >= 0) {
C = cos(B);
D = sin(-B);
} else {
C = cos(-B);
D = sin(B);
}
I ALMOST think that part of the argument includes "if you use GOTO, it should be in the context of standard code structures like if/else, while loops, and so on. While the above code is pretty ugly, it doesn't get really bad until some other part of the program does "goto 300" or (worse) "goto 200"!
presented as a Flow Chart
Not fair. A flow chart is biased toward "goto-like" actions. In my PL/1 class where there were emphasizing "structured programming", they actively discouraged "flow charts" for that reason, in favor of another form of diagram (heh. Which doesn't seem to have caught on. NassiâShneiderman diagram - Wikipedia, I think? (oops. Already mentioned. I confess to have only scanned the 100+ messages in this thread.) The whole diagramming thing wasn't THAT strongly encouraged; sort of "if you use proper code structures, it's probably obvious.")
You want this, right? Which IMO is clearer than the flow chart in the first place.
while (!elapsed(3*ONESEC)) {
if (buttonOpen()) break;
}
LED2Off();
Or perhaps:
while (buttonClosed()) {
if (elapsed(3*ONESEC)) break;
}
LED2Off();
to you!