🚀 go-pugleaf

James Giles wrote:
> 
> In 1968, Edsger Dijkstra wrote a letter to the _Communications_
> _of_the_ACM_ titled "Go To Statement Considered Harmful".  This
> paper has since been widely reprinted.  In 1974, Donald Knuth
> wrote a paper for _Computing_Surveys_ titled "Structured
> Programming with GOTO Statements".  This paper has also been
> widely reprinted.  These were not the first nor the only papers
> written on this subject, but to my mind, they should have been
> the last needed.  Anyone who argues this issue should first
> be required to prove he (or she) has read both these papers.
> Anyone who hasn't read these papers should be ignored out
> of hand.
> 
> That being said, I'll go ahead and add my $0.02 to the mix.
> 
> I actually use GOTOs all the time.  Except for the "hello world"
> program, my programs tend to have thousands of GOTO's.  For example,
> an IF without a ELSE clause has one conditional GOTO, with an ELSE
> there's both a conditional and an unconditional branch.  A WHILE
> loop has both conditional and unconditional branches too.
> 
> Now this is both trivially obvious and rather silly.  But it still
> raises the question of why CASE, IF(ELSE), WHILE(FOR, etc.), and
> procedure calls are the only branches anointed as "structured".
> It wasn't always so.  Though these were the constructs mentioned in
> Dijkstra's letter on the subject, there was no suggestion that these
> were the *ONLY* appropriate constructs.

< .... many lines deleted .... >

> Well, there's a lot more to talk about GOTOs (like exception handling!),
> but this is enough for one article.  The bottom line is that automatic
> rejection of GOTOs for religious reasons loses sight of the real issues
> which led to the controversy and often can lead to unfair disregard for
> techniques which are perfectly sound.  New kinds of GOTOs slowly reach
> into the "structured" pantheon, but only very slowly (and perhaps correctly
> so).  Complete elimination of GOTOs from available languages would stop
> this useful evolution entirely.  In any case, people should not be so quick
> to condemn *all* GOTOs out of hand.  As Dijkstra himself pointed out:
> 
>       Please don't fall into the trap of believing that I am terribly
>       dogmatical about it.  I have a feeling that others are making a
>       religion out of it, as if the conceptual problems of programming
>       could be solved by a single trick, by a simple form of coding
>       discipline!
>                                       - E.W. Dijkstra

In the APL world it has often been seen as an inferior style of using
GOTO or even LOOPS at all.

In most instances they are not needed. I might add that in ALL cases
you could avoid GOTOs and LOOPs if you really put your mind to it.

In the most advanced of languages, J , there were no GOTOs or LOOPs in 
the beginning. They have been introduced in the most recent versions
of J and are now a well appreciated part of J.

In the most recent versions of J there are now several Control 
Structures. Not needed according to the purist but I personally
find them easy to use and saves me the hassle of being too clever
all the time.

You have:

if. ... do. ... end.
if. ... do. ... else. end.
if. ... do. ... elseif. ... do. ... elseif. .. .. .. end.
try. ... catch. ... end.
while. ... do. ... end.
whilst. ... do. ... end.

there are even more conventional Control Words:

break.
continue.
goto_name.
label_name.
return.

Using these kind of structures can simplify the job of initial 
solving a problem of program flow while you are solving a new kind
of challenge.

Once you have the system solved I find I can usually go into the
system and remove the control structures.

One which is quite handy is the 
try. ... catch. ... end.
But only until you have the system under control then it is actually 
worse. In the catch part you have to be clever to report the error
that occurred. Unless you do not care about the error and always want
to do certain action if the try part does not work and given correct
situation it should.


-- 
/Gosi
bjornhp@simi.is Bjorn Helgason Spitalastig 4 101 Reykjavik Iceland 354 
562 5441
http://www.jsoftware.com