C ognitively A pprop riate Progam m ing L anguage C onstructs

In the above we have tried to lay out some of the knowledge and processing strategies th at novices and experts employ. However, for the most part, these sorts of observations have not been used in the design of programming languages. This is unfortunate, since a unnecssary barrier to learning has been erected if a language construct is “not matched’’ with the cognitive strategy th at underlies it. In what follows we will identify one such language construct — Pascal’s while loop

— in which there is a clear mismatch between how people prefer to solve problems and how the language construct forces them to solve problems. The upshot, which is not surprising, is th at people’s performance using this construct is unacceptably poor. (An expanded version of this work appears in [15].)

Consider then, the problem and its program solution given in Figure 8A. Notice that the problem is neither esoteric nor tricky; certainly one would expect novice programmers to be able to write a correct solution to this problem. However, we have found that performance on this problem is generally quite poor; in one study where we asked students to write a program, at their desks, for this problem, we found only 40% could write correct programs.5 We have argued that a major stumbling block is the unusual model of looping required by Pascal’s while construct.

Stepping back from the code, the strategy that this program embodies can be characterised as:

Read ( f i r s t v a l u e ) W HILE T e s t ( i * t f t v a l u e )

DO BEG IN

P r o c e s s ( i ’ t h v a l u e ) R e ad ( I ♦ I s t v a l u e ) END

Since the loop may not be executed if the First value read is 99999, a Read outside the loop is necessary in order to get the loop started. However, this results in the loop processing being one step behind the Read; on the ith pass through the loop, the ith value is processed and then the ith + 1 value is read in. We call this strategy “process i/read next-i” (henceforth referred to as PROCESS/r e a d). In effect, processing in the loop would be “out of sync” with reading in the

^Because we see that bugs of this sort often “fall through the cracks”, PROUST, our program that finds non- syntactic bugs in novice programs, has been explicitly designed to provide comments to the student on just such bugs

1

1

-®We did not count off for incorrect syntax.

loop.

In contrast, consider the program displayed in Figure 8B th at solves the Averaging Problem using a variant of Ada’s l o o p . . . e x i t construct. The strategy underlying the use of the

loop. . . l e a v e . , .aga i n construct can be abstracted as follows:

LOOP DO B EG IN

R e ad ( i ’ t h va lu e )

I F T e s t ( i ’ t h v a l u e ) LEAVE P r o c e s s ( i ' t h va lu e ) A G A IN

That is, on the ith pass through the loop read the ith value and process it; we call this the “read i/process i” strategy (henceforth referred to as READ/PROCESS). We argue th a t the difficulty of this strategy arises from the extra burden that it places on memory and processing resources, in comparison to th at placed by a READ/PROCESS strategy.

In a study reported in [15] we tested the following hypothesis:

People will write correct program» more often when the language facilitate» their preferred strategy.

Subjects were novice, intermediate and advanced programmers. In the first part of the study, we asked subjects to write a plan — not a program — to solve the Averaging Problem. We found th at when programmers were not constrained by a particular programming language they overwhelmingly used a READ/PROCESS strategy in their plans. In the second part of the study, half the subjects were asked to write the program using standard Pascal, the language th at they already knew; the other half were asked to write the same program using Pascal-L, which is Pascal with only the l oop. . . I ea ve . .. aga i n construct. Both groups were given a one page description describing how the language’s looping construct worked. We found th at programmers using the l oop. .. l ea v e. . .again construct wrote correct programs significantly more often than those using the while construct — the increase in performance was approximately 20%. Note th at the programmers had never seen or used the loop. . . I ea v e . . .aga i n construct before, whereas they had been using the wh i I e construct for up to 5 semesters.

Strong claims have been made against a construct th at permits an exit from the middle of the loop; it is argued th a t one should exit a loop from the top or the bottom, not the middle (18, 4, 8].

It is further claimed th a t the readability of a program is hampered if exits from the middle of the loop are allowed. Our study did not examine the readability claim, since we looked only at program generation. However, a series of studies by Sheppard et al. (12) suggest th at in fact a construct that permits an exit in the middle does not interfere with readability. Thus, there appears to be empirical evidence that an exit from the middle of the loop is not as harmful as was

T \t Averaging Problem: Write * program that repeatedly read« in integers, until it reads the integer 09099. After

conjectured. Finally, we hope that this sort of study indicates how one might proceed to analyze the relationship between language constructs and cognitive strategies.