About Fred Martin

Fred Martin is a faculty member at the University of Massachusetts Lowell, where he is associate dean for teaching, learning, and undergraduate studies in the Kennedy College of Sciences and professor of computer science. He has been serving on the board of CSTA since 2014, and is past-chair of CSTA's Board of Directors.

Doing computing means embracing failure

Posted on March 20, 2015 by Fred Martin

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:

using recursion to draw Sierpinksi’s triangle (and creating a derived object that’s “drawable” using a gaming graphics library)

building a pseudo-random number generator using a linear feedback shift register, and then using this to encode (and decode) an image

simulating the movements of planets in the solar system (using Newton’s fundamental laws of gravity and acceleration)

(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

Posted on March 18, 2015 by Fred Martin

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!

Yours,
Fred Martin
University Representative

Teaching and learning with “gift code”

Posted on February 3, 2015 by Fred Martin

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

Image

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

Posted on October 28, 2014 by Fred Martin

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

Posted on August 21, 2014 by Fred Martin

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

The CSTA Advocate Blog

Author Archives: Fred Martin