isbn9789526046266

A reasonable description of this for loop is: “First, the variable – i in this case – is set to zero. Then
the loop iterates over all the values of i from 0 to 9 and prints them out.” A novice programmer may
form a mental model of this program that matches this description and is viable when it comes to dealing
with this specific program, but is not robust. For instance, some of the students in Vainio’s study had
developed an understanding according to which whichever variable is used within the body of a for loop
is always set to zero at the start of the loop. Such an understanding is clearly not generally viable.
A problem with an understanding such as the above is that the student has formed a component
model of the for statement (within their model of the program) that does not meet the principles set out
by de Kleer and Brown. The understanding violates the no-function-in-structure principle, as it mixes up
the definition of a for statement (its structure) with what the for statement is used for in a particular
context (its function, which here includes assigning zero to a variable). A related violation is that of the
locality principle. The component model of the for construct is not independent of the specifics of other
constructs; it is dependent on the idea that somewhere within the body of the loop there is at least one
other statement that makes use of a variable that affects what the for statement does.
Vainio and Sajaniemi (2007) describe violations of the no-function-in-structure principle as common,
attributing this in part to the tendency in CS1 courses to associate each type of problem with only a single
kind of programming construct, and each programming construct with a single kind of problem. Their
work emphasizes the need for novices to separate what a construct is and what it is typically used for.
To summarize this section, tracing a program requires the ability to mentally simulate programs running
in a notional machine. Novices especially need concrete tracing at a low level of abstraction to make
sense of programs, but often lack the ability or even the inclination to trace programs. Ideally, mental
simulations are based on robust, generalizable mental models of programs, and rely on abstraction and
external status representations if and when the limits of working memory are met.
5.6 Where is the big problem – misconceptions, schemas, tracing, or
the notional machine?
Let us reflect on what this and the previous chapters have told us about learning to program. My review
of learning programming has so far centered around five challenges that face the novice programmer.
1. Creating programs imposes a great cognitive load on novice programmers.
2. Programmers need plan schemas which represent generic solutions to common problems, but novices
have few.
3. Novice programmers have misconceptions about basic programming concepts, which give them
trouble when reading and writing programs.
4. Many creative and unexpected programming tasks require mental tracing of programs, something
that novices are not always capable of.
5. Novices need to form a viable mental model of a notional machine to be able to understand program
execution.
Some pertinent and difficult questions are as follows: Which of these challenges are the most important?
Is there a particular bottleneck for learning? How do the challenges depend on each other?
Different researchers have given different answers to these questions.
A legion of misconceptions
Research on misconceptions has a long history which demonstrates that non-viable understandings of
programming concepts have been considered an important and pedagogically fertile area of computing
education research by numerous authors. Clancy enthuses:
68