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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: rgardner@nyx.net (Ray Gardner) Subject: Re: Software landmines (loops) Date: 1998/09/07 Message-ID: <905134925.147581@iris.nyx.net> X-Deja-AN: 388556793 X-Disclaimer: Nyx is a Free Public Access Internet Service: http://www.nyx.net Nyx is not responsible for the actions of its users. Our AUP / Free Speech Policy are at http://www.nyx.net/policies/ Direct complaints to abuse@nyx.net References: <6r9f8h$jtm$1@nnrp1.dejanews.com> <6renh8$ga7$1@nnrp1.dejanews.com> <6rf59b$2ud$1@nnrp1.dejanews.com> <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <35f51e53.48044143@ <904556531.666222@miso.it.uq.edu.au> <6sgror$je8$3@news.indigo.ie> <6sh3qn$9p2$1@hirame.wwa.com> <35ece7ee.1489912@news.erols.com> X-Post-Path: iris.nyx.net!rgardner@nyx10.nyx.net Organization: random access Reply-To: rgardner@acm.org NNTP-Posting-Date: Sun, 06 Sep 1998 20:22:05 MDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Originator: rgardner@nyx10.nyx.net (Raymond Gardner) Date: 1998-09-07T00:00:00+00:00 List-Id: Matthew Heaney wrote: > rgardner@nyx.net (Ray Gardner) writes: > > > RCM had responded with a direct quote from Dijkstra, but Ell But the > > original idea, as expounded by Dijkstra, Mills, Wirth, Ledgard, and > > others does indeed restrict you to single- entry/single-exit control > > structures, and they don't exit loops in the middle. > > Oh! You were doing well up to that last line. Read about the > dowhiledo structure, in section 3.3.3, Iteration Structures, of > Structured Programming, by Linger, Mills, and Witt. > > A list of prime programs also appears on p115, and the one at the bottom > is a dowhiledo loop. He explicates the meaning of that loop structure > on p116-7. Thanks for the correction, Matt. Of course my main point was that the founder(s) of SP did limit the control structures to single-entry / single-exit structures, and that still stands. The middle-exit loop (with single exit) is still such a structure whether Dijkstra used it or not. (He didn't). I realize this subthread about what SP is or isn't started with your post supporting a middle-exit loop and citing the Soloway et al. study from CACM 11/83. I was mainly replying to Ell's disbelief that SP concerns se/se structures only. The Soloway study was interesting. RCM asked you about the study so I assume he doesn't have it ready at hand, so I'll answer a couple of his questions about it. The study was a based on a trivial programming assignment given to students. 116 were novices in their first Pascal class, 112 were "intermediates" in their second programming class, and 52 were "advanced" (juniors and seniors in systems programming and programming methodology classes). The assigment was to write a Pascal program to read a list of numbers terminated with a sentinel value of 99999 and compute the average (excluding the sentinel value). Programs were considered correct even if they didn't check against division by 0 (i.e. only a sentinel value was read), so a correct program could be written about 15 or 16 lines of code. Syntax errors were ignored. Half the subjects had to use standard Pascal (but without goto apparently) and the others used a modified Pascal (Pascal-L) with a loop...leave...again structure in lieu of all other loop constructs. Before writing any code (and before being told about the modified Pascal) all subjects were asked to write a "plan" in any language other than a programming language. The plans were studied to see if they "naturally" specified a "process/read" strategy or a "read/process" strategy. Most, including advanced, wrote a "read/process" approach, though a third of the advanced chose "process/read" (I'd guess because they expected to write in a Pascal style), and about 2/3 of the novices had plans too vague to be classified. Here, process/read means the loop processes data before reading the next data item, meaning there is a "priming" read before entering the loop. This is seen as appropriate for straight Pascal. read/process means the loop reads, tests for sentinel, and then processes the data. Straight Pascal needs to use flags, duplicate conditions, etc. to get the correct behavior, but read/process is considered appropriate for Pascal-L because it can be done with no duplication of the read statement. Interestingly, the few novices who chose process/read with straight Pascal all got the program right, none of the read/process novices did. Of the novices who chose read/process for Pascal-L (all but 1), only about half got it right. In the intermediate group on straight Pascal, 18 chose process/read and 16 of those got it right, while 21 chose read/process and only 3 got it right. On Pascal-L, 43 chose read/process and 34 were correct, while 7 tried process/read but only 2 got it right. The advanced Pascal group showed 16 out of 18 correct with process/read, with only 5 trying read/process and only 2 of those getting it right. With Pascal-L, 23 out of 24 choosing read/process were correct, as were the only 2 who used process/read. Soloway et al. conclude from these numbers that the mid-exit loop strategy leads to more correct results. I'm no statistician, but I'm not entirely convinced. The first paragraph of the paper suggests they were really interested in making programming easier for non-programmers. It's true that more subjects got it right in each category with Pascal-L than with straight Pascal. But I also note that more advanced subjects were more likely to choose the "appropriate" strategy for the language. I figure they'd learned (in class or on their own) about the "priming read" approach, which is key to getting it right without a mid-exit loop structure. I wonder how much better all the Pascal groups would have done if they'd been properly instructed on this. (I assume they weren't, or more of the novices and intermediates would have chosen the process/read approach for Pascal.) What's really appalling is how many students got this simple thing wrong. The novices were 3/4 through their first programming course and "had been taught about and had experience with the while loop and the other two looping constructs"; the intermediates were 2/3 through their second course. I'm not sure if this says more about the students or the school, though I'd guess many of the novices and intermediates included those lacked the aptitude for the work and later quit programming. The article mentions another "series of studies by Sheppard et al." regarding the readability effects of mid-exit loops on professional programmers. It's in Computer, Dec. 1979. Unfortunately I only joined IEEE-CS in 1984, so I don't have that one at hand. Perhaps someone in these newsgroups who does have it can summarize? It might be more interesting than the Soloway article.