Learning computing with metaphors

Don’t think of an elephant!

Now what are you thinking about? Of course, it’s an elephant.

This sentence is the title of a book by George Lakoff, a contemporary linguist who makes that case that we frame our thinking with the words and metaphors we use. By consciously recognizing this, we can understand our own thinking better and become more persuasive.

Inspired by Lakoff’s work, Alvaro Videla published an essay Metaphors We Compute By in the October 2017 Communications of the ACM. As a computer scientist and software engineer, Videla recognized the extent to which we make sense of concepts in computing via metaphors. He gives this example:

Say you could program a computer to command other computers to perform tasks, respecting their arrival order. This description is already difficult to understand. On the other hand, you could describe the solution by describing a queue server that assigns jobs to workers based on a first-come, first-served queue discipline.

Consider all the examples from daily life in the description of the solution: A “queue” is something with which all of us are familiar—that’s a “line” for those of us speaking American English! “First-come, first-served” is how most everyday lines operate, “workers” and “jobs” are people and roles from our daily lives.

With this metaphor, it makes sense. The everyday concepts translate into computational artifacts. A worker becomes an operating-systems process. A job becomes an algorithm carried out by that process on some particular data. The line becomes a FIFO queue.

This idea of using metaphors goes back far in our field. Some of the early CS education research focused on how the names of words chosen to be language commands helped (or hindered) students’ understanding. For example, in the 1987 article The Buggy Path to Development of Programming Expertise, Pea, Soloway and Spohrer reported on how students expected parallelism in BASIC code with “IF… THEN” statements. They thought the computer could evaluate any statement as needed, firing when a condition became true—as it might be in daily life.

I’ve used metaphors to explain function application—a concept in functional programming. It’s similar to how parameters or arguments are supplied to C or Java functions. I brought a rubber mallet to class, and described function application as the mallet “pounding the parameters on the head.” So if you have a function increment, which adds one to its parameter, then increment sees a 3, pounds it, and produces a 4. Then “functional mapping” is walking down a list, pounding each parameter in turn. In Scheme: (map increment (list 1 2 3 4)) produces the list (2 3 4 5).

Later during the semester, I could just pretend I was holding the mallet to bring back the idea of function application.

What metaphors have you introduced to your students to help them understand computing concepts? Did they work? Have you changed them over time? Please share with your colleagues!

head shot of Fred Martin, chair of board of directors

Fred Martin, chair of board of directors

Just released: Video interviews on computational thinking

What is computational thinking?

How is computational thinking distinct from other thinking skills?

How can teachers assess computational thinking skills?

Have you ever wanted to ask an expert these questions? The CSTA Computational Thinking Task Force is creating a series of video interviews in which we do just that!

