Last week I jumped into using Scratch with my 10th grade class. I had an idea for the Logo-like task of drawing a square (and other regular polygons) that I got from CS Ed Day. It worked well there as an introduction, so I decided to start with that. Then I needed more ideas for the rest of the week, so I took a look at the ScratchEd site and found my way to the Exploring Computer Science (ECS) curriculum.
I didn’t have time to read their entire philosophy statement, so I skipped straight to the example files and lesson ideas. John Landa (a teacher at South East High School in Los Angeles) contributed a whole set of Scratch files, including one I chose to use that gives the students a baseball diamond and asks them to animate the cat running the bases.
I thought, given the Giants World Series win just a couple months ago, this would be a fun way to have the students learn more about the blocks (commands) that control movement and appearance. And my students came up with a whole bunch of creative solutions to the problem.
Some of them work better than others. The solution that comes with the ECS curriculum guide looks like this:
There are two subtly tricky aspects to this solution. One is that it uses multiple threads: the first one controls the position of the sprite (moving it around the bases), and the second one controls its appearance (changing costume every half second to animate it).
Why did we need two threads? This is a reasonable question, and the answer is that the “glide” command is blocking, meaning that it prevents the execution of the next command until it finishes its work. If we want anything else to happen during the glide, we need to put that in a different thread. That’s a reasonable answer, cool to discuss with students as they solve the problem, and really cool that Scratch allows it.
The other trick is that the sprite’s rotation style needs to be set such that it will only face left or right (as opposed to the other options: free rotation or no rotation). I’m not sure why the designers of Scratch thought it was better to have a special interface option instead of creating a block that flips the costume, but here we are.
Knowing all that, consider this alternative solution developed by one of my students:
He avoided the confusing left-right flip / rotation issues by creating different costumes for the different directions (costumes 1 and 2 face right, costumes 3 and 4 face left). As a result, he also needed some coordination between the movement thread and the costume-change thread. Through trial and error he came up with values that worked, but as you can see it was essentially a race condition. And when he shared it online, the timing worked differently in the browser than it did on the desktop app. You couldn’t really ask for a better illustration to show why relying on timing to coordinate execution between threads is fragile.
This assignment opened the door to some advanced topics pretty quickly. I have to admit that I didn’t know the first week of Scratch would lead to us talking about concurrent computing. That’s exciting for me. I’ve wondered in the past if we’re teaching the right languages, and maybe this is part of the answer. Without being bogged down in lots of syntax or drifting away into abstract thoughts, we have access to sophisticated programming concepts.
Today in class I let the students watch me struggle with different ways to deal with the rotation / flip problem, partly to affirm that there are multiple valid solutions, partly to share some secret tips with them, partly to model the iterative process of solving a problem, and partly to introduce the broadcast blocks. It felt really natural to teach the concept of events and event handling as a result of what we just looked at. And who knows where that will lead next? I’m happy that I’ve started on this new adventure with my students.