While working on the definition of notional machines at Dagstuhl, we realized that there might be different forms of notional machines! Just to streamline my own thinking, I am describing four different forms here. This post is not meant to be complete! Let me reiterate that our current understanding of a notional machine is:
“A notional machines is a didactical tool that helps a learner understand the workings of the source code on an actual machine” (slightly evolved from the definition in my previous post)
Different forms of notional machines each come with their own benefits and downsides (or as Sally Fincher called them: affordances) and some people (learners or teachers) might naturally lean to one form more than to another. And, some programming languages might more naturally fit one type of notional machine. More on that at the end of this post!
Metaphors
The first type of notional machine is a metaphor. People that know me might know that this is my default one. I love explaining using metaphors and we have done some work on the box metaphor for variables. A metaphor is a notional machine because it helps a learner understand how a part of the machine works. For example, through the box metaphor a learner learns how a variable works because it helps them see that a value remains ‘in’ a variable until something happens, and that it can be inspected over and over without changing the values.
Benefits are that the box is very tangible, but it might induce the misconception that a variable holds multiple values. In one of the breakout sessions, Sally mentioned that the box metaphor might not be precise enough to talk about affordances, and that we would need more precise descriptions. We coined the idea of ‘Felienne’s box’ which is a more specific box, in which values are stored on postit notes that stack upon each other so only the final value is inspectable. See me explain this in a video (Dutch).
Another metaphor we talked about were Brian Dorn’s dance moves as metaphor for procedures. A dance teacher will not say “cross your feet, keep your heels on the ground, and bend your knees and straighten them again” but will simply say ‘do a plie’. That is easier and quicker. Similarly we can repeat a piece of code by giving it a name and then calling it. This metaphor has as benefits that is can be adapted to the target audience and that almost any culture has some form of dance (the floss or ballet or hiphop or country dancing). Downsides are that is only covers procedures but does not extend to functions since it cannot represent return values in a logical way.
I think I buy into the idea that these are notional machines since they really support learners to make sense of the machine even though they are limited. We talkes bout how these are not notional machines for the full language but for a subset, which will also be true for some of the other forms.
Representation
The best example of a representation might be PythonTutor by Phillip Guo. Here is a screenshot:
This visualization is dynamic, i.e. it is generated life by the system for the student to look at, but of course a representation could also be something that a student draws by hand. Benefits of this representation (and representations in general) is are that they can be a truthful representation of what the machine does, they allow for fewer things to be lost in translation than a metaphor. However, as you can see in the image above also a representation can potentially create a high cognitive load on a learner since there is a lot going on in the image, so reading it can be hard, and so can creating one.
Rules
A third way to think of notional machines is as rules that do not illustrate but express what the machine does. For example, imagine a student already understands how while works in Python. Then we could explain for in terms of while as follows:
i == 0
while i < 10:
print(i)
i += 1
is equal to
for i in range(10):
print(i)
And of course that rule can also be expressed in a more generic way:
i == 0
while i < n:
statements
i += 1
is equal to
for i in range(n):
statements
The benefits of this notional machine is that there are no “lies”, the machine is precisely expressed in terms of understood concepts, but on the other hand, this notation is very abstract and might thus not be accessible to all students, or applicable to all sorts of languages.
Actions
The final category (that we did not discuss before) is an action based notional machine. This idea was suggested by Katie Cunningham as something that is being used in other field commonly, for example in biology where students learn to always draw a certain diagram for DNA or in chemistry where people always write down a chemical equation.
I realized I use something like that in my lessons too:
This is a notional machine because it tries to communicate to learners what the machine also does (look up the value of the variable that was the latest one to be set) but it add an action to it, something to do, even if you do not fully understand the meaning. That is clearly a benefit, it is something you can train as a habit and then you might be able to do it without thinking about it, helping you to read bigger programs.
The risk though, of ‘action notational machines’ is that they might be too disconnected from their meaning (like long division, a student might be able to execute that algorithm without really understanding its meaning).
Interplay between notional machines
So at this point, (besides if these forms are the only ones, and if they are even really different form each other, haha), we don’t know how these forms interact with each other. Are some teachers more likely to use metaphors and while others prefer rules (I think so)? Does it help students to first learn about actions and then rules, or the other way around? Should a curriculum or course use one form to be more consistent, or vary? All very interesting open questions that this classification might help shape. Can you think of other forms? Let me know in the comments!