How should I respond to a student who proposes a "weak" analogy?

Question

I'm teaching programming with JS at the highschool level, students have some prior experience with programming with different languages but are still mostly beginners, and we're working through some core language concepts. A few times now the situation has come up where I introduce some new concept, and a student suggests it's similar to something encountered before. The analogy initially seems like it doesn't work, if I ask them to elaborate, they usually do find some connection between the ideas, but it seems (to someone with more experience) like a pretty convoluted relationship.

A concrete example: we ran into attaching multiple event listeners to a single DOM element in a browser context. A student suggested that event listeners are like arrays. After discussing it, the connection the student saw, was that you could add or remove items from arrays and you can add and remove event listeners from elements. Nothing the student said was incorrect, but I was concerned saying "yes, event listeners are like arrays" wasn't a terribly useful analogy in reasoning about either construct.

What is a good way of dealing with this situation? I don't want to shut students down who make connections like this, it seems like a very productive way of thinking in general, but I also don't want to propagate misconceptions or encourage a questionable mental model.

Answer 1

It seems to me that you have a good process going, encouraging students to participate and give their ideas. Of course, they are students, so their explanations and insights are likely to be incomplete, even flawed. However, encouraging them is still a good thing and their attempts to put two things together will lead to better thinking as long as you monitor it and intervene as needed.

Your desire to not "shut them down" or discourage them is also to be commended. You do need, of course, to put them on the proper path. So such student comments, like most student contributions, should be treated as an opportunity to go deeper. You can acknowledge the validity of the student's analogy (partial validity) and still suggest that the student also describe how and where the analogy fails. In fact, no analogy is perfect: A is "something like" B is a good way to think about an analogy, not A is "just like" B. In fact A is "also unlike" B is nearly always worth exploring, even for strong analogies. For example, in Java, an object is something like a dog.

Hmmmm.

Well, a dog responds to messages as does a Java object. But I never met a java object that liked to be scratched behind the ears. In fact, the difference is also instructive. Dogs are only somewhat "encapsulated" and solely in control of themselves. You can break that encapsulation with physical force, dragging the dog along by its collar (not a nice thing to do, though). But a properly encapsulated Java object is immune from such things, though you can, of course, re-program the system.

I don't claim my simple example above is definitive, but it was only an attempt to quickly come up with a way to move the conversation in a productive direction.

Some analogies are better than others. But every student contribution is an opportunity for exploration.

Answer 2

The concrete example:

Your student is right. At least, I agree with him, because I think of event listeners in the same way.

When multiple callers register for the same event, and the event triggers, it "calls everyone back". Functionally, it's similar to how an array or list is processed, e.g. :

foreach (var caller in callers)
{
    caller.Call();
}

The thing about abstract fields such as programming and mathematics is that people will find what works for them. Not everyone sees it the same way.

I may be biased because me and the student apparently see it the same way; but I'm actually having a hard time poking holes into his argument, without having to resort to fairly avanced event handling (and even then, the analogy sort of works).

---

Anecdotally:

A simple example for math applies to me. When considering the average of two numbers, most people think to themselves:

average = (A + B) / 2;

However, I instinctively used another pattern:

average = A + (B-A)/2 

Note that A is always the smallest number.

This looks a lot more contrived. I agree. But to me personally, it was easier to do it like that. I'm someone who uses number forms to visualize numbers in my head, which means I do simple calculations visually (sort of, it's hard to explain).

When you ask me to calculate the average of 45 and 51, what I see in my head is:

... 43 44 45 46 47 48 49 50 51 52 53 ...

I take the numbers between the boundaries:

46 47 48 49 50

And I find the middle number.

48

When you look back at "my" formula, maybe you'll see that the order of operations is the same as this visual example. Take the difference, split it in two, find what's in the middle.
To me, it makes perfect sense, and I am considerably faster when calculating averages (of 2 numbers) this way.

I reverted to using the more standard approach when math classes started requiring us to calculate the average of more than 2 numbers. But for finding the average of two numbers, I still use my own method to this very day.

---

How to respond:

Even though the student is correct (in his own way), if you simply agree with his stance, others may misunderstand him (because they e.g. think of arrays in a different way than the student who raised the analogy).

