From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: doylep@ecf.toronto.edu (Patrick Doyle) Subject: Re: Why C++ is successful Date: 1998/08/16 Message-ID: #1/1 X-Deja-AN: 381761135 X-Nntp-Posting-Host: skule.ecf Sender: news@ecf.toronto.edu (News Administrator) References: Organization: University of Toronto, Engineering Computing Facility Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-08-16T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: > >First the hint is simply because, although the algorithmic flow of the >original is completely clear, Er, that is still under debate... :-) >it is my experience that when people >contort to remove the gotos, they often end up with a non-equivalent >algorithm. That says nothing about the clarity of the original, merely >the difficulty of removing the goto. Ok, I'll agree with that. On the other hand, I find my own code clearer if I just don't put the gotos in there in the first place. >The above code is correct, but for my taste not clearer. I don't like >having a loop which at the outside looks like a perfectly normal >J from 1 .. N - 1 loop, but is not. Ironically, that's exactly why I prefer my version. Yours is based on a for-loop. If that does not suggest a once-through pass over each element of the list, I don't know what does. On the other hand, mine is essentially a while-loop, which (to me) always suggests that the pattern of iteration is more complex than a for-loop, or else it should have been coded as one. (Incidentally, there is no for-loop in Eiffel, so everything must be coded as a while loop, but that is beside the point.) >Here the unusual structure of this loop is buried in an inner assignment, >rather than being evident at the top level in my presentation with a goto. Your goto was not at the top level. The label was. A label suggests only that the indicated statement is the target of a jump. It makes no suggestion as to where this jump comes from; and to me, it certainly doesn't suggest that a for-loop is no longer a for-loop. >But certainly people differ in tastes and perhaps some will prefer the >above, but please prefer it because it is clearer to you, NOT, as is the >case for so many programmers, simply because the goto is eliminated. Agreed. Please take all my above comments as personal opinion only. >There is nothing inherently unclear about a goto, that's the important >thing. On the contrary, the semantics of a goto, intepreted in the normal >operational manner at which most programmers interpret semantics, is >about as simple as it could be. Yes, of course it is possible to abuse >the goto and write disgusting code, but the same can be said about >any feature in any language. The clarity of the goto statement is one of a number of examples of paradoxical situations where the properties of a language feature on a small scale are the opposite of its properties on a large scale. For example, a class declaration appears, on a small scale, to add verbosity and complexity to code; but for large-scale software construction, it has a powerful simplifying and clarifying effect. Likewise, while the goto is extremely simple on a micro-level, in large-scale software it has precisely the opposite effect. In other words, it is easy to understand what the goto statement does, but it's hard to understand what a large piece of code based on gotos does. But, as you say, this is just my (and Dijkstra's :-) opinion. -PD -- -- Patrick Doyle doylep@ecf.toronto.edu