> Linus Torvalds <torvalds@transmeta.com> writes:
>
> > Actually, I suspect that what made goto's impopular among some computer
> > scientists was not the code itself, but the bad compilers of the day. They
> > just blamed it on "spagetti code". But take it from me: it's a damn lot
> > easier to create bad code by overusing "good" features like exceptions and
> > overloading than it is by using "goto".
>
> It's a lot easier to write a good optimizing compiler for languages
> that disallow goto. Just open the Dragon Book and compare the complexity
> of the algorithms that work on reductible graphs (that are the programs
> with no goto) with the ones that work on arbitary graphs.
The dragon book is what, 20 years old now? It's a good book, no doubt
about it, but it is still aimed at a rather simple compiler setup.
The fact is that any good compiler has to be able to handle goto-like
behaviour anyway these days. You can make a _simple_ compiler without it,
but you can't make a good compiler.
To make a language really simple to optimize, you also have to disallow
"break" and "continue": any loops must have only one exit point (defined
by the language), and you must have only one point of return from
subroutines.
Which is pretty much what Pascal does.
But don't kid yourself that Pascal does this for any altrusitic reasons
like "goto is bad for you". Pascal just gives you a straightjacket that
makes it easier for the compiler, but it makes it harder for the
programmer. And anybody who seriously thinks that having just one return
point is a _good_ language feature needs a brain transplant.
Straightjackets are for crazy people. "It's for your own best", indeed..
Linus