gotos

[Stephen J. Friedl]

In article <2200 at louie.udel.EDU>, new at udel.EDU (Darren New) writes:
>
> [responding to the "give me something hard to translate" challenge]
>
> How about: (pseudocode)
>    for (i = 0; i < max_in_table && key != name[i]; ++i) 
>       if (keypressed()) goto handle_key;
>    seek(helpfile, offset[i]);
>    if (keypressed()) goto handle_key;
>
>	[more code with output and "keypressed" here.  Presumably
>	this lets redisplay stop and process the next command and
>	possibly avoiding wasted output.  Emacs and WordStar do
>	this, among others]
> 
> I contend that if the reading and formatting and displaying are sufficiently
> slow, such behaviour can be desirable (i.e., on microcomputers).
> I would like to see a goto-less version of this that is easier to understand.

Let's put this goto business in perspective:

	/*
 	 * strcpy() - written by John Doe
	 */
	strcpy(dst, src)
	char	dst[], src[];
	{
	int	i;

		for (i = 0; dst[i] = src[i]; i++)
			;
	}

     Who objects to this?

     Even a beginnermediate C programmer is likely to rewrite
this function using pointers, but it is unlikely that a
passionate hatred of [arrays] (or of John Doe) will develop as
well.  In this case, the use of arrays indicates lack of
experience or insight, not of evil intent or laziness.

       ***********************************************
       * The problem is not with arrays but with the *
       * underlying thought that caused their use.   *
       *                                             *
       * The solution is not to ban the array but to *
       * teach the insight.                          *
       ***********************************************

     And so it goes with our bedeviled goto.  In the quoted text
above, goto probably indicates a lack of experience with really
neat methods of preemptive redisplay.   Gosling Emacs does this
by checking for keypressed() *one place* very deeply in the
display handler rather than sprinkle these calls everywhere; Sys
V Rel 3 curses does it like this too.  I have oversimplified
it here, but it is extremely elegant and beautiful to behold.
Those attempting mere transliteration of the above fragment
are condemned to failure even if no gotos are used -- the failure
just won't be as "obvious".

       ***********************************************
       * The problem is not with the goto but with   *
       * the underlying thought that caused its use. *
       *                                             *
       * The solution is not to ban the goto but to  *
       * teach the insight.                          *
       ***********************************************

     The array example is a trivial one but (I believe) valid.
When you are learning C you will naturally stumble over the
syntax and semantics of the language, but it is part of learning.
In my opinion, *excessive* use of arrays tells me that the user
needs to get more comfortable with pointers, but I betcha this
person does not believe that they are doing anything "wrong".
Perhaps they are not: the program works, doesn't it?

     Once you've learned C you still have a long way to go.
There are many, many more levels of insight beyond just learning
syntax -- learning to speak Spanish won't make you a great
speaker in Mexico City.  The goto shows lack of insight on a much
higher level, and it is a lot harder to convince people that they
are missing that insight.  Showering users of gotos with $50 fines
and ridicule is hardly conducive to inspired thinking.

     The solution to this goto problem is not to be found by
banning the goto but by better fundamental understandings.
Focusing on language syntax is largely a wasted effort that
distracts from the real issues.

    C'mon guys/gals, let's replace:

 	"you show me a fragment with gotos and I can rewrite
 	it without them" (said with challenging tone)

with

 	"You show me what you want to accomplish, and I'll
 	suggest some alternate ideas" (said with helpful tone).

     If you use gotos a lot, ask a wizard for suggestions and try
to gain something beyond solving the problem at hand.  If you are
a wizard, share your experience as others undoubtedly did with
you.  Most of us really enjoy the fun of computers and want to be
the best we can be.  Let's help each other out.


     I've crossposted this to comp.software-eng in the hope
that some of the net.readers over there might have something
to offer from a software engineering viewpoint rather than a
language syntax viewpoint.  Anyone?

-- 
Steve Friedl       V-Systems, Inc.      Resident access(2) basher
friedl at vsi.com   {backbones}!vsi.com!friedl    attmail!vsi!friedl