2006/5/19, Mike Nelson <miken700 / yahoo.com>:

> Back then, with the goto problem, we found that we were writing a bunch
> of messy and goto was the central construct that abused. So we decided
> that it was better to use the function construct in most cases in order
> to help this problem. But in our retreat of messy code we seemed to
> place our fear of it wholly into the goto construct itself. My guess is
> that this allows us to say that we can ignore a lot of that fear now as
> long as we don't use goto statements, which is sort of ignoring the
> central problem of messy code.

I see this differently: experience has shown that GOTO in most cases
leads to bad code. It's also formally proven that it's not needed,
i.e. the same semantic can be achieved without it (but using if -
else, loop constructs etc.).  Since these other constructs of course
*can* also be abused (like every feature a programming language
offers) but usually give better code remove the GOTO.  And that's what
they did.

> Because of all this, it now seems that we are left with a weird
> superstition around the goto construct. Which is pretty odd to me
> because it's still a fundamental construct used on the CPU, so why not
> use it in the code when it helps?

Because it leads to bad code too often to outweight the occasional benefits.

Cheers

robert

-- 
Have a look: http://www.flickr.com/photos/fussel-foto/