From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: GOTOs
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Thu, 3 Sep 1992 05:51:40 GMT

In article <15232@umd5.umd.edu> malmberg@umsa8.umd.edu (Norwin Malmberg) writes:
>IQTI400@INDYCMS.IUPUI.EDU (macphil) writes:
>
>[snip]
>>There are scenarios where a GOTO is a timesaver in the short-haul and
>>even more where it's an immediate convenience.  There are very few
>>situations where they are absolutely, positively necessary.  The
>>ability to distinguish these situations is fairly rare when it comes
>>to the off-the-shelf, run-of-the-mill programmer/analyst simply
>>because most are not *good* programmers writing high-quality code.
>
>>I'm betting 99+% of COBOL programs used by the average business for
>>doing nothing more than running various sort/summary/total reports
>>would be significantly improved by allowing businesses to purchase
>>a COBOL compiler which flagged "GOTO" as a syntax error.  Similar
>>arguments could be made for many other languages in their native
>>habitats.  Only when you get to extremely complex situations could
>>you start attempting to make serious efforts against this argument.
>
>>I'm not a COBOL-bigot, I'm just pointing this out as one of the
>>most-abused languages which can be highly procedural and fairly
>>easy to read when used properly.
>
>OK, I'll admit it - I used to program in COBOL.
>
>I have seen all too many COBOL programs where the person had been told
>"You should never use a GOTO".  In general, these programs contain
>strange switches to handle control flow, force you to flip pages all
>over the place when trying to trace how they work (since every little
>thing is handled by a separate paragraph, usually not on the same page),
>and generally are a pain to trace.  They also have a tendancy to exhibit
>strange bugs because of all those switches.
>
>In particular, there is the "read records from a file and process them
>until there are no more records".  Doing this without a GOTO usually
>looks like this:
>
>MOVE "NO" TO NO-MORE-RECORDS.
>PERFORM READ-AND-PROCESS UNTIL NO-MORE-RECORDS = "YES".
>
>READ-AND-PROCESS.
>  READ IN-FILE AT END
>    MOVE "YES" TO NO-MORE-RECORDS.
>  IF NO-MORE-RECORDS NOT = "YES"
>    PERFORM PROCESS-RECORD.
>
>Rather clumsy.  By comparison, it looks fairly clean using a GOTO:
>
>READ-RECORD.
>   READ IN-FILE AT END
>     GO TO NEXT-ROUTINE.
>   [Process record]
>        .
>        .
>        .
>   GO TO READ-RECORD.
>NEXT-ROUTINE.
>    etc.
>
>In general, GOTOs can be used in COBOL in a clean manner, producing more
>readable code than not using them.  I will admit that it is possible to
>write spaghetti using GOTOs, but avoiding GOTOs at all costs often ends
>up with even more confusing code.

Yes, there are even people advocating structured COBOL :-(.

The same crap all over again.  Instead of a nice simple clean efficient
routine, you have clumsy confusing inefficient code, which you can mindlessly
read in small sections, because someone decided that's "better" :-(.

COBOL has traditionally been known as a language which is somewhat clunky
to get anything done in, but the binary generated for what it does state
well is excellent and likely compares to good assembler for a slightly
contrived set of cases.  (But leave it to the structurites to ruin a good
thing :-(.)

cjl

Newsgroups: alt.folklore.computers