4 ms·

I guess some people are afraid to use a gun for fear that they might shoot their foot—or that someone else will. I think goto’s are useful.

by nusaru 5y ago

rightbyte 5y ago
There is a dogmatic contempt for goto:s. Like people who use them are stupid or something and obviously doing it wrong. I think the underlying reason is that it is annoying to write tree walking interpreters and implement goto:s. (How do you even do that?). So the prominent CS folks at the time just dismissed goto:s instead by bullying user to submission.
- scambier 5y ago
  The contempt is justified. `goto`s break the flow and make the code harder to read and reason about, and thus make it easier to introduce bugs. It's an instruction that's almost never _needed_ today, because there is always a better structure to use instead. I only use it in Lua, to compensate for a lack of `continue` in loops.
  - cyberpunk 5y ago
    cybrpnk:~/src/linux$ grep -rniE 'goto\W+.*;' . | grep -E '\.[c|h]:' | wc -l 182044 Sure.. I mean.. 'almost'
    - dan-robertson 5y ago
      It’s worth noting: 1. One need for goto in C is for what is done with labelled loops in other languages. So one might expect uses there 2. Another use is for cleanup after errors which would be automatically handled by the compiler (via destructors) in most more modern non-gc languages. It looks like: int do_thing(args…){ foo *x; bar *y; baz *z; int err; if((err = make_foo(&x, …)) < 0) goto exit3; if((err = make_bar(&y, …)) < 0) goto exit2; if((err = make_baz(&z, …)) < 0) goto exit1; frob(foo, bar, baz); err = 0; /* maybe use x,y,z and return instead of cleanup */ free_baz(z); exit1: free_bar(y); exit2: free_foo(x); exit3: return err; } So really all you’re proving is that C does not provide sufficiently useful structured programming tools to avoid goto. Java handles this fine for memory but not so nicely for objects that have more involved cleanup that shouldn’t be delayed (e.g. open files, removing from some parent object, etc). Indeed Java also doesn’t provide great tools for protecting cleanup code from stack unwindings, or at least they aren’t sufficiently ergonomic that you see them used everywhere. It certainly isn’t the case that Linux is full of old-school do-whatever-you-like uses of goto.
  - _0ffh 5y ago
    Meh, that's just the kind of dealing in absolutes that gets on some peoples' nerves. I agree that in almost all situations gotos are probably not the best choice, but there are still situations where gotos are a reasonable option, arguably even the best that's available.
- Jtsummers 5y ago
  That's a very ahistorical take. The primary reason to move away from go to statements was around reasonability. Structured programming introduced semantically meaningful control structures which replaced the vast majority of the uses of go to statements. Go to statements, themselves, don't carry the same meaning with them (is it part of a loop, a conditional, a subroutine call, a return from a subroutine, moving to an error handler?), go to statements also permit spaghetti code which is somewhere between hard and impossible to express in most languages using structured programming control structures.
  - rightbyte 5y ago
    Ye sure I agree. Structured programming was a rational displacement of goto:s. I think it took Fortran like 20 years before it got proper loop constructs and you could essentially write to the instruction register with assigned goto, like Fortran was some Macro Assembler. But the contempt goes further than "goto vs subroutine calls" or "goto vs the if-else construct". With "underlying reason" I meant more like "underlying reason for the contempt of all use of goto". Even when goto makes the code less spaghetti and more readable. Knuth did a good write up on the matter: https://pic.plover.com/knuth-GOTO.pdf https://pic.plover.com/knuth-GOTO.pdf
    - Jtsummers 5y ago
      What you initially wrote, and what I was replying to: > I think the underlying reason is that it is annoying to write tree walking interpreters and implement goto:s I don't believe that there is any historical justification for this view. And your updated statement is even less historically sound. Everything written about go to statements (as a negative, something to partially or fully eliminate) seems to have been predicated on reasonability and comprehensibility of the code by people, not the ability to write tree walking interpreters. Which is a minor activity when reviewing the totality of all computer programming activities of the past 70 or so years.

I guess some people are afraid to use a gun for fear that they might shoot their foot—or that someone else will. I think goto’s are useful.

by nusaru 5y ago

I guess some people are afraid to use a gun for fear that they might shoot their foot—or that someone else will. I think goto’s are useful.

rightbyte 5y ago

There is a dogmatic contempt for goto:s. Like people who use them are stupid or something and obviously doing it wrong. I think the underlying reason is that it is annoying to write tree walking interpreters and implement goto:s. (How do you even do that?). So the prominent CS folks at the time just dismissed goto:s instead by bullying user to submission.

scambier 5y ago
The contempt is justified. `goto`s break the flow and make the code harder to read and reason about, and thus make it easier to introduce bugs. It's an instruction that's almost never _needed_ today, because there is always a better structure to use instead. I only use it in Lua, to compensate for a lack of `continue` in loops.
- cyberpunk 5y ago
  cybrpnk:~/src/linux$ grep -rniE 'goto\W+.*;' . | grep -E '\.[c|h]:' | wc -l 182044 Sure.. I mean.. 'almost'
  - dan-robertson 5y ago
    It’s worth noting: 1. One need for goto in C is for what is done with labelled loops in other languages. So one might expect uses there 2. Another use is for cleanup after errors which would be automatically handled by the compiler (via destructors) in most more modern non-gc languages. It looks like: int do_thing(args…){ foo *x; bar *y; baz *z; int err; if((err = make_foo(&x, …)) < 0) goto exit3; if((err = make_bar(&y, …)) < 0) goto exit2; if((err = make_baz(&z, …)) < 0) goto exit1; frob(foo, bar, baz); err = 0; /* maybe use x,y,z and return instead of cleanup */ free_baz(z); exit1: free_bar(y); exit2: free_foo(x); exit3: return err; } So really all you’re proving is that C does not provide sufficiently useful structured programming tools to avoid goto. Java handles this fine for memory but not so nicely for objects that have more involved cleanup that shouldn’t be delayed (e.g. open files, removing from some parent object, etc). Indeed Java also doesn’t provide great tools for protecting cleanup code from stack unwindings, or at least they aren’t sufficiently ergonomic that you see them used everywhere. It certainly isn’t the case that Linux is full of old-school do-whatever-you-like uses of goto.
- _0ffh 5y ago
  Meh, that's just the kind of dealing in absolutes that gets on some peoples' nerves. I agree that in almost all situations gotos are probably not the best choice, but there are still situations where gotos are a reasonable option, arguably even the best that's available.
Jtsummers 5y ago
That's a very ahistorical take. The primary reason to move away from go to statements was around reasonability. Structured programming introduced semantically meaningful control structures which replaced the vast majority of the uses of go to statements. Go to statements, themselves, don't carry the same meaning with them (is it part of a loop, a conditional, a subroutine call, a return from a subroutine, moving to an error handler?), go to statements also permit spaghetti code which is somewhere between hard and impossible to express in most languages using structured programming control structures.
- rightbyte 5y ago
  Ye sure I agree. Structured programming was a rational displacement of goto:s. I think it took Fortran like 20 years before it got proper loop constructs and you could essentially write to the instruction register with assigned goto, like Fortran was some Macro Assembler. But the contempt goes further than "goto vs subroutine calls" or "goto vs the if-else construct". With "underlying reason" I meant more like "underlying reason for the contempt of all use of goto". Even when goto makes the code less spaghetti and more readable. Knuth did a good write up on the matter: https://pic.plover.com/knuth-GOTO.pdf https://pic.plover.com/knuth-GOTO.pdf
  - Jtsummers 5y ago
    What you initially wrote, and what I was replying to: > I think the underlying reason is that it is annoying to write tree walking interpreters and implement goto:s I don't believe that there is any historical justification for this view. And your updated statement is even less historically sound. Everything written about go to statements (as a negative, something to partially or fully eliminate) seems to have been predicated on reasonability and comprehensibility of the code by people, not the ability to write tree walking interpreters. Which is a minor activity when reviewing the totality of all computer programming activities of the past 70 or so years.