July 14, 2023

Explain Like I'm Five How I taught Ms Zdan's first-graders to empathize with a machine, and you can too!

Little kids use computers all the time. Increasingly early in their schooling, they also learn how to write code. However, learning about computing entails more than just learning to code.

Jumping straight into code has its drawbacks. A first attempt at writing code is often frustrating because the computer feels like an obtuse, unreasonable entity that just does things a certain way. Because it wants to; because it can. The best one can do is to memorize this behavior and deal with it. At worst, the computer becomes the adversary. At best, it becomes an eccentric and unreliable teammate with whom we have somehow learned to collaborate.

Computational thinking, a cool new idea from Jeannette Wing, argues that people need to understand how a computer thinks, what compels it, and what limits it. I think it's possible, and worthwhile, to introduce these ideas to our youngest students, even before they learn to code. I have a fun idea for how to introduce the concept of binary numbers to first-graders in a way that is interactive, physically embodied, and exciting for kids. I executed these ideas over a series of four lessons at Beverly J Martin Elementary, and this is my lesson plan.

### Lesson 1: a tale of two hungry cities

I went into class with eight cards, each colored red on one side and blue on the other. I split the class into two groups, standing in huddles on opposite ends of the room. Each group got one card and I explained the game:

You are two cities on hills, and you have a zip line that carries food between you. Occasionally you'd like to order something to eat from the other city, but the cities are rather far apart and you can only communicate using your cards. A card is either red or blue, and you can order either a burger or spaghetti.

I allowed them one meeting to come up with a plan, and they quickly had something: red would mean a burger, and blue spaghetti.

SignalOrder
Rburger
Btheyspaghetti

I sneaked up to one city and whispered, "Can you order me a burger, please?", and the students delivered. I ran to the other city and got them to order me some spaghetti. Then I went to the first city and requested that they order me a hot dog. Pandemonium. I was accused of being a naughty man.

A student proposed that flashing no card could mean a hot dog, but I steered them away from that: "Well some days you may want to order nothing at all; reserve no card for that."

Someone proposed balancing the card between red and blue, or swapping quickly between red and blue; I steered them clear of these too. After a minute I offered each city a second card, and they had an answer right away. The old rules would remain, and any two cards would mean hot dog.

SignalOrder
Rburger
Btheyspaghetti
RR, BB, RB, BRhot dog

This made me a little nervous since it was not part of the plan, but I moved us along: "Well this is great, but what if the other city confuses the hot dog order with two burgers or two things of spaghetti? Or a burger that is chopped up and mixed into spaghetti?"

They figured out a way to make me happy:

SignalOrder
RRburger
BBtheyspaghetti
RB, BRhot dog

and, on prodding, they realized they could order yet another thing:

SignalOrder
RRburger
BBtheyspaghetti
RBhot dog
BRbibimbap

Finally I handed them a third card, asked them to make the longest list they could, and left the room. I returned to a menu of eight items and some rather hungry kids.

We were out of time, but the students had enough fun that Ms Zdan requested that I leave the cards for them to play with. I left her with all eight cards, and a hint: n cards can say 2n things.

### Lesson 2: computer as nation-state

I brought in a motherboard from the lab and showed it to the class. There was a lot going on, but I made the key point: a chip has a bunch of things that are connected by wire to other things.

As in the image above, I pointed out two large components that were connected directly using wire (in the image, look for the gray squares, and notice that they are connected directly by four pairs of wire). These components were like our cities on hills, and the wires like our cards. Power flowing through a wire? That's a blue card. No power? That's a red card. A computer chip has way more than two components, and those components need to talk each other all the time. All of the confusion that my students faced with the card game was also the computer's confusion, and all their limitations also applied to the computer.

The kids were especially excited to see that the motherboard had a little fan, and this led to a discussion about how running electricity through a computer chip causes it to heat up. My students were young enough to have never actually handled incandescent lightbulbs, so that example fell flat on its face. However, they had almost all used their parents' phones and tablets for hours in a row and knew that those got hot. I explained that we could use less power to keep the temperature down, but that would make it harder to tell whether a wire was sending power or not. The kids made a neat connection to the cities-on-hills game: this was like ordering food on a really foggy day, when it was hard for the other city to see the color of the card.

An aside that I did not bring up with the kids: in the card game, we reserved the no card signal for no order. This is not actually available to a computer, since even the silence of a wire has a semantic meaning. To get around this, a computer uses a special signal to mean no signal.

### Lesson 3: how a computer stores a number

Ms Zdan reported that the students had taken to playing the card game in their free time. By the time I arrived for the third lesson, they were absolute pros at ordering food by zip line. They had figured out that they could use four cards to say sixteen things, and had begun to write down their "codes" on little cheatsheets.

I made the point that all of this was only working because everyone had the same cheatsheets: if I slipped a wonky cheatsheet into the mix, the whole system would break down. We said, together, the biggest word of the day: protocol. They had arrived at a protocol for ordering food, just as computers have protocols for their electrical signals.

We went back to two cards and four items, and I explained that the real challenge was not making a long list, but making a long list that was still short enough to later pick out a unique item. Indeed, they could make a list of any four things and use two cards to pick out the right one. For instance, they could use two cards to control their teacher around the room:

SignalOrder
RRAnshuman walks to the right
BBAnshuman walks to the left
RBAnshuman walks towards you
BRtheyAnshuman walks away from you

and of course we spent a good five minutes having me bumble around the room like a robot.

I explained that a computer does the same thing, but with numbers. We made a list of the kids' favorite numbers, and gave them card-based signals:

SignalNumber
RRa thousand!
RBtheya thousand and one!
BRa million!
BBa quintajillion!

