LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (June 1999, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Fri, 11 Jun 1999 12:31:17 -0400
Reply-To:     "Paul M. Dorfman" <sashole@EARTHLINK.NET>
Sender:       "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From:         "Paul M. Dorfman" <sashole@EARTHLINK.NET>
Organization: KINPH
Subject:      Re: Programming Theory Question.
Comments: To: Richard DeVenezia <radevenz@ix.netcom.com>, sas-l@listserv.uga.edu
Content-Type: text/plain; charset=koi8-r

Rich,

It could not have been said better. Cracking down on GOTOs to prevent 'unstructured' programming has the same nature as eliminating guns: It shifts the culpability from one who misuses a tool onto the tool itself.

Many spears have been broken over this one. We can discuss it here forever without revealing any new truths. Anti-GOTO hysteria has been around for years spearheaded by COBOL 'shops standard legislators' trained in 'structured programming'. For curiosity sake, I have surveyed two dozen or so COBOL guys asking just one question: What IS structured programming? NOBODY had a clear idea, the most common notion having been 'programming without GOTOs'.

GOTOless mindset is just a dogma, a form of religion based solely on faith. In his response to the original question, Paul Thompson's wrote:

"There is always a better way than a GOTO. HEre is some FLAMEBAIT: THERE IS NEVER A NEED FOR A GOTO. NEVER."

This is expressed in the form of a mathematical theorem. Any mathematical theorem (in particular, expressed in terms of ALWAYS and NEVER) is considered disproved if a single counterexample can be found. In this case, there are many. One of the worst myths about GOTOs is that anything written using them can be rewritten without ones leaving efficiency intact. Those who think it is true might want to read through Donald E. Knuth's brilliant article 'Structured Programming With GO TO Statements' published as part of the book 'Literate Programming'. If, after reading the paper, any questions regarding GOTO usage remain unclear, it means it was not read carefully enough.

Fortunately, in THIS group the author need not be introduced. Amongst the surveyed guys I mentioned above, only two had ever heard of Donald Knuth, yet 90 percent of them prided themselves as ultimate authority in programming theory, practice, and especially in structured programming.

Kind regards, ==================== Paul M. Dorfman Jacksonville, FL ====================

Richard DeVenezia wrote: > > >Can someone explain why a GOTO statement is classified as bad programming? > > > > I can't, because I don't think it is. Moderate use of all available > language syntax is sensible. Badly constructed do loops can be just as hard > to understand as poorly structured GOTO code. I would rather be handed > commented GOTO laden code than uncommented structured syntax code. > > It's been a long time since I looked at code as 'theorem' that has to be > deduced as true or false. In this computer science mindset, gotos make the > deducing harder. > > In SAS macro, which lacks a %RETURN, %GOTO is a necessity for exiting a > macro when certain requirement criteria are not met (i.e., this macro > variable must be one of these values). Personally, I hate code that has > ump-teen nested IF's because someone didn't want to use a goto to bypass > some logic. > > Rich


Back to: Top of message | Previous page | Main SAS-L page