Listen in on our conversation with Chris Stephenson, Director of Computer Science Education Programs at Google, as she answers our questions and describes cross curricular computational thinking applications in the task of preserving native languages (https://youtu.be/FuN6g8NmuHc).

Listen to our conversation with Eric Snow, Education Researcher in the Center for Technology in Learning at SRI International as he answers our questions and describes his research in assessing computational thinking (https://youtu.be/92pv8dPItjE).

We have several more interviews with experts in the field planned for later this fall.

All of the interviews are archived here: csteachers.org/page/CompThinkInterviews.

A History of the New Math (and lessons for CS Ed)

Spines of New Math paperbacks from the 1960s (courtesy wikimedia.org)

Spines of New Math paperbacks from the 1960s (courtesy wikimedia.org)

Many of us remember the New Math from personal experience. I do from elementary school in the 1970s in West Hurley, NY.

I loved it. I learned that the decimal system is arbitrary and numbers could be expressed in any base. That was fascinating.

Of course, I was the kid who learned his times tables for fun.

The New Math emphasized understanding the rule-systems that underlie numbers. In elementary school, it constructed the very concept of number with set theory rather than by rote counting.

There wasn’t a focus on students being able to do arithmetic computations. This upset people, and by the 1970s, the New Math was under attack.

The “back to basics” movement re-established an emphasis on computations in the 1980s.

As described by Christopher J. Phillips in his book The New Math: A Political History (The University of Chicago Press, 2015), it’s not a coincidence that this is the same decade in which the country elected Ronald Reagan as president.

Phillips cogently makes the case that the rise and fall of the New Math movement traces our cultural mores and larger political beliefs about who should be making decisions in our society.

Going back two thousand years, Phillips shows how the argument about how mathematics should be taught has been a proxy for a conversation about how people should be taught to think.

For the developers of the New Math, their approach would help American citizens be critical and creative thinkers—what was required to counter the Cold War threat of a dominant Soviet Union.

Indeed, the federal funding that was leveraged in the 1950s to build the New Math movement was appropriated as literally a matter of national defense. This was followed by the Elementary and Secondary Education Act in the 1960s, which continued the federal government’s role in fostering national education curricula.

The consensus that the federal government should be deciding what’s taught in our nation’s schools frayed with the cultural changes in the 1960s and collapsed with the horrors of Vietnam in the 1970s.

As we work towards making computer science a first-class citizen in the pantheon of school teaching and learning, what lessons can we draw from the rise and fall of the New Math?

Computer science is a liberal art—not just a vocational skill. It’s true that becoming accomplished as a software developer is a path to a good career, including good pay. And it’s true that there is a social justice dimension to broadening participation in computing—everyone should discover whether they love computing and then have access to these career paths.

But the reason to institutionalize computer science in K-12 is deeper than that. It’s because computing is beautiful and powerful—like all forms of knowing and doing.

We must go beyond the zero-sum game. One of our big challenges is creating time for teaching and learning computing. We don’t want to create winners (computer science) and losers (other areas of study).

It seems clear that infusion approaches—integrating computing into other subjects—will be an important part of the future.

It’s a team effort. One of the big take-aways from Phillips’ book was the reach of the School Mathematics Study Group—the organization that was created to develop and support the New Math. Curriculum writers from all over the country were involved in creating the reference texts; these individuals then served in leadership roles in the adoptions in their home states.

Most importantly, now we live in a time where everyone’s involved in curriculum decisions, particularly parents.

We need everyone together to make this happen.

P.S. I highly recommend Christopher Phillips’ book. His writing is clean and compelling, and the story is engaging and compact. He also published an essay-length version of his thesis in the New York Times on December 3, 2015.

Welcome to our treehouse

This is a guest blog post by Kim Douglas, a student at UMass Lowell. Kim has a BA degree from Emerson College in Animation & Motion Media.

When people ask me what I’m studying, and I tell them that I’m pursuing a degree in computer science, they usually say one of two things.

  1. “Oh, I totally should’ve done that. Tons of great-paying jobs in that field!”
  2. “Oh, I totally should’ve done that. But I’m not smart enough.”

I usually just smile politely and deflect, because these conversations tend to happen with adults who are well on their way, doing whatever they’re doing with their lives. But the truth is, responses like this frustrate me.

I wonder if the people with this first response are being earnest; whether their interest is for the right reasons. After all, everybody hates it when their favorite song becomes popular—especially if that song came from a collection of painstakingly curated mixtapes. I’ve only been programming for a few years, and still I feel this way.

Here I am, just halfway up the ladder to the neighborhood treehouse, and I already want to put up a “KEEP OUT!” sign for the kid behind me!


Then I think about how computer science makes me happy, and how it makes other people happy. Now, the second response—“Oh, I totally would’ve done that, but I’m not smart enough”—is even more frustrating. Because chances are, it’s just not true!

These people probably are smart enough, but got intimidated by the steep learning curve nonetheless. Yes, we should blame the media for that, but we should also blame ourselves. People start to see the KEEP OUT signs at a pretty young age.

Wait, come back! We need your hammer to fix our treehouse!

I am a researcher in the Middle School Pathways in Computer Science project, which is designed to make it so that Johnny who lives next door (and, in particular, Sally, Jane, DeShawn, Rudjit, Liliana, Esteban, and Amira) never see the KEEP OUT sign in the first place.

In my first week in project classrooms, an eighth grader—let’s call him Jake—asked me if I went to MIT. Understandable, since App Inventor has MIT literally written all over it.

“No, I go to UMass Lowell.”

“Can you make apps?”

“We make all kinds of cool stuff! So can you.”

“Nah. I’m not smart.”

Inside, I hang my head. I show him a demo app I had made in the fall, as part of the teachers’ professional development. It has pictures of some planets whose buttons play audio files and change colors when you press them. It’s no Candy Crush, but Jake is visibly more interested in it than the text-to-speech button he’d just made.


“Of course you’re smart. You can totally make something like this.”

“I can’t. I told you—I’m not smart, I’m an athlete.”

“Athletes can’t be smart too?”

“Well, they don’t have to. I’m gonna play basketball in college, and all you really need to get in on an athletic scholarship is a C.”

Then I show him an app that another teacher had made—this one is similar in its functionality, but has pictures, text, and audio clips of different people talking about the Ferguson protests. His eyes widen. He takes the tablet from me and starts playing with the buttons.

“I know about this!”

I think at this point in his life, Jake is more excited about making a basketball game app designed to rack up mad points than a Ferguson app designed to provide social commentary. He’s thirteen, after all.

But that’s okay. When he played with the app, he saw people that looked like him. He didn’t see a KEEP OUT sign.

The next week, Jake was a little more engaged in the lesson. He got further than some other kids on that day’s tutorial, and even gave them pointers on fitting the blocks together. They went back and forth between their workstations, laughing at the sounds they could make the tablets produce, playfully chiding each other’s screwups, and peering at how the next kid fit her blocks together.

I think, overall, it’s going pretty well.

For more, see Kim’s blog at http://kmbrlynn.github.io/weblog.

Doing computing means embracing failure

We always tell ourselves and our students to take risks. But taking risks means that we will fail at things. And generally, none of us like to fail.

Think about what it’s like to write code. Most of the time, the code is broken, and you’re failing.

This semester, I’m watching my students struggle with assignments in our sophomore-level object-orientation in C++ programming class.

We’re working through a series of two-week projects. The projects are pretty fun:

(There are more—this material is from Princeton’s COS 126 course.)

From the students’ point of view, there are a lot of steps to get to a working system:

First, to understand the basic problem. What data structures will we use? How does the algorithm we’ll use work? How will it all be organized into objects?

Next, starting to write code. What goes in the header file? What goes in the source file? Why is there this separation anyway?

OK, I have some code. Let’s try compiling it. Oh great, tons of compile errors. Of course.

OK now it compiles. Does it work? Not a chance.

Well, time to debug… where do I start? Probably printing some stuff out… how about seeing that I can read the command line arguments properly?

And so on.

Probably the most challenging part is at the very beginning—making sense of the task itself, and how it’s to be accomplished.

I encourage my students to do their work in baby steps. Just write a few lines of code, compile it, and make sure it works.

Only add more code after you have a little bit of code working.

Compile and test before moving on. Make sure you are going from a working thing to the next working thing.

But even with this strategy, as soon as a bit of code is working, the next step is to add more code, which means breaking it again!

Most of the time, things are broken.

It takes a high tolerance for failure like this.

I do believe that we learn best when we encounter challenges.

And the beauty of our practice is that we’re so readily able to get feedback on the quality of our ideas. Since our ideas are expressed in machine-executable form, we can debug them.

But it is hard, emotionally demanding work, and it’s important that we recognize how much effort our students put in to accomplish their successes.

Terry Dash, a CS educator in Massachusetts, just described to me a teaching experience she had teaching Scratch to middle school students. Midway through the school year, her student Erica cried out during class, “Now I get it! The more it breaks, the more fun it is!”

That’s the spirit!

yours respectfully,
Fred Martin
CSTA University Representative

CSTA Funding Committee

Another of CSTA’s standing committees is the Funding Committee. Our charter is to support the initiatives of the CSTA, and help ensure the sustainability of our organization.

We keep an eye out for federal and other grant opportunities, and then we bring together groups of CSTA people and others to hash out the ideas and ultimately submit proposals.

A lot of the practical fund-raising work is also carried out in a continuous process by Lissa Clayborn, our acting executive director.

The Funding Committee is led by Fred Martin (chair) and Dave Reed (co-chair).

If you know of a grant opportunity that’s a fit for the CSTA, please let us know!

Fred Martin
University Representative

Teaching and learning with “gift code”

Last month I co-taught a two-and-a-half day workshop introducing students to building apps with MIT App Inventor. Some of our students had prior programming background, and others did not.

Here, our goal as teachers was to get our students engaged in their own original projects (rather than teaching any specific set of computing concepts).

I’ve done a bunch of workshops like this, with learners of all ages, and we’ve developed the concept of “gift code.” (Thanks, Michael Penta!)

With gift code, a student describes their idea to you, and you translate it back to them in the form of working code.

Ideally, gift code has the following properties:

  • It’s short. I’ll dictate the code and have the student type it in (or in the case of App Inventor, select and configure the code blocks). It really has to be small so neither of us gets impatient.
  • It works. The premise is that the student will understand the computational ideas in the code by seeing them work. Often the code will combine a bunch of concepts together—ideas that would be hard to explain individually, but make sense when combined into a working unit.
  • It’s the student’s idea. This is pretty important—the code should embody the student’s idea! But it’s OK to simplify what they said, as long as it demonstrates the essence of what they wanted.
  • It’s extensible. This is crucial. In a few minutes, I’m going to walk away and work with another student, and I want my student now to understand enough so that they can keep going. It’s fine if their next step is a copy-paste of the same code structure—e.g., adding a new condition-action rule.

It’s really fun when it works. Students are empowered because they can get complex things working quickly.

In the best case, an hour after receiving gift code, a student has full ownership over it. They understand it, they have added to it, and they don’t even remember that I gave it to them. (That’s totally fine with me.)

Do you use gift code in your own teaching?

Fred Martin
CSTA University Faculty Representative

CS Ed Week != Hour of Code


With the fabulous success of Hour of Code last year, I think many of us have fallen into thinking that Computer Science Education Week (CS Ed Week) is “Hour of Code week.”

As in, “What are you doing for Hour of Code?”… I actually heard myself saying that to someone.

But of course CS Ed Week is much more than introducing your students to a coding lesson.

Teachers who I know are: showcasing their students’ project work, organizing a hackathon to benefit a charitable organization, sharing their year-long curricula with parents and colleagues, and screening films about famous computer scientists.

By the way, did you know that CS Ed Week is the week that it is because Grace Hopper was born on December 9 (1906)? I just learned this.

At my university, it’s finals week. So my students will be taking finals in my two computing courses. (This seems to happen every year.) But in the prior week, they’ll be showing off their final projects to the whole department!

For more resources and ideas, go to csedweek.org/csteacher to download a “Participation Kit for Computer Science Teachers” and list your activities on an international map.

So… “What are you doing for Computer Science Education Week?”

P.S. The languages I’m using most at the moment are Scheme and App Inventor. Below is this post’s title in those languages. Both evaluate to true.

Scheme / Racket / Lisp
(not (equal? 'cs-ed-week 'hour-of-code))

MIT App Inventor


Real Programmers Use Blocks – A new definition of who is a programmer

In the last few years, blocks-based programming environments have become quite popular. This wave of popularity has been heralded by Scratch, but there are many such systems presently in use, including Starlogo and Net Logo, MIT App Inventor, and the Blockly-based tutorials developed by Code.org.

Probably you and your students use one — or more — of these coding environments.

But chances are you’ve also gotten the question, “Yes, but what is the real language behind the blocks?” when you’ve introduced these systems to your students, or shown them to parents.

Or maybe you’ve been asked, “When will we learn real programming?”

Perhaps even you think blocks-based programming isn’t “real” programming.

In other words — many people think that “Real programmers don’t use blocks.”

This perception is a serious concern.

Colleen Lewis published an interesting study related to this in 2010. She assembled a group of 6th grade students with little background in computing. She randomly assigned them to one of two groups: a text group using Logo Microworlds and a blocks group using MIT Scratch. Both groups were given structurally equivalent teaching and project work.

After a week of instruction, Lewis gave them attitude surveys and a coding assessment.

In analyzing the data, she discovered two things:

(1) The kids working with blocks showed a better grasp of conditionals, and otherwise learned essentially the same coding skills as those in the text-language first group.

(2) The kids working with the text language identified themselves more strongly as  programmers.

It’s ironic. Even though the blocks-programmers were equally competent coders, the text-programmers were more inclined to think of themselves as  computer scientists!

Even kids believe that text-programming is more “real” than blocks-programming.

It’s true that many blocks-based programming environments were developed for beginners. So it’s also reasonable to think “blocks programming is for beginners.”

It’s also true that most programming tools used by professionals are text-based environments.

Let’s take a look at how these programming environments really work. In block-based environments, you can “see all the pieces,” so it’s generally easier to discover what commands and operations are possible. Colors help you logically group operations, and  block shapes allow blocks to fit together only if they “work together.” This means that only syntactically correct programs can be assembled.

But the blocks themselves don’t help you write a logically correct program. That’s still up to you. In this sense, programming is still hard — a genuine intellectual challenge.

It turns out that there are three big things you often get in blocks-based environments. You get:

(1) Easy access to powerful APIs. For example, in Scratch, you can easily make a sprite glide across the screen, have it change direction, and have it change its appearance; in App Inventor, you can query a web database or send a text message with just a single command.

(2) Easy-to-use, yet sophisticated, control structures, such as event handling. With Scratch, you can have multiple sprites moving simultaneously, and have them send messages to each other. In App Inventor, you can easily make a link between pressing a button on the screen and initiating an action (like playing a sound). In typical text languages, either of these things would require many complex lines of code. In App Inventor, all computation is initiated by event-handler blocks that respond to events like touching a button, changing location, or receiving a text message. Everyday real-world programs depend on these sorts of features, but they are not easy to express in traditional languages.

(3) The ability to build real programs and put them in the hands of users. A big aspect of Scratch’s success is the Scratch web site and sharing gallery, which makes it easy for kids to share their work with each other. Likewise, when building apps with App Inventor, people make real apps for mobile devices and can distribute them to people.

It’s worth noting that there’s nothing special about blocks in these three big ideas! Rather, it’s that the people who have developed these blocks-based systems focus on empowering programmers — giving them the tools that let them make real things.

Blocks environments strive to make easy the things that should be easy. But building something real that gets used by others is still hard. You have to build something that’s interesting, fun, and/or useful, pay attention to details, and solve problems along the way.

So, who is a programmer? We invite all to embrace what we believe:

“Real programmers make programs that matter to real people.”

By this definition, real programmers definitely use blocks.

Hal Abelson
Lawrence Baldwin
Mark Friedman
Derrell Lipman
Josh Sheldon
Mark Sherman
Fred Martin
Ralph Morelli
Eni Mustafaraj
Shay Pokress
Franklyn Turbak
Dave Wolber

Submitted by Fred Martin, University Faculty Rep., CSTA Board of Directors

A first post from Fred Martin, your new University Representative

Dear CSTA members,

I am delighted and honored to be elected for a 2-year term to the CSTA board, which began this July.

I was with all of you who attended the annual conference in St. Charles this summer. Then I stayed the rest of the week for the CS Principles Summit and the board meeting.

As others have described on this blog, the annual conference was inspiring. Among all of the great sessions, one stood out for me. Floresa Vaughn (a math teacher) and Marisa Brown (a science teacher) led a conversation where they described using Bootstrap to teach mathematics to high school students.

When she introduced herself, Ms. Vaughn made sure we knew that she considered herself a math teacher, not a computer science teacher. Her interest in Bootstrap was exactly because it taught math, not computer science. As she described, statements in Bootstrap look like mathematical relationships, not variable assignments.

But also, Ms. Vaughn was thrilled by the idea of making her own video game. This was exciting, and Bootstrap would let her do it!

The two teachers work in a continuation school in Los Angeles, which is a school for 16 to 18 year old students who weren’t successful in regular high schools and are at risk for dropping out.

Floresa and Marisa work with students who have struggled with school, and particularly math. After learning about Bootstrap, and because “trying the same thing over and over and expecting different results is the definition of insanity” (their own words!), they felt empowered to try Bootstrap.

Working together, Ms. Vaughn and Ms. Brown taught a new special course based on the Bootstrap curriculum. As they described, they succeeded in helping their students discover that they have the ability to do math. And that they could even enjoy it. And they could make video games! (See more in their article in the CSTA Voice September 2014 issue.)

The teachers showed a video from their students’ final presentations, where one of the students presented her video game. They gently guided their student in discussing the mathematical properties of her game, and when she succinctly explained the ideas, the whole classroom audience cheered her success.

The video captured the teaching and learning that Ms. Vaughn, Ms. Brown, and their students accomplished that semester.

It also revealed the deep commitment that the teachers have to their students’ learning.

It was especially poignant because of Ms. Brown and Ms. Vaughn’s unwavering will to find a way of reaching students who didn’t have a lot of prior success in school.

To me, there are two lessons from this story:

First, being creative with computing is really different from other endeavors. People like making things and computing lets us make things that are relevant in today’s world (like video games). There are a lot of children (and grown-ups) who find joy and pleasure in making something that really works. There aren’t many experiences like this in the traditional K-12 environment.

Second, it all happens because of the deep commitment to your students’ learning—and your own learning—from teachers like you.

Thank you for all of your work, and I look forward to being part of your community over the next two years.

Fred Martin
CSTA University Representative