| Warren Simmons 2004-09-28, 3:55 pm |
| 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 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 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.
>
>
>
>
> 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.
>
>
>
>
> 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
>
>
|