Re: No Go To's Forever!

[Richard D Riehle <laoXhai@ix.netcom.com>]

In article <38D7B41D.B3494C6A@lmco.com>,
	Bill Dale <william.dale.jr@lmco.com> wrote:

>Never use a GOTO - ever. At all. Anywhere. Period.
>
>OK, I'll put you down as not interested in working for me.  

When Dijkstra wrote his letter to the Communications of the ACM
in 1968, "Goto Considered Harmful," lots of people read the 
title but not the letter.  COBOL and Fortran code was mangled
by programmers under the management of people who made up rules
based on the title of the article.  Early languages were not
well-designed to intelligently avoid occasional use of a "jump"
or "goto."  The early adoption of this admonition may have caused
as much damage as good in those early programs.

Later languages, starting with Pascal (some might argue for PL/I
or some other language), introduced well-formed structures with
improved scoping rules.  This eliminated many situations that might
have required a "goto."  It did not eliminate all of them.  I recall
a program where we were able to more effectively meet a deadline
by modifying one little piece of code with a "goto".  It was the
correct decision at the time.  There was no equvilaent of a 
pragma Inline for the language in use and we could not tolerate
the overhead of heavy access to a subprogram call.  We would solve
the problem differently today.

In my humble opinion, we should not design with the goto.  However,
it is sometimes an important mechanism when all other options have
been exhausted.  I have seen some excellent programs that have used
the goto, including some very recent Ada code.  In one example, the
programmer used it to emulate the "continue" statement one finds in 
some other programming languages.  I recall a posting a long time 
ago where Dr. Dewar presented an example of an FSM that lent itself
to design with a goto.

I remember someone once saying that "people who make up rules about
programming tend to be people who no longer write real programs." 
That may be an extreme point-of-view, but it is a point-of-view 
from the trenches and programming managers need to know what the
people who are laying down source code think of such doctrinaire
approaches to software development.  

Richard Riehle
richard@adaworks.com