Fun fact: little kids love big numbers.

We took a minute to write 0 on every card's red side and 1 on every card's blue side, and then I told them what a computer's favorite eight numbers are: 0, 1, 2, 3, 4, 5, 6, and 7. Rather boring in comparison, yes, but could we signal them? Yes we could:

Signal
(color)
Signal
(binary) they
Number
(computer)
RRRtheythey0000
RRB0011
RBR0102
RBB0113
BRR1004
BRB1015
BBR1106
BBB1117

We wrote this down on our little protocol cheatsheets and called it a day.

### Lesson 4: counting too far

We started the day with a little arithmetic. How do we add 6 and 3? My students were early enough in their education that they did this exactly the way I wanted them to:

We put up six fingers and say out loud, "one, two, three". As we say each number, we put up an additional finger. Then we stop and think. How many fingers do we have up? Nine!

I then asked them to add 6 and 5. They started off strong, but then, at ten, ran out of fingers. Some of them counted a toe, but most just contented themselves with calling me a naughty man again. I explained that a computer sometimes has a similar problem: it wants to keep going but it runs out of ways of holding on to information, just like running out of fingers to count or cards to signal with.

I requested a volunteer, and they and I stood in front of the room facing the class. I told the class that we were both on a number line running across the front of the room. We were both currently at 0. My volunteer would count like a person, while I would count like a computer.

0123456789
themtheytheytheytheytheytheytheytheythey
me

"One more!" I said, and we both hopped over to stand on 1.

0123456789
theythemtheytheytheytheytheytheytheythey
me

The class took over. One more! One more! We eventually landed at:

0123456789
theytheytheytheytheytheytheythemtheythey
me

One more! I ran to the other end of the number line and stood on 0, while my volunteer jumped to eight:

0123456789
theytheytheytheytheytheytheytheythemthey
me

There was a little riot. Once we had settled down, I asked them to look at their cheat sheets from the previous time:

Signal
(color)
Signal
(binary) they
Number
(computer)
RRRtheythey0000
RRB0011
RBR0102
RBB0113
BRR1004
BRB1015
BBR1106
BBB1117

What was a poor computer to do? I had simply run out of unique signals after 7, and I wanted to do something reasonable, so I had wrapped around to 0.

I explained that a computer does the same thing, and that it is called overflow. By and large, the largest number that a computer can express, plus one, is the smallest number it can express.

So what's the big deal?

Well, let's say we're in a car with our mom. The speedometer says we're doing seven miles per hour, and, yup, we are. Then mom hits the gas a hair and the speedometer says we're doing zero. Actually, we're doing eight. Hmm, there's a bunch of stuff that we're allowed to do at zero miles an hour: we're allowed to unbuckle our seatbelts, open the door, step out for ice-cream. Doing this at eight miles per hour is a bad idea, and we know it.

With this, we wrapped up. I like to think that my students left with a little more empathy for the computer, and all the little hoops it needs to jump through while it does our bidding.

### Further reading for the precocious student (or teacher)

I designed the lesson plan above with some care, trying to tell no untruths and yet not to overwhelm. No doubt there will be further questions. I'll answer some of them here.

In the example I just used positive numbers, so I was able to use my three digits to count from 0 to 7. When we know we'll need negative numbers, we commonly use the same signals to instead mean:

Signal
(color)
Signal
(binary) they
Number
(computer)
RRRtheythey0000
RRB0011
RBR0102
RBB0113
BRR100-4
BRB101-3
BBR110-2
BBB111-1

As you know, we are at liberty to choose any eight numbers we like. The choice I've shown above may feel rather obscure, but it is actually a very clever way of representing negative numbers. Read more about that here!

#### I'm pretty sure my computer can count way past seven. What's up with that?

In the example, a computer has three digits and each digit can be either 0 or 1, and so it can say 23 = 8 things. A modern computer actually has 64 digits, and so it can say 264 things. That's 1.84 x 1019, more than there are grains of sand on Earth.

#### Is this overflow business real? What do we do about it?

Oh it's real. Consider the following code, written in a language called OCaml. My questions start with # and end with ;;. The computer's answers start with - : int =.

# max_int;;
- : int = 4611686018427387903
# 4611686018427387903 + 1;;
- : int = -4611686018427387904
# min_int;;
- : int = -4611686018427387904


First I asked OCaml to please tell me the biggest number it can handle. Then I added one to it. The answer was a rather small number; note that we've gone deeply negative. In fact, it was the smallest number OCaml can handle.

We have clever ways of checking for overflow, but here's the thing: arithmetic accompanied by a special check for overflow is meaningfully more expensive than plain arithmetic. We want to run these special checks judiciously. As an analogy, consider a person who gives their car a 75-minute inspection every morning before driving ten minutes to work. They'll be safe, but they'll also be late. Checking the car before each big family road trip is probably enough.

Yet another instance where the computer must tread a tightrope!

Sometimes, after analyzing a piece of code carefully, we're pretty sure that overflow cannot possibly occur in that code, so we allow ourselves to skip such checks. However, this analysis is tricky and we had better make sure we get them right. In 2021 I helped show that Dijkstra's algorithm, a classic algorithm that has been taught and used for over 60 years, can overflow in a way that was not previously known. I'll let you read all about that here.

### Acknowledgments

An enormous thank you to Ms Zdan, her teaching aide Ms Jenn, and her delightful students. My time at Beverly J Martin Elementary School was facilitated by Cornell University's grasshopr program, a volunteer organization that pairs graduate students with K-12 teachers so we can share our research with curious students. This is hard, important, rewarding work, and you are superstars for making it happen every year.