I think,

In this discussion about 'goto' we are forgetting one important fact
about it. This is, the fact that 'goto' is simply a jump and a
corresponding lable. This makes 'goto' jumps possible at any point in
code which is absolutely not necessary. Evolving from simple 'goto'
and lable statements, got rid of many situations where goto would
have made code difficult to conceptualise as composed of modules. The
idea behind goto is not absolutely technical but a consequence of how
our minds work. Goto was replaced by functions, break, continue and
exit: the reason is that way the human mind can more efficiently
organize and visualise code parts according to its local purpose. I
think, we should not forget that our brains are essentially pattern
recognizing "neural computers": goto breaks recognition of those
patterns rendering code a mess of unrelated bits, hence the term,
spaghetti code.

Edward

On 25/06/2016, Steve Litt <slitt@???> wrote:
> On Sat, 25 Jun 2016 01:21:33 +0200
> Irrwahn <irrwahn@???> wrote:
>
>> For the
>> interested, David Tribble's "Go To Statement Considered
>> Harmful: A Retrospective"[4] makes for a good read.
>>
>>
>> [1] NB: "break" and "continue" are just "goto" in disguise.
>>

>> [2] For example in the notorious case of releasing resources
>>     in reverse order of allocation in the event of an error.

>>

>> [3] Lame attempt at translating a witticism once made by a
>>     German politician.

>>
>> [4] http://david.tribble.com/text/goto.html
>
> Ugh!
>
> I knew to be skeptical when the author, in the 3rd paragraph, called
> the evilness of goto a "myth". Agenda alert!
>
> First of all, we all need to get on the same page as to what we're
> talking about. By my definitions, "break" and "continue" and for that
> matter exit(1) or exit 1 and exceptions are in no way gotos in disguise.
> They're program counter alterations that break modularity (which goto
> does too), but break it in a very predictable and reasonably unharmful
> way. Real goto statements, with labels you can put anywhere, are
> extremely prone to utter destruction of modularity. I know: I started
> programming with gotos, because I started designing with flowcharts.
>
> With a flowchart based design, flow control ricochets around like a
> laser pen in a house of mirrors. If you like systemd, you'll love
> flowchart based design. And of course, the way to implement flowchart
> based design in code is with gotos. The Flowchart fellows of the
> 1960s/70's were clever: In many cases too clever for their own good.
> They were clever enough to make it, but not to debug it. And because
> the functional decomposition design method that I replaced flowcharts
> with was much more productive, they lost out in the marketplace to more
> productive programmers.
>
> If you want to see my opinion on gotos and flowcharts, and how I came
> upon this opinion, go to
> http://www.troubleshooters.com/lpm/200310/200310.htm, search for
> "Whomping Out the Code", and read the next two paragraphs. If one uses
> gotos, one must be VERY careful. It's called spaghetti programming for
> a reason.
>
> Then there's the old excuse "well, you might need to escape a deeply
> nested loop. No problem, encapsulate the outer loop from which you want
> to escape in a function, and use the return statement wherever you want
> to bust out of the nested loop. If some cleanup needs to be done
> before the loop-bust, call the cleanup as another function. Or if you
> want to bust out of the whole program, use exit() or an exception. Just
> don't use a goto with a label. Because someday some well meaning but
> dumb maintenance programmer will put code between the end of the
> outer loop and the label, and then all hell will break loose.
>
> If you look at the article's annotated Dijkstra essay, Dijkstra
> repeatedly says "goto statement", not just "goto" as a concept. He
> wasn't talking about break, nor continue, nor return, nor an exception.
> Break, continue, return, exit() and exceptions perform a jump without a
> corresponding "return from subroutine", which is unmodular and
> unstructured, but they jump to places specified by their placement in
> the program, not specified by some label the programmer can place
> absolutely anywhere.
>
> I'm not kidding: My programming ability improved by over an order of
> magnitude when I stopped using goto statements with moveable labels,
> and in my opinion anyone wanting to use a goto with a moveable label
> should explain in detail why he can't achieve the same result with
> structures such as break, continue, return, exit(), an exception, or
> the real structured solution: Loops with flags that can be turned
> false, and if statements such that nothing from the current loop is
> executed after the flag is turned false.
>
> SteveT
>
> Steve Litt
> June 2016 featured book: Troubleshooting: Why Bother?
> http://www.troubleshooters.com/twb
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>