You need to approach it correctly, because you can't err on either side:

• If you tell the student he is wrong (for the sake of the other students), then he will be incredibly confused. I've been on the receiving end of this, and it took me some time to regain the confidence to use my own averaging method.
• If you tell the student he is right (for the sake of the student), then the other students may end up incredibly confused.

So when you respond, make it clear that you understand what the student means, but it's not exactly the same in every way.

For example:

I see what you mean, and this particular case does indeed behave similar to an "array of listeners". But there are other cases where the analogy doesn't quite work, so be aware of that.

Or:

I can see where you're coming from. As you now understand it, there are indeed some similarities. However, once we delve into more advanced examples, you'll start to notice that it's not quite the same. Try to not stick to the analogy because you'll end up expecting different behavior.

I think this sticks to the middle of the road:

• It confirms the student's basic interpretation of the code's behavior.
• It highlights that the analogy is not perfect and flawed when applied to other cases.
• Other students who have no idea what the student was talking about (because they understand it in a different way) will understand that the analogy is flawed and not generally usable, so they won't fixate on understanding why this analogy sort of works and will instead be more likely to ignore it and move on.

There are of course countless ways to respond, but you should always try to find a compromise that both confirms the student's vague suspicion, suggests that it only works in particular cases, and it avoids creating confusion for the other students.

Specifically for this example, my response would be:

Yes, even listeners can be considered as an "array of listeners" where you can add/remove listeners as you please. However, "an array of something" is an incredibly common concept in programming. Whether it's getting data from a database (a table is an array of entries) or parsing a string (which is an array of characters), you'll find arrays and lists everywhere you look.
When we get to the more advanced part of the curriculum, almost everything will use an array-like approach at one point or another.

Answer 3

A student suggested that event listeners are like arrays. After discussing it, the connection the student saw, was that you could add or remove items from arrays and you can add and remove event listeners from elements.

To expand on my comment on the OP, there are two comparisons being made here and I suspect getting muddled between these is the source of the confusion. Depending on which one the student was going for will determine whether the student was correct or not.

1. event listeners vs arrays
2. collections of event listeners (contained within a DOM element) vs arrays

In this case I would argue that the second case is not wrong given that their interfaces are similar (that they are both collections, in the same way that a herd of sheep is similar to a herd of zebras).

Nothing the student said was incorrect, but I was concerned saying "yes, event listeners are like arrays" wasn't a terribly useful analogy in reasoning about either construct.

As above, it depends on exactly which comparison is being made as they are very distinct claims.

A similar analogy would be to consider a room in a building being similar to a car (in that it can contain people and people can sit down and you can have a radio playing) but... then claim a human is similar to a car (as opposed to claiming that "things which can contain humans" are similar).

How to handle it in the classroom..

I applaud you for taking the time/effort to dig a little deeper into understanding the student's (mis-)conceptions.

Personally I have found being completely upfront with students that I'm not an oracle with all the answers (but that I am happy to have a think about it and/or work through it with them) has been successful. Specifically, by explaining that it seems to fit/work well at the moment based on what has been said, but there are some significant(?) differences and/or nuances where the analogy falls down but right now I am struggling to understand/explain how and why - followed by asking if it is okay to move on for the moment and later take some additional time to properly think about it before getting back to them.

I would like to think that students appreciate the honesty and that the frankness/openness that, sometimes, everyone (including teachers) needs to ask questions/go away and think about things regardless of skill level - i.e. that it's okay for them as novices to do so also!

Answer 4

An array is like a list of event handlers. But it is not like an event handler. Telling students stuff does not work well, but having them discover it does.

The student has seen something in the description that is like an array, this is good they are making connections. Unfortunately (at you say) they may make the wrong connection. You are discussing a list/array of event handlers, the student thinks you are talking about event handlers.

Therefore as @Buffy said, ask them to elaborate. Ask how it is like an array, and how it is not.

You could also do an active learning activity: have a student be an event handler, another to be an event, a sheet of paper to be a button. Act this through. Then add another event-handler/student, then another. Where do they go? What is the data structure that the event-handlers are in. What do we have to do to trigger all of the events-handlers. [There is something else doing a foreach event_handler in event_handlers]