isbn9789526046266

The third reason was pragmatic: the CS1 for non-majors in which we were to try out our approach is
a course in imperative Python programming that covers some basics of object-orientation near the end.
15.2.2 Concrete tracing is a natural choice
A mater-studiorum from Section 5.5. Programmers use two kinds of mental tracing strategies. Concrete
tracing uses actual values, while symbolic tracing uses generic symbols (e.g., the value assigned to x,
the return value of foo()). Symbolic tracing is lighter on working memory and is typical of the way
people prefer to run mental models ‘qualitatively’. Concrete tracing is needed in challenging situations,
and novices need it often.
UUhistle’s notional machine uses actual values to provide a form of concrete visualization, for several
fairly obvious reasons. First, the computer uses concrete values when running Python programs. Second,
novices need to learn concrete simulation to deal with difficult and common situations such as unfamiliar
and buggy programs. Third, the external representation that is the visualization compensates for the
failings of working memory.
Are there downsides to using concrete values? One might be that it leaves symbolic tracing untaught.
However, it may be that people move quite effortlessly from the concrete to the qualitative/symbolic
running of mental models when they have a solid enough understanding of the concepts involved, so
perhaps symbolic tracing is not a skill that needs separate teaching.
15.2.3 There is not an unmanageable amount of detail
The developers of the Jeliot program visualization system specifically wished to show novices details
about program execution that seem self-evident to experts (Ben-Bassat Levy et al., 2003). This serves
an obvious purpose. However, when the level of abstraction is fixed, as in Jeliot, there is a very real risk
that controlling the viewing of a detailed animation may turn into an endless ‘click-a-thon’ that merely
bores students and distracts them from the meaning of the visualization. An occasional criticism of the
Jeliot system is that the user has to view everything in detail without being able to focus on the aspect
of execution that they are most interested in (Moreno and Joy, 2007). 2
UUhistle is also all about exposing certain details of execution to novices and has a similar fixed level
of abstraction to Jeliot, so the risk of excessive detail is there. Moreover, when UUhistle is used for visual
program simulation rather than animating programs, the danger is even more ominous, as learners have
to work to get past each execution step.
Excessive detail can be fought by learners themselves, by teachers, and by the system designer directly.
The learner vs. excessive detail
One way to fight excessive detail is by empowering the learner. Just like a debugger, UUhistle in program
animation mode allows the user to have a program run until a specified line of code and set breakpoints
(Chapter 13). The user can also choose to execute code one line at a time, reducing the number of
interactions needed to get to an interesting point in the program run.
The teacher vs. excessive detail
A visual program simulation exercise does not allow the user to skip freely to an arbitrary stage of
execution. Wherever the user has to manually simulate the program’s execution in UUhistle, he does so
at the lowest level of granularity. However, with careful VPS exercise design, the teacher can allow the
user to skip past boilerplate code and other unnecessary detail (Chapter 13). The teacher can configure
exercises so that some code is executed automatically before the VPS task starts (either by making it
‘hidden’ or by defining a preset breakpoint); there are also many ways of fine-tuning simulation/animation
hybrids.
2 The newest version of Jeliot supports a “Run until line” command that somewhat alleviates this problem if students find
and use it.
231