Xref: utzoo comp.lang.c:9535 comp.software-eng:481 Path: utzoo!mnetor!uunet!vsi!friedl From: friedl@vsi.UUCP (Stephen J. Friedl) Newsgroups: comp.lang.c,comp.software-eng Subject: Re: gotos Message-ID: <587@vsi.UUCP> Date: 22 Apr 88 02:40:24 GMT References: <1988Apr8.183815.3187@utzoo.uucp> <449@goofy.megatest.UUCP> <2200@louie.udel.EDU> Organization: V-Systems, Inc. -- Santa Ana, CA Lines: 114 Summary: Let's put this in perspective (long, sorry) In article <2200@louie.udel.EDU>, new@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@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl