
If Go To statements are bad then why ... - externalreality
... are there countless abstractions and programming language mechanisms that bounce you around the text in ways that Go TO could have never dreamed of. I rarely spend time thinking about stuff like this but sometimes, just sometimes, the question just begs to be asked (again).
======
coldtea
> _... are there countless abstractions and programming language mechanisms
> that bounce you around the text in ways that Go TO could have never dreamed
> of._

Like? What are those abstractions and mechanisms?

Well written programs can (and do) make use of no such mechanisms, in any
case. Where have you seen those? Any particular example that moves the flow
the way Goto does?

Exceptions come to mind, and people always point out that its bad to abuse
exceptions for control flow (e.g. using them like a kind of goto).

The problem with goto (which is not considered a problem when used in local
scope, e.g. for cleanup code within a function) is that it moves the flow of
execution away and makes it difficult to track.

A function (or e.g. a continuation in Node) doesn't have that problem: you
return back to where you started.

------
davismwfl
Flow of control is what is critical in every application, and goto's allow you
to break flow of control easily. That said, a lot of very stable systems used
goto's for very specific instances. For example, they would use it to short
circuit the if/else/if/else for error handling, cleanup etc. But it was a goto
within a single scope, e.g. within a single function. Of course, with that
power comes the ability to cut off an important appendage, and in reality the
"need" for a goto is really not a need, it is a lazy implementation detail.

Usually what I found is people feeling the need to use goto often just didn't
understand how to design or layout the system they were working on, or try to
put to many unrelated code segments into a function. As other comments
mention, the flow of control changing scope etc cause lead to all kinds of
difficult debugging, memory leaks, crashes etc. So not generally a good idea.
Smarter to use proper function scoping, return behavior and error codes.

One of my early tasks as a C programmer, back in the early 90's, was taking a
C program that had like only 4-5 functions (with thousands of lines of code)
in it, and tons of goto's and cleaning it up to be a maintainable system.
Engineers all hated that system because it ran fairly stable (somehow), but
touching a single line of code could mean days of debugging. Starting over was
easiest but took forever to get the functionality correct because of all the
jumps to weird places that were not obvious behaviors. That was an
unforgettable lesson for me.

------
ktpsns
Jumping between addresses is the way how assembler programs/machine code
works. A high level language shall abstract, bringing powerful concepts like
scopes. If you short-circuit the high level logic by directly using gotos, you
will shoot into your foot. Furthermore, the pladoyer "goto considered harmful"
was about using high level program structures for the sake of their power.
Letting the compiler alone to do the hard work of managing your variables,
etc.

------
zimpenfish
I once failed/bailed from a C course because I refused to remove a `goto` and
the instructor refused to allow my code to be submitted. Even though it was
demonstrably the right thing to do, he was adamant that it was better to have
a cascade of `if` blocks with guard variables that made it way more complex
and difficult to follow.

