Re: "Goto statement considered superfluous" (was: If you were inventing C)

Response interleaved:

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9HPwxJ1uflB@jpberlin-l.willms.jpberlin.de...
> CS> That doesn't mean the techniques could reasonably be applied before
> CS> they were invented.  I don't think GO TO in  COBOL is inherently evil
> CS> any more than the branch instructions on the 1401 were.
>
>    What is evil is not the existens of GOTO in COBOL, but that the
> lack of proper repetition statements did push programmers to program
> COBOL as if it were assembler. And many of those never learned to
> think in program structure, but only step-by-step walk throughs.
>
>    GOTO is superfluous for a "High Level Language".

I guess my take on the earlier topic is more like "What in COBOL can now be
seen as a mistake *at the time it was developed*?".

At the time COBOL was developed, GO wasn't superfluous enough in Fortran or
Basic or ALGOL or any of the other higher-level languages around at the time
to warrant its omission from the language.   The "go-to-less" language with
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 do most of my programming work in the language of a database
> development system, which doesn't have a GOTO. You might also check
> with your colleagues of the OS/1100 side for @SSG or Skeleton, which
> can do wonderful things like WFL and which doesn't know a GOTO.

I have no doubt whatever that it's possible to write programs without GO TO
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 have
interfered with its acceptance.

>    Sure, the hardware will know nothing else but jumps, but a 'High
> Level Language' should provide some abstraction from that hardware
> level and provide proper statements for repetition. These came to
> COBOL only with the 1985 standard.

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 COBOL
in 1960 should have followed the precepts Dijkstra published in 1968 or that
it was a mistake for Grace Hopper to have failed to do so.

> When COBOL could organize repetition of PERFORMed _procedures_ with
> VARYING a control variable, UNTIL a loop exit condition, n TIMES, I
> don't see any reason why the same should not have been possible with a
> local sequence of statements.

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 not
necessarily mean that the logic associated with the avoidance of GO is more
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 mean
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

On 23-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> 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 don't think it would.   It already was significantly different from other
languages of the time.   We would have used the tool as given to us.

I also don't think that removing ADD, SUBTRACT, MULTIPLY, and DIVIDE would h
ave
hurt it.   We learned to use those verbs because they were part of the tool.