Re: "Goto statement considered superfluous"

I would like to remind people that not only did 60' COBOL have GO TO, it
had ALTER.  They were a pair in many cases.

Warren


Chuck Stevens wrote:
> Response interleaved:
>
> "Lueko Willms" <l.willms@jpberlin.de> wrote in message
> news:9HPwxJ1uflB@jpberlin-l.willms.jpberlin.de...
> 
>
>
> I guess my take on the earlier topic is more like "What in COBOL can now b
e
> seen as a mistake *at the time it was developed*?".
>
> At the time COBOL was developed, GO wasn't superfluous enough in Fortran o
r
> Basic or ALGOL or any of the other higher-level languages around at the ti
me
> to warrant its omission from the language.   The "go-to-less" language wit
h
> which I am most familiar (and the one I'd argue is probably most in
> compliance with Dijkstra's philosophy) had only one loop-control construct
:
> DO FOREVER, with a corresponding "IF <condition> UNDO", and it dates from
> the early 1970's.
>
> 
>
>
> I have no doubt whatever that it's possible to write programs without GO T
O
> whether the language has the construct or not.  I've done so in both cases
,
> in fact.  But I think the *absence* of GO TO in the COBOL of 1960 would ha
ve
> interfered with its acceptance.
>
> 
>
>
> I agree, and I also think their proliferation is a Good Thing.  I would
> encourage people to use them as a matter of style; I don't agree that COBO
L
> in 1960 should have followed the precepts Dijkstra published in 1968 or th
at
> it was a mistake for Grace Hopper to have failed to do so.
>
> 
>
>
> So the bottom line is "in-line PERFORM" should have been available earlier
> than '85.  I don't have a problem with that.  ALGOL had its equivalent a
> quarter-century before that.  But ALGOL had, and still has, GO as well.
>
> Many, many times I have rewritten procedures in the ALGOL-dialect products
 I
> work on for the sole purpose of getting rid of GO statements.  That does n
ot
> necessarily mean that the logic associated with the avoidance of GO is mor
e
> efficient at execution time.  It does mean (at least to me) that if there'
s
> any extra (in this case compile-time) cost to our users associated with
> logic alternative to GO and intra-procedure labels, that cost is worth
> incurring in the interests of improved maintainability.  There are a few
> cases in which it is really impractical to avoid it.  All this doesn't mea
n
> I think ALGOL should have been designed without a GO statement from the
> beginning; as for COBOL, I believe the absence of such a construct would
> have interfered with the language's acceptance.
>
>     -Chuck Stevens
>
>