Constructivism is a fairly broad term that encompasses several different concepts: an epistemology (theory of knowledge), a pedagogy (theory of teaching) and more besides. Here’s Juha Sorva’s description of constructivist knowledge acquisition from a recent paper:
The central tenet of the educational paradigm known as constructivism is that people actively construct knowledge rather than passively receiving and storing ready-made knowledge. Knowledge is not taken in as is from an external world, and it is not a copy of what a textbook or teacher said. Instead, knowledge is unique to the person or group that constructed it. Learning occurs as existing knowledge and the learners’ interests interact with new experiences.
I’m fairly happy with that, and Sorva suggests that most educational researchers broadly agree with the above idea. As ever, I’m interested in how this applies to computing in particular, and in this post I’ll briefly discuss constructivism and its application to computing education.
(Various branches of constructivism go much further afield than the above definition. Constructivist epistemology says that there is no absolute truth or knowable world, only our flawed knowledge. Social constructivists, as described by Sorva, “tend to see knowledge as something that is defined through social collaboration and language use”. Especially from a computing standpoint, both of these seem untenable to me. Constructivism is also often conflated with discovery learning, which I am not covering in this post.)
Constructivism in Computing
Ben-Ari highlights two distinct aspects of computing that matter to the application of constructivism:
- A (beginning) CS student has no effective model of a computer. By effective model, I mean a cognitive structure that the student can use to make viable constructions of knowledge, based upon sensory experiences such as reading, listening to lectures and working with, a computer.
- The computer forms an accessible ontological reality. By accessible ontological reality, I mean that a
‘correct’ answer is easily accessible, and moreover, successful performance requires that a normative model of this reality must be constructed.
So, computing students are faced with this twin challenge and opportunity. They come to computing without a realistic idea of how a computer works, but they do have a computer: a fast, responsive device that will accept instructions or commands, and output the definitive result. Their task is to construct, from scratch, an idea of how the computer works. In programming, specifically, this is tied in with being be able to predict and understand what happens when a given program executes.
This mental model of program execution is known as a notional machine. Sorva says: “A notional machine is a characterization of the computer in its role as executor of programs in a particular language or a set of related languages.” Sorva argues that a notional machine is an important thing to tackle in programming education: an incorrect notional machine will cause programmers problems, so making sure that learners form a correct model is surely important. And indeed, in computing more than many other disciplines, there is little or no wiggle room for forming an incorrect model. An incorrect understanding of assignment or procedure calls (or any other fundamental concept) is a barrier to progression.
In programming, there are many different paradigms for programming. Imperative object oriented programming (Java, C#, etc) can be seen as a superset of imperative procedural programming (Pascal, C), but there are also fairly different paradigms like logic programming (Prolog), functional programming (strict like ML, or lazy like Haskell) and other extensions like message-passing concurrent programming. Sorva mentions that different paradigms will need different notional machines, and even goes so far as to disclaim that his results may not apply to functional programming.
There is some interesting ground to be covered in transfer and manipulation for different paradigms. Many programmers who predate the spread of object-oriented programming (OOP) have potentially built their OOP notional machines by extending their procedural programming notional machine. I speculate that a difficulty for some experienced programmers is that it is hard to comprehend someone else’s notional machine arrived at from a fairly different starting point, and so the temptation is to teach the way you learnt — which manifests in attitudes such as “you need to understand assembly language first”. At the other end of the scale, there are things like the objects-first pedagogy, which aims to build an understanding of OOP directly, without first covering procedural programming separately.
The notional machine idea embeds the constructed-knowledge idea of constructivism at the heart of programming: programmers must construct their own notional machine in order to function as programmers. The particular constraint for constructivism here is that there is little flexibility for each learner to construct their own model: the model must still fit the true model very accurately, or there will be big problems for the learner. It would no doubt be much easier if we could adopt the classical model of pouring knowledge into students! There are all sorts of ideas on techniques to encourage correct notional machine formation: code reading, program tracing, execution visualisation and more, which Sorva covers in his paper/thesis — links are below.
Mordechai Ben-Ari. Constructivism in Computer Science Education. SIGCSE, 1998. Free PDF version available.
Juha Sorva. Notional Machines and Introductory Programming Education. ACM Trans. Comput. Educ. 13(2), June 2013. Unfortunately, there’s no freely available version at the moment, but the sizeable thesis on which the paper is based is freely available.