The problem is based in human nature. When approaching a new concept that appears similar to another concept they already know, people seem to be hardwired try to understand the new concept by creating a metaphor of the old concept works and trying to apply it to the new concept. If the metaphor fails, many people will simply give up on understanding a new and perfectly valid concept, saying simply it doesn’t make sense. The new concept isn’t wrong, the metaphor used to understand it is wrong31.
I personally am convinced that this is why most people find STEM disciplines so hard. The concepts and ideas in the Liberal Arts and Social Sciences are pretty malleable, and even an incorrect metaphor can be twisted and combined with a twisted version of the concept to create a metaphor that sort-of works as explanation of the concept. But in truth the metaphor and the understand are actually invalid.
In STEM, concepts and ideas are much less forgiving, and mean exactly what they mean. Concepts cannot be twisted to fit an incorrect metaphor. STEM forces people to give up incorrect metaphors and adopt new metaphors; a very difficult task.
To better understand what a metaphor is, and why they have to be understood carefully, consider a very common metaphor in CS, that of a stack data structure and a cafeteria tray dispenser, such as the one shown in the figure below.
When learning the stack data structure, the metaphor that is traditionally used is that a tray is placed on the top of the stack of trays, and so the last tray placed is the first one accessed, and a stack is just a Last-In-First-Out (LIFO) queue.
But this metaphor fails quickly. Consider, what is the Big-O of placing a new tray at the top of the dispenser? Since all of the trays must be moved, it is O(n). But as anyone programming a stack data structure knows, placing a new element in a stack is O(1). Something is wrong, and what is wrong is the metaphor32.
It is only when the student comes to understand a stack as it is implemented in an array that a more correct, and much more useful metaphor, is understood.
In more traditional OOP, a class creates a type that is instantiated to create an Object. This Object is defined by the data (instance variables) and behaviors (methods) that are defined in the class. The class represents a type, or model, of what instance of the class will look like when the program is run, and a variable of the class type is created. The type (class) cannot be changed after compilation, and new behaviors and data cannot be added. In Java, and other traditional OOP languages, the definition of the type is statically defined when the program is compiled. The type of variable can be changed at run time, but only by creating a new variable in memory, and that variable must also correspond to a statically defined class.
31 Godel’s theorem proves that no metaphor can ever be sufficient, as complete systems have undecidability, and decidable systems are incomplete. A large part of education should be helping people understand this and teaching them how to give up invalid metaphors when they no longer work.
32 One of my favorite improper use of metaphors is to ask, “What color is faith?”. The obvious answer is yellow, as the Christian Bible describes faith as being “as a mustard seed’, and mustard seeds are yellow. This is obvious non- sense, but I personally encounter this type of reasoning many times every day.
33 Not to make too fine a point here, but this is true in all things in life. We all have prejudices and biases, all of them based on some facts and lots of unexamined metaphors of life we have created. Part of education, and of creating an educated populace, is to teach people to examine their assumptions about their metaphors.