on goto
in [General Programming]
|
From: James Kanze on 2 May 2010 18:42 On May 2, 5:57 pm, Seebs <usenet-nos...(a)seebs.net> wrote: > On 2010-05-02, James Kanze <james.ka...(a)gmail.com> wrote: > > > It sounds to me almost the opposite. He's not really advocating > > a programming paradigm, as condemning one which definitely makes > > the code more difficult to understand. > > Except he hasn't established that the other paradigm *definitely* makes > the code more difficult to understand. > > And empirically, when someone converted a program using the condemned > paradigm, which everyone understood at first read, to one using his > preferred paradigm, several experienced programmers tripped over it, > because the resulting program was harder to understand. It's easier to > understand a simple rule with an exception than to understand a complicated > rule. > > -s > -- > Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...(a)seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: James Kanze on 2 May 2010 18:42 On May 2, 5:57 pm, Seebs <usenet-nos...(a)seebs.net> wrote: > On 2010-05-02, James Kanze <james.ka...(a)gmail.com> wrote: > > It sounds to me almost the opposite. He's not really advocating > > a programming paradigm, as condemning one which definitely makes > > the code more difficult to understand. > Except he hasn't established that the other paradigm > *definitely* makes the code more difficult to understand. No. The only thing that's been conclusively proven is that the SESE idiom never makes the code more difficult to understand. If the loops (and the functions that contain them) are reasonably short, the difference between the two should be minimal. -- James Kanze
From: Kai-Uwe Bux on 2 May 2010 18:54 James Kanze wrote: > On May 2, 5:57 pm, Seebs <usenet-nos...(a)seebs.net> wrote: >> On 2010-05-02, James Kanze <james.ka...(a)gmail.com> wrote: > >> > It sounds to me almost the opposite. He's not really advocating >> > a programming paradigm, as condemning one which definitely makes >> > the code more difficult to understand. > >> Except he hasn't established that the other paradigm >> *definitely* makes the code more difficult to understand. > > No. The only thing that's been conclusively proven is that the > SESE idiom never makes the code more difficult to understand. [...] Just curious: could you provide a reference, where I can read up on that proof? I vaguely remember a theorem to the effect that there is a family of programs such that rewriting them into SESE either makes the code size grow exponentially or degrades efficiency of execution by a logarithmic factor; but I would have to look that up for a precise statement. Anyway, that does not directly contradict your statement above; but it would be interesting to compare the two theorems. Best Kai-Uwe Bux
From: Seebs on 2 May 2010 18:59 On 2010-05-02, James Kanze <james.kanze(a)gmail.com> wrote: > On May 2, 5:57 pm, Seebs <usenet-nos...(a)seebs.net> wrote: >> Except he hasn't established that the other paradigm >> *definitely* makes the code more difficult to understand. > No. The only thing that's been conclusively proven is that the > SESE idiom never makes the code more difficult to understand. That has not been proven. And, in fact, in the recent example, we saw conclusively that the SESE version was misunderstood by more than one reader, while the other version was not misunderstood by anyone. Demonstrably, SESE *can* make code more difficult to understand. > If the loops (and the functions that contain them) are > reasonably short, the difference between the two should be > minimal. Again, empiricism wins; empirically, the SESE version of the scan of a three-dimensional array was less understandable, in that more than one person, reading it, misunderstood what its effects would be. There is no way you can go from "people misunderstand B, but not A" to "conclusively proven that B is not more difficult to understand". -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Ben Bacarisse on 2 May 2010 19:13
James Kanze <james.kanze(a)gmail.com> writes: > On May 2, 1:37 pm, Ben Bacarisse <ben.use...(a)bsb.me.uk> wrote: >> James Kanze <james.ka...(a)gmail.com> writes: >> > On May 2, 9:07 am, Juha Nieminen <nos...(a)thanks.invalid> wrote: >> <snip> > >> I think you may be using the wrong term here. For me, a loop >> invariant is a condition that is quite separate from the >> loop's controlling condition. > > Yes and no. As you correctly point out, there can be loop > invariants which aren't expressed by the controlling condition, > and they play an important role in evaluating the correctness of > the loop. It does, however, facilitate comprehension of the > loop if one of the invariants is that the loops termination > conditions haven't been met. That's not what most people call a loop invariant. The term refers to any predicate[1] that is always true at the point at which the loop condition is evaluated -- even when that condition is false. You seem to be extending the term in a way that will confuse someone trying to understand invariants. A predicate that expresses that fact that the loop's termination conditions haven't been met can't be an invariant in the sense the term is usually used. [1] The trick of course is picking a useful one. That's why people often talk about "the invariant" because there is often a minimal one that clearly helps to establish the correctness of the loop. -- Ben. |