http://qs321.pair.com?node_id=130046


in reply to Would you use 'goto' here?

For those who are interested, here is a link to one of the reasons behind the cargo cult notion of no gotos. This of course is “Go To Statement Considered Harmful”, E. Dijkstra's famous letter to the editor of Communications of the ACM, Vol. 9, No. 5 (May 1966), pp. 366-71. Like the basis of many such things, it doesn't quite say what many think—and in any event, should be read by anyone who programs or even pretends to program!

Another article that should be read in this context is found here. Actually the link is to a .pdf file created from scanner input. But still legible for all of that. This paper, “Structured Programming with go to Statements”, is by Donald Knuth, published in Current Trends in Programming Methodology, Vol. 1, Raymond T. Yeh, ed., New York, NY., 1977. In it Knuth details a history of the go to discussion and then follows with his position and rationale.

This pair make a good start, but only a start. If you want more before you come to an informed opinion, try Classics in Software Engineering Editied by Edward Nash Yourdon, New York, NY., Yourdon Press, 1979. While sadly out of print, this shows up from time to time at Powell's Technical in Portland. Try http://www.powells.com/technicalbooks

–hsm

p.s. Do I use gotos? Of course I do, I'm an assembler hack—can't get there from here without them!

Replies are listed 'Best First'.
Re (tilly) 2: Would you use 'goto' here?
by tilly (Archbishop) on Dec 07, 2001 at 22:36 UTC
    Thank you for the link to Knuth's paper.

    I have read about it before, but not read it. As normally happens, there are insights in the original that are forgotten later. One of the best ones so far for me is the note on p277 which points to a proof by Rao Kosaraju that implies that the normal structured programming constructs, with loop control, with named loops is sufficient to replace any algorithm using gotos with an equivalent one without goto which does no extra computation. (The key point being no extra computation.) I find this an interesting theoretical validation of the point that loop control and named loops in Perl is sufficient to replace the vast majority of reasonable gotos in other languages.

    And if you go on to p282 you will find the following quote:

    Certain go to statements which arise in connection with well-understood transformations are acceptable, provided that the program documentation explains what the transformation was.
    The example that he demonstrated this with was taking an obvious recursive algorithm, recognizing tail-recursion, and rewriting it for efficiency. This involved introducing gotos. In my note to Ovid above I used the examples of implementing a finite state machine, and TheDamian's Switch.

    And then there are the comments which are fascinating in hindsight. For instance the one on p295 about how a given level of abstraction often defines several related routines and data definitions. His example is how the representation of a table is tied to the routines you need for storing to and fetching from it. His assertion that the next generation of languages will probably take into account such related routines seems to me to be an excellent anticipation of OO programming...

    And his closing note about the future seems to be an excellent description of the present. Higher level languages like Perl often contain goto, but people just don't see the need to use it, and so the issue faces away. However, as he said, it remains true that if you let beginners know about goto and leave them with the opinion that it is OK to use the feature, they will discover many cases where they "need" goto, but the cause of the need is poor planning on their part, and they would be better off hitting the roadblock, backing off, and then rethinking rather than working their way forward into more trouble by adding gotos...

[reply]

In Section Seekers of Perl Wisdom