Communications of the ACM
Dijkstra Was Wrong About 'Radical Novelty': Metaphors in CS Education
Credit: University of Michigan
Edsger Dijkstra's 1988 paper "On the Cruelty of Really Teaching Computer Science" (in plain text form here) is one of the most well-cited papers on computer science (CS) education. It's also wrong. A growing body of recent research explores the very topic that Dijkstra tried to warn us away from — how we learn and teach computer science with metaphor.
According to Google Scholar, Dijkstra's paper has been cited 571 times. In contrast, the most-cited paper in all of the ACM Digital Library papers related to SIGCSE has 412 citations (see data here). Dijkstra's paper has been cited more than any peer-reviewed CS education research. Many of these citations might be citing the "cruelty" paper as a foil, like Owen Astrachan's "On the Cruelty of Really Teaching Computer Science redux."
Dijkstra's argument is that computers represent "radical novelty." There's nothing like them in human experience, and we cannot use our past experience to understand them. In particular, we shouldn't use metaphors.
It is the most common way of trying to cope with novelty: by means of metaphors and analogies we try to link the new to the old, the novel to the familiar. Under sufficiently slow and gradual change, it works reasonably well; in the case of a sharp discontinuity, however, the method breaks down: though we may glorify it with the name "common sense", our past experience is no longer relevant, the analogies become too shallow, and the metaphors become more misleading than illuminating. This is the situation that is characteristic for the "radical" novelty.
Coping with radical novelty requires an orthogonal method. One must consider one's own past, the experiences collected, and the habits formed in it as an unfortunate accident of history, and one has to approach the radical novelty with a blank mind, consciously refusing to try to link it with what is already familiar, because the familiar is hopelessly inadequate.
We now know that this is likely impossible. The learning sciences tell us that all learning is based on connecting new experiences to previous, through a process called constructivism developed by Jean Piaget (see a nice explanation here). Trying to learn something without connection to prior experience inhibits learning. It leads to a phenomenon called inert knowledge (see Wikipedia page) where you have memorized stuff to pass the test, but you don't really understand and can't really use the knowledge.
I never really thought much about the metaphors we use to learn and teach computer science until the SIGCSE 2014 paper "Metaphors we teach by." CS teachers and students have been ignoring Dijkstra's admonitions all along. They teach with a variety of metaphors, and though all of them have limitations (Dijkstra was right about that), this paper explored how teachers dealt with the breaking point.
A 2019 paper "Identifying embodied metaphors for computing education" goes a step further, to focus on the metaphors that are based on physicality. From a "radical novelty" perspective, this may seem ridiculous — nothing could be less physical than ideas like "arrays" and "control flow." But from a "constructivism" perspective, nothing could be more natural. The basis for all our experiences are being physical beings in a physical world. When we're dealing with new ideas, we will likely relate them to physical processes.
I'm working with Ph.D. student Amber Solomon, who has been studying how teachers teach recursion and how students learn it. She had a paper this last summer at the 2020 International Conference of the Learning Sciences about the embodied metaphors that teachers use when teaching recursion (see blog post summary here). Teachers gesture and point, but it's not clear to what. They talk about being "here" and "going." They use language that suggests metaphors like the program "says" something.
Amber is co-advised by Betsy DiSalvo and me. The three of us have been spending time coding her videos of CS students understanding and modifying programs that use recursion. These are absolutely fascinating, and once you start looking for metaphors and uses of embodiment, you see it everywhere. I particularly like how students shift metaphors, e.g., talking about the recursive function "going" and then being "stopped" by the base case, then talking about "going down" the stack and execution being different "on the way back up." We know that there is no "down," "back," or "up" in a computer process — these are examples of using concepts from our everyday, physical world to understand computational processes.
In 1988 when Dijkstra wrote this piece, cognitive science journals were only about a decade old, and learning sciences wasn't established until the 1990s. It's understandable that Dijkstra might not have known about constructivism. Today, we know constructivism as the most widely-accepted theory of how humans learn. Using a constructivist lens on learning about computing, we can better understand how to help students use their everyday knowledge as metaphors to learn computer science.
Mark Guzdial is professor of electrical engineering and computer science in the College of Engineering, and professor of information in the School of Information, of the University of Michigan.
Comments
Thomas Jones
Dijkstra Was Wrong is Wrong.
The idea that we can evaluate Dijkistra's paper given what we know today is Presentism and misses the points that Dijkistra was making. If we want to make progress we need to fully exploit what we know already (Guzdial's point) but we also need to go to the next level. In that effort past metaphores get in out way. I, myself, find that when i am stuck, i often need to abandon what i know already and seek to find what it is that I do not know. Kurt Godel needed to abandon Russel's existing knowlege to find a new way of thinking about uncertainty. The same can be said for Claude Shannon and Dijkistra himself. Lampson taught us that All problems in computer science can be solved by another layer of abstraction. And our new computer scientists need to understand that!
Mark Guzdial
Hi Thomas,
As I write at the end of the post, we can't blame Dijkstra for getting it wrong. He likely did not have access to the cognitive science findings that we have today. It's still important to identify how new knowledge helps us correct prior understanding. Dijkstra published many wrong ideas about education which get cited even today. It's important to correct those.
There is an assumption in your note, and in Dijkstra's original essay, which is no longer true today. Most students studying computer science today are *not* preparing to become computer scientists. As computing education grows in K-12 education, and as we provide computing education to non-CS majors (e.g., computational scientists and journalists), we have to recognize that we are not always preparing students to "go to the next level," as you put it. Think about the challenge of teaching a 12 year old about programming in Scratch without relying on any metaphors or prior knowledge. You would be unlikely to succeed.
Maybe Dijkstra's admonition to avoid metaphor has some value for students at or going to the frontiers of computer science knowledge. It's not good advice for most students studying computer science today.
Thomas Mcguire
Mark,
While constructivism has its place, I'm not sure Dijkstra is wrong. To quote from one of your references on constructivist theory;
"The constructivist theory posits that knowledge can only exist within the human mind, and that it does not have to match any real world reality" (Driscoll, 2000).
This is what Dijkstra is trying to overcome. Rather than leave it to chance that the abstractions students develop are useful. He wants to provide students with a mathematical framework on which to rely on. He calls it his Formal Method Initiative. The implication being: regardless of how the student's brain has decided to store the Formal Methods, when they are presented in concrete form they should adhere to the rules of the method. More importantly the Formal Methods would be understandable to the student and others. The concrete form should also be proven, to the extent of the student's ability and within the rules of the Formal Method.
Dijkstra talks of the dangers of operational reasoning as being inefficient and being caused by simplistic metaphors. I believe this is more dangerous now than in days of Dijkstra's talk. Today everyone has a graphical computer environment at their disposal. People code first and think about structure and architecture later. In the decade preceding Dijkstra's talk getting on a computer was more difficult and a lot of preparation with pen, paper and chalk board preceded the actual coding (especially for students).
My own children are guilty of this type of reasoning and they shudder when I break out pen and paper to draw a rough sketch of what they should be trying to accomplish.
I agree with you for non-CS majors, however you can get them functional is fine. But I took your blog subject to mean: how can we educate to make computer science as a career, more accessible to more students who may be interested in the field. Unfortunately, I believe the biggest draw back is time. Computers are much like a musical instrument, It takes hours of practice to become proficient and many people are not willing to put in the time.
Mark Guzdial
Hi Thomas,
You raise an interesting point at the end -- what is the goal of CS education? For whom are we aiming CS education? Certainly, we do care about those who are making computer science their career. For my work, I'm far more interested in the larger population of people who need to know something about computing but will not be computer science professionals.
In either case, everyone walks before they run. Imagine how difficult it would be to learn to speak if we told babies that they were wrong whenever they spoke in less than grammatically correct sentences? Everyone starts out in every field in essentially the same way: Trying things out and messing around, using experiences and metaphors from daily life, and making many mistakes and failures. We have to allow for that. Formal Methods don't come first. Planning before doing doesn't come first. Yes, we want more from professionals. For most people, developing understanding is more important than being planful and methodological.
Displaying all 4 comments