ResetStateEachProgramExecution

Correction

Here is what's right.

Running a scratch program (pressing the green flag button) will start executing the program from whatever state the world is in right then. The values of variables and the state of the sprites will not implicitly get reset by starting the program.

Assume the following script:

If the user executes this script, the sprite moves forward 100 steps from its current position, increases its size by 10 from its current size, and increments the score variable by 1 from its current value.

Note that running the program will not reset the state of the sprites or the values of variables. The world will start in whatever state it is when the flag button was clicked. Thus, the start state of the world depends on previous runs of the program and on direct manipulations by the user.

If starting a program is supposed to start from a well-defined state, the scripts need to explicitly set that state (set variables as well as the position/heading/… of sprites to specific values).

Origin

Where could this misconception come from?

The cause of this misconception might lie in a belief that a given block of the script will always have the exact same effect.

Symptoms

How do you know your students might have this misconception?

Empirical Evidence

This misconception appears in Item P9 in the Scratch ProMAT assessment:

Question

Here you see a program with a loop.

At the beginning, the cat is facing right. When we run the program once, the cat faces left. Where will the cat be facing if we run the entire program twice?

Answers

The answers are displayed as the cat sprite facing the four cardinal directions:

Value

How can you build on this misconception?

The fact that for most programming languages each program execution starts from a blank slate could be seen as just a consequence of equating program executions with operating system processes. In most programming languages, each time we execute a program we create an entirely new process (with completely cleared out memory), which means there is no available prior program state.

A student with this misconception might simply not be familiar with this prevalent but somewhat arcane approach to implementing systems. In fact, modern application frameworks provide means to persist and restore the state of an application across executions (e.g., when restarting a web browser, the new process will open all the previously open tabs, to provide the user with a smooth experience).

This misconception could occur not just in Scratch, but also in other programming languages like Smalltalk, Pharo, or Self, and, more generally, in “live programming” environments, where the program state persists beyond the developer-triggered execution of code.