8 ms·

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really under

Probably coming too late to the discussion, but commenting anyway... The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. Other than simple integer FOR loops, basically all control-flow in the FORTRAN of those days was accomplished with GOTO -- and to numbered lines, not labels. Things we take for granted in all languages today like { code blocks } didn't exist. Indeed the first thing you do when you try to understand code of that era is to print it out, get your markers out, and start drawing arrows all over the green-bar paper so you can start to make some sense of where control flow is going. In that world, yes, GOTO was a big problem and its use was rightly replaced with the structured control flow that we all use today. But that world has also been nearly gone for 30 years now. It's completely unrelated to using a C "goto" statement with a well-chosen label name in order to accomplish some otherwise-awkward control flow. On projects I've worked on I tend to develop a reputation for heavy goto use and I do so unapologetically. Sometimes it honestly is the cleanest way to implement something and I don't think it should be feared one bit. Just because it was a bad idea to do everything with a GOTO 60 years ago shouldn't mean don't do some things with goto today.

rstuart4133 5y ago
> Indeed the first thing you do when you try to understand code of that era is to print it out, get your markers out, and start drawing arrows all over the green-bar paper so you can start to make some sense of where control flow is going. The first thing I do is change the indentation to reflect the structure. The basic blocks then become obvious. If you don't do that (and most people in the era didn't), it's about as hard to read as left aligned C code. With it, it's not that much harder to read than indented C code. Unfortunately not indenting the code just reflected a bigger problem: programmers back then were totally oblivious to the structure indenting revealed or how they could be used to reduce the difficulty in reading the code: basic blocks, limited scopes and the like. It's not that they were lazy, it's that they didn't understand how code is built. Dijkstra taught computer science. That is what he was up against. At the time, all programming languages used goto almost exclusively for flow control. In some ways, it is the simplest way to do it. One construct did the job of the multitudes we use today: for, while, until and even recursion. However if you didn't follow some simple rules the goto's invariably ended up as spaghetti and the end result ended up being there was far more spaghetti in production than structured code. The two simple rules are: 1. backward goto's were only for loops, and 2. you must not goto inside an inner basic block. These are exact same rules for and while loops with {} blocks enforce. But it takes some self discipline to apply those rules, and no one is going to do it if they don't understand why they are important. Such understanding requires good high level intuition about how code is structured. It took a long while to teach such intuition. If you got rid of the goto's by replacing them with higher level constructs like for and while, you not only got rid of the problem - you also forced young students to think in terms of code flow. That is what Dijkstra was arguing for in "Goto's considered harmful". Today, times have changed. You very rarely see a badly structured goto in the Linux kernel code, even though C allows it. I'm not sure why that is - because I'm pretty sure if Dijkstra hadn't won out and Javascript and it's ilk still had goto's then shudder. The coding standards in web programming is a cluster fuck as it is: I swear there isn't a week go by when I don't come up against a broken web page. Just this week I was forced to fire up the browsers js debugger to change a field on a linkedin.com form, and manually do "$0.value = 'yes'" to move on. ffs. But yes, in projects with coding standards as high as the Linux kernels, everybody that (is allowed to?) contribute seems to have a very good understanding of how to make code that others find easy to read and understand, a ban on gotos would be counterproductive. Despite the discipline they require, gotos can be used to make the code cleaner and shorter. You see numerous examples of that in the kernel.
moffkalast 5y ago
Yeah to those still adamant about it, if you've ever used a: - function call - if sentence - any kind of loop You've used a GOTO under the hood. I hope you can live with yourself, you monster :)
- brundolf 5y ago
  But there's a reason we come up with sanctioned, constrained concepts built atop more powerful lower-level ones. Constraints in code benefit maintainability, correctness, and sometimes even performance. "Yeah to those still adamant about it, if you've ever used statically-typed code, you've used untyped assembly under the hood. I hope you can live with yourself, you monster :)"
- agent327 5y ago
  You put a smiley so I suppose it's possible you know better, but this kind of shallow, thoughtless critique is just painful to read, especially when following such a well-presented, historically accurate description of the debate surrounding goto. This is especially true given that Dijkstra himself refutes your argument, such as it is, in the opening paragraph of his seminal paper.
