isbn9789526046266

A high-level OO machine?
Sajaniemi and Kuittinen’s object-oriented notional machine operates on the same level of abstraction as
their procedural notional machine, dealing with primitives such as variables and stack frames. In contrast,
Bergin emphasizes the dramatically different way computation is thought about in OOP:
One fairly typical component of a beginning course of programming using the procedural
paradigm is a discussion of the von Neumann machine architecture. [. . . ] This simple machine
model fits well with the procedural paradigm, but less well with other, more abstract, ways of
looking at computation. There is a simple relationship between the physical level provided by
the von Neumann architecture and the virtual level provided by most procedural languages.
This is just not the case with the functional or object-oriented paradigm. The functional
paradigm, of course, completely hides the underlying physical architecture. The objectoriented
one does not hide it, but turns it on its head. Instead of the data being moved
to the CPU for processing, a very common metaphor in OOP is that the CPU moves inside
the objects. (Bergin, 2000)
Gries (2008) also criticizes the use of low-level abstractions in teaching object-orientation:
But many programming texts fail to use abstraction appropriately, e.g., by describing variables
and assignment in terms of computers [. . . ]
“A variable is a name for a memory location used to hold a value of some particular data
type.”
“When [the assignment statement is] executed, the expression is evaluated . . . and the
result is stored in the memory location . . . .”
“The computer must always know the type of value to be stored in the memory location
associated with a variable.”
“An object reference variable actually stores the address where the object is stored in
memory.”
[. . . ] introducing computing concepts in terms of the computer can create unnecessary and
confusing detail, especially when OO concepts are described in terms of a computer, with
discussions of pointers to objects in memory, heaps, and other implementation-related terms.
(p. 32)
Gries prefers to scrap difficult terminology – e.g., ‘reference’, ‘pointer’ – as “with appropriate abstraction
away from the computer, these terms become unnecessary”. We saw Gries’s higher-level conceptual model
of objects and classes in Section 10.3.
In a similar vein to Gries, Caspersen and his colleagues (Caspersen, 2007; Bennedsen and Schulte,
2006; Henriksen, 2007) have sought to represent an object-oriented notional machine on a higher level
of abstraction. They argue that object-oriented programmers need to understand program execution in
terms of a notional machine that deals with interacting object structures. Henriksen (2007) envisioned a
visualization of a notional machine that would abstract out execution details such as expression evaluation
and concentrate on object interactions. Caspersen (2007) outlines a future system in which students could
‘play’ with the visualization of an object model, stepping forward and backward, and making changes to
program state at will (cf. Victor, 2012).
Two machines?
Berglund and Lister (2007, 2010) found through phenomenographic analysis that amongst participants
in the objects-early debate, objects early is experienced in different ways: as learning an extension
of imperative programming or as learning something conceptually quite distinct from imperative
programming. This qualitative divide is, in my interpretation, reflected in the literature on object-oriented
138