- GrumpyYoungMan 5y ago
  What's even worse is that, at the machine language level, condition and unconditional jumps are all that there are; we've all been using GOTOs constantly without even knowing it. :)
- 1-more 5y ago
  a case statement is the one where the GOTO peeks out the most, imo.
- andi999 5y ago
  The real hidden gotos are: - state machines - early return of a function
- masklinn 5y ago
  > You've used a GOTO under the hood. That it's under the hood is the point of using constrained control-flow control. It's significantly easier to reason about `if` and `while` and `for` than about `goto`. That is basically the same reason functional programming have more HoFs than `fold`. You can do everything with `fold` and that's a problem because it creates way more cognitive overhead for the reader, they can't know what the code is trying to achieve until they get all the details, nor is the compiler able to check anything. Likewise goto.
CJefferson 5y ago
I agree with you completely. I once made a poster (I wish I'd kept it) where I was tracing out the behaviour of a single mega function with around 50 labels in it, and gotos all over the place. I worked on a reimplementation, slowly picking apart the function into subfunctions, while loops, recursive function calls, etc. Took me about 2 weeks.
- munificent 5y ago
  That must have been so satisfying once it was done.
- prox 5y ago
  You maybe the right person to ask… Aren’t function / functioncallers a form of goto?
  - CJefferson 5y ago
    Technically yes, all code eventually compiles to goto, or goto equivalents (simplifying slightly) However, the idea behind "goto considered harmful" is almost all code can be written with function, loops and if/else statements and get just as efficient, and much, much easier to understand.
    - kazinator 5y ago
      All goto code can be mechanically translated into a network of mutually tail-calling functions arranged into an identically shaped call graph that is hardly easier to understand. What you can do with goto-based code is refactor it into a form that obeys certain conventions such that it is easy to mechanically translate to such a tail-call newtork, but then stop short of actually doing it. Then when reading the code, just pretend you're looking at function calls.
- kazinator 5y ago
  I could refactor a self-contained 50 label goto graph into a network of tail recursing functions pretty quickly; as little as an hour, in the absence of nasty confounding factors. If the goto graph implements a calculation with no side effects like I/O, my network will be all pure functions, too. Completely beyond the reproach of any CS academic. :) There is a mechanical way to do this. 1. We turn all of the function's local variables into function arguments. Each of our tail recursive functions will take these arguments. 2. Every labeled node becomes a function. 3. Every goto becomes a function call invoking the function that its target label was turned into, passing in each of its own argument to the corresponding parameter of that function. The function's return value is immediately returned. 4. Every variable assignment before a goto is turned into an argument expression in the function call which passes the new value to the corresponding argument. E.g. instead a++; d *= 2; goto foo; we have return foo(a + 1, b, c, d * 2, e, ...); Once you have this working, then you refactor. For instance, if you have a function like this: int foo(int a, int b, int c, ..., int z) { return a + c; } which does not pass its arguments to another tail-called function, then you can eliminate all of the arguments and just turn it into: int foo(int a, int c) { return a + c; } and of course edit all of the calls to foo accordingly, and simplify those places also. In this way, you will "discover" simpler functions that work with just a subset of the state transfer.
blntechie 5y ago
My first job was writing VB.NET code and it was hammered to us not to use GOTO. Once for a critical production bug, using GOTO was the quickest solution to fix and I used it with a comment to not fire me. And that code lived on for years.
- ehutch79 5y ago
  Sometimes a little bit of poison can make a great medicine. Goes both ways though.
0xffff2 5y ago
Can you give an example of where you've used goto in C or a C-like language? Or a rough estimate of the number of times you've found goto to be the best solution? I agree with your post in principle, but in practice I can't think of a single example where I've used a goto that wasn't eventually refactored to something better that didn't have the goto. Edit: Probably the most common example (and one given early in the article) is deeply nested loops. This is a good example of where I'm very unlikely to use goto. Almost certainly, I will prefer to hide one or more of the inner loops inside of a function call.
- mumblemumble 5y ago
  What's wrong with the examples in the article?
- codr7 5y ago
  https://github.com/codr7/ampl/blob/main/src/ampl/eval.cpp https://github.com/codr7/ampl/blob/main/src/ampl/eval.cpp
  - InfiniteRand 5y ago
    I'm sure there's probably a reason for doing things this way, but it seems like that code would make more sense as a function pointer table and a series of functions. Was that not preferred for aesthetic reasons or for some specific technical reason?
    - codr7 5y ago
      Speed. Your suggestion adds indirect memory access plus function call, for every instruction. I've tried every other way I can think of, and nothing runs faster from my experience.
  - slaymaker1907 5y ago
    Replying to infiniterand, a table of function pointers is going to generally have way more overhead than an indirect goto. An indirect goto is essentially a single assembly jump instruction. This is also often faster than a while loop plus switch since it is friendlier to the branch predictor.
westcort 5y ago
What I want is a language that consists ONLY of GOTO statements. The Turing tape concept indicates that it should be possible.
- schoen 5y ago
  Subtract and branch if negative is more or less that: https://en.wikipedia.org/wiki/One-instruction_set_computer#Subtract_and_branch_if_negative https://en.wikipedia.org/wiki/One-instruction_set_computer#S...
GrumpyYoungMan 5y ago
> "The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. ... Just because it was a bad idea to do everything with a GOTO 60 years ago shouldn't mean don't do some things with goto today." Every time this comes up, I always encourage people to read an excellent analysis by David Tribble "Go To Statement Considered Harmful: A Retrospective" that goes over Dijkstra's essay line by line and explains what it means in a more modern context: http://david.tribble.com/text/goto.html http://david.tribble.com/text/goto.html It really should be required reading in CS programs. I've used and still use goto in the few niches it makes sense to, primarily error handling and multi-level break in C/C++.
- wglb 5y ago
  This is a good balanced article. What is often missing from these goto discussions is the dialog between Knuth and Dijkstra on this topic. There is another discussion between the two of them about a problem requiring no less than four stacks to understand.
- User23 5y ago
  > "Dijkstra later abandoned the search for program provability and turned instead to the study of techniques for correct program derivation" It's odd how even today very few people in the "formal verification" world understand this distinction. Naturally verifying a derived program is trivial, since it's literally a proof by construction. I've attempted many times to explain this distinction, and they inevitably just start babbling about the limitations of the tooling they use. A sad case of man with a hammer syndrome and probably an illustration of my own failure to achieve clarity I guess. > "However, to some extent Dijkstra's principle has not been fully realized when we observe the complexity that must be dealt with by real-world programming tasks, such as multitasking, multithreading, interrupt handling" Dijkstra designed the first proven correct interrupt handler for a multitasking OS two years before the Goto Letter[1][2] so I think we can rest assured that he was aware of these issues. [1] https://en.wikipedia.org/wiki/THE_multiprogramming_system https://en.wikipedia.org/wiki/THE_multiprogramming_system [2] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/EWD196.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/E...
CodeMage 5y ago
This is my pet peeve with how they teach kids programming. Granted, I only have anecdata on that topic, gleaned from how they teach my own kid at school, but I still can't shake the feeling that we're doing them a disservice by making them skip straight to JavaScript or Python. I wonder what it would be like if kids started with BASIC. And not Visual Basic or any other modern, structured flavor. No, I mean the ancient stuff: 10 PRINT "All your base are belong to us!" 20 GOTO 10 Limited in what it can do, simple to learn, with just enough fun stuff in it (like PLOT, DRAW, INKEY$, INPUT, etc.) Then go on to assembly language, again on some very limited and simple machine, along the lines of the good old ZX Spectrum 48 or Commodore 64. Then move on to something like C or Pascal. Or even Python and JavaScript if you want. But the idea is that going through BASIC and assembly, they'll learn two important things: 1) how computers actually work (even though it's super-simplified, it should still be useful), and 2) why you need structured programming. Or maybe I'm just being naive. I really would like to see if that works out, though.
- gsinclair 5y ago
  I teach high school CS and have eventually come to the same insight, and found that novice programmers do indeed understand primitive BASIC much more easily than Python. Python seems simple to us, but there is so much abstraction even in its base-level syntax. I am gradually redeveloping my course materials to use BASIC (via replit.com) in the early stages.
1vuio0pswjnm7 5y ago
SNOBOL, the non-numerical computing counterpart to FORTRAN, also uses GOTOs, exclusively. I still run spitbol. Regardless of its assembly-like control flow, I think the pattern matching beats PCRE, and Lua's implementation of LPeg.
ouid 5y ago
I thought the problem with unstructured goto is that it is extremely hard to reason formally about code that uses it.

rstuart4133 5y ago

> Indeed the first thing you do when you try to understand code of that era is to print it out, get your markers out, and start drawing arrows all over the green-bar paper so you can start to make some sense of where control flow is going. The first thing I do is change the indentation to reflect the structure. The basic blocks then become obvious. If you don't do that (and most people in the era didn't), it's about as hard to read as left aligned C code. With it, it's not that much harder to read than indented C code. Unfortunately not indenting the code just reflected a bigger problem: programmers back then were totally oblivious to the structure indenting revealed or how they could be used to reduce the difficulty in reading the code: basic blocks, limited scopes and the like. It's not that they were lazy, it's that they didn't understand how code is built. Dijkstra taught computer science. That is what he was up against. At the time, all programming languages used goto almost exclusively for flow control. In some ways, it is the simplest way to do it. One construct did the job of the multitudes we use today: for, while, until and even recursion. However if you didn't follow some simple rules the goto's invariably ended up as spaghetti and the end result ended up being there was far more spaghetti in production than structured code. The two simple rules are: 1. backward goto's were only for loops, and 2. you must not goto inside an inner basic block. These are exact same rules for and while loops with {} blocks enforce. But it takes some self discipline to apply those rules, and no one is going to do it if they don't understand why they are important. Such understanding requires good high level intuition about how code is structured. It took a long while to teach such intuition. If you got rid of the goto's by replacing them with higher level constructs like for and while, you not only got rid of the problem - you also forced young students to think in terms of code flow. That is what Dijkstra was arguing for in "Goto's considered harmful". Today, times have changed. You very rarely see a badly structured goto in the Linux kernel code, even though C allows it. I'm not sure why that is - because I'm pretty sure if Dijkstra hadn't won out and Javascript and it's ilk still had goto's then shudder. The coding standards in web programming is a cluster fuck as it is: I swear there isn't a week go by when I don't come up against a broken web page. Just this week I was forced to fire up the browsers js debugger to change a field on a linkedin.com form, and manually do "$0.value = 'yes'" to move on. ffs. But yes, in projects with coding standards as high as the Linux kernels, everybody that (is allowed to?) contribute seems to have a very good understanding of how to make code that others find easy to read and understand, a ban on gotos would be counterproductive. Despite the discipline they require, gotos can be used to make the code cleaner and shorter. You see numerous examples of that in the kernel.

moffkalast 5y ago

Yeah to those still adamant about it, if you've ever used a: - function call - if sentence - any kind of loop You've used a GOTO under the hood. I hope you can live with yourself, you monster :)

brundolf 5y ago
But there's a reason we come up with sanctioned, constrained concepts built atop more powerful lower-level ones. Constraints in code benefit maintainability, correctness, and sometimes even performance. "Yeah to those still adamant about it, if you've ever used statically-typed code, you've used untyped assembly under the hood. I hope you can live with yourself, you monster :)"
agent327 5y ago
You put a smiley so I suppose it's possible you know better, but this kind of shallow, thoughtless critique is just painful to read, especially when following such a well-presented, historically accurate description of the debate surrounding goto. This is especially true given that Dijkstra himself refutes your argument, such as it is, in the opening paragraph of his seminal paper.
GrumpyYoungMan 5y ago
What's even worse is that, at the machine language level, condition and unconditional jumps are all that there are; we've all been using GOTOs constantly without even knowing it. :)
1-more 5y ago
a case statement is the one where the GOTO peeks out the most, imo.
andi999 5y ago
The real hidden gotos are: - state machines - early return of a function
masklinn 5y ago
> You've used a GOTO under the hood. That it's under the hood is the point of using constrained control-flow control. It's significantly easier to reason about `if` and `while` and `for` than about `goto`. That is basically the same reason functional programming have more HoFs than `fold`. You can do everything with `fold` and that's a problem because it creates way more cognitive overhead for the reader, they can't know what the code is trying to achieve until they get all the details, nor is the compiler able to check anything. Likewise goto.

CJefferson 5y ago

I agree with you completely. I once made a poster (I wish I'd kept it) where I was tracing out the behaviour of a single mega function with around 50 labels in it, and gotos all over the place. I worked on a reimplementation, slowly picking apart the function into subfunctions, while loops, recursive function calls, etc. Took me about 2 weeks.

munificent 5y ago
That must have been so satisfying once it was done.
prox 5y ago
You maybe the right person to ask… Aren’t function / functioncallers a form of goto?
- CJefferson 5y ago
  Technically yes, all code eventually compiles to goto, or goto equivalents (simplifying slightly) However, the idea behind "goto considered harmful" is almost all code can be written with function, loops and if/else statements and get just as efficient, and much, much easier to understand.
  - kazinator 5y ago
    All goto code can be mechanically translated into a network of mutually tail-calling functions arranged into an identically shaped call graph that is hardly easier to understand. What you can do with goto-based code is refactor it into a form that obeys certain conventions such that it is easy to mechanically translate to such a tail-call newtork, but then stop short of actually doing it. Then when reading the code, just pretend you're looking at function calls.
kazinator 5y ago
I could refactor a self-contained 50 label goto graph into a network of tail recursing functions pretty quickly; as little as an hour, in the absence of nasty confounding factors. If the goto graph implements a calculation with no side effects like I/O, my network will be all pure functions, too. Completely beyond the reproach of any CS academic. :) There is a mechanical way to do this. 1. We turn all of the function's local variables into function arguments. Each of our tail recursive functions will take these arguments. 2. Every labeled node becomes a function. 3. Every goto becomes a function call invoking the function that its target label was turned into, passing in each of its own argument to the corresponding parameter of that function. The function's return value is immediately returned. 4. Every variable assignment before a goto is turned into an argument expression in the function call which passes the new value to the corresponding argument. E.g. instead a++; d *= 2; goto foo; we have return foo(a + 1, b, c, d * 2, e, ...); Once you have this working, then you refactor. For instance, if you have a function like this: int foo(int a, int b, int c, ..., int z) { return a + c; } which does not pass its arguments to another tail-called function, then you can eliminate all of the arguments and just turn it into: int foo(int a, int c) { return a + c; } and of course edit all of the calls to foo accordingly, and simplify those places also. In this way, you will "discover" simpler functions that work with just a subset of the state transfer.

blntechie 5y ago

My first job was writing VB.NET code and it was hammered to us not to use GOTO. Once for a critical production bug, using GOTO was the quickest solution to fix and I used it with a comment to not fire me. And that code lived on for years.

ehutch79 5y ago
Sometimes a little bit of poison can make a great medicine. Goes both ways though.

0xffff2 5y ago

Can you give an example of where you've used goto in C or a C-like language? Or a rough estimate of the number of times you've found goto to be the best solution? I agree with your post in principle, but in practice I can't think of a single example where I've used a goto that wasn't eventually refactored to something better that didn't have the goto. Edit: Probably the most common example (and one given early in the article) is deeply nested loops. This is a good example of where I'm very unlikely to use goto. Almost certainly, I will prefer to hide one or more of the inner loops inside of a function call.

mumblemumble 5y ago
What's wrong with the examples in the article?
codr7 5y ago
https://github.com/codr7/ampl/blob/main/src/ampl/eval.cpp https://github.com/codr7/ampl/blob/main/src/ampl/eval.cpp
- InfiniteRand 5y ago
  I'm sure there's probably a reason for doing things this way, but it seems like that code would make more sense as a function pointer table and a series of functions. Was that not preferred for aesthetic reasons or for some specific technical reason?
  - codr7 5y ago
    Speed. Your suggestion adds indirect memory access plus function call, for every instruction. I've tried every other way I can think of, and nothing runs faster from my experience.
- slaymaker1907 5y ago
  Replying to infiniterand, a table of function pointers is going to generally have way more overhead than an indirect goto. An indirect goto is essentially a single assembly jump instruction. This is also often faster than a while loop plus switch since it is friendlier to the branch predictor.

westcort 5y ago

What I want is a language that consists ONLY of GOTO statements. The Turing tape concept indicates that it should be possible.

schoen 5y ago
Subtract and branch if negative is more or less that: https://en.wikipedia.org/wiki/One-instruction_set_computer#Subtract_and_branch_if_negative https://en.wikipedia.org/wiki/One-instruction_set_computer#S...

GrumpyYoungMan 5y ago

> "The issue I think is that people today read "GOTO Considered Harmful" without really understanding the world at the time. ... Just because it was a bad idea to do everything with a GOTO 60 years ago shouldn't mean don't do some things with goto today." Every time this comes up, I always encourage people to read an excellent analysis by David Tribble "Go To Statement Considered Harmful: A Retrospective" that goes over Dijkstra's essay line by line and explains what it means in a more modern context: http://david.tribble.com/text/goto.html http://david.tribble.com/text/goto.html It really should be required reading in CS programs. I've used and still use goto in the few niches it makes sense to, primarily error handling and multi-level break in C/C++.

wglb 5y ago
This is a good balanced article. What is often missing from these goto discussions is the dialog between Knuth and Dijkstra on this topic. There is another discussion between the two of them about a problem requiring no less than four stacks to understand.
User23 5y ago
> "Dijkstra later abandoned the search for program provability and turned instead to the study of techniques for correct program derivation" It's odd how even today very few people in the "formal verification" world understand this distinction. Naturally verifying a derived program is trivial, since it's literally a proof by construction. I've attempted many times to explain this distinction, and they inevitably just start babbling about the limitations of the tooling they use. A sad case of man with a hammer syndrome and probably an illustration of my own failure to achieve clarity I guess. > "However, to some extent Dijkstra's principle has not been fully realized when we observe the complexity that must be dealt with by real-world programming tasks, such as multitasking, multithreading, interrupt handling" Dijkstra designed the first proven correct interrupt handler for a multitasking OS two years before the Goto Letter[1][2] so I think we can rest assured that he was aware of these issues. [1] https://en.wikipedia.org/wiki/THE_multiprogramming_system https://en.wikipedia.org/wiki/THE_multiprogramming_system [2] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/EWD196.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/E...

CodeMage 5y ago

This is my pet peeve with how they teach kids programming. Granted, I only have anecdata on that topic, gleaned from how they teach my own kid at school, but I still can't shake the feeling that we're doing them a disservice by making them skip straight to JavaScript or Python. I wonder what it would be like if kids started with BASIC. And not Visual Basic or any other modern, structured flavor. No, I mean the ancient stuff: 10 PRINT "All your base are belong to us!" 20 GOTO 10 Limited in what it can do, simple to learn, with just enough fun stuff in it (like PLOT, DRAW, INKEY$, INPUT, etc.) Then go on to assembly language, again on some very limited and simple machine, along the lines of the good old ZX Spectrum 48 or Commodore 64. Then move on to something like C or Pascal. Or even Python and JavaScript if you want. But the idea is that going through BASIC and assembly, they'll learn two important things: 1) how computers actually work (even though it's super-simplified, it should still be useful), and 2) why you need structured programming. Or maybe I'm just being naive. I really would like to see if that works out, though.

gsinclair 5y ago
I teach high school CS and have eventually come to the same insight, and found that novice programmers do indeed understand primitive BASIC much more easily than Python. Python seems simple to us, but there is so much abstraction even in its base-level syntax. I am gradually redeveloping my course materials to use BASIC (via replit.com) in the early stages.

1vuio0pswjnm7 5y ago

SNOBOL, the non-numerical computing counterpart to FORTRAN, also uses GOTOs, exclusively. I still run spitbol. Regardless of its assembly-like control flow, I think the pattern matching beats PCRE, and Lua's implementation of LPeg.

ouid 5y ago

I thought the problem with unstructured goto is that it is extremely hard to reason formally about code that uses it.