CS Ed Day
I took my 11th grade students to UC Berkeley today, for the Computer Science Education Day, hosted by Dr. Dan Garcia and the Berkeley Computer Science Department as part of the national Computer Science Education Week.
In addition to the great demos from undergrads in Dan’s new CS10 course, there was a standout presentation on AI from professor Dan Klein. His Overmind Project tackles a bunch of difficult tasks, and the fact that they are cast in terms of the video game StarCraft made it extremely interesting and accessible to a large number of my students.
Then we had two hands-on sessions: First, we played the programming game Light-Bot which is an example of the sort of abstract-thinking-and-logic-developing games I’ve written about before. While the students worked up through the levels, Glenn Sugden talked up BYOB to me. A Berkeley enhancement to Scratch, BYOB extends that environment to allow user-defined blocks. He showed me how this enables recursion by writing factorial, then I wrote Fibonacci to get a feel for it.
Then the class moved to a new lab and sat down with BYOB. As I watched my students tackle the challenge of creating a set of instructions for drawing a square, I had a bit of a breakthrough. In the past I’ve been pretty openly biased against tools like Scratch and Alice, since it didn’t seem like they reduced any of the cognitive load of learning, say, conditional execution or loops. And yet they require laborious clicking and dragging within a set of graphical metaphors that students will never see anywhere else.
All that is still true. But what I hadn’t realized is that the cumbersome nature of the drag-and-drop programming buys you a benefit: it’s much harder to botch the syntax. There’s no such thing as a missing semicolon or unclosed curly brace. Now that I focus my thoughts on the problem of tiny syntax errors, I can recall numerous times where a student has tried an idea, ran into what I would see as minor errors, and falsely concluded that their whole idea was no good. Then they ask for help and I lead them back to their original idea, only to learn that they’ve already had the important conceptual insight. That experience is frustrating for both of us and undermines both their confidence and their development of a consistent model of how a language expresses computation. Using a visual programming environment seems to help avoid this problem.
On the other hand, they’re going to have to move out of that graphical world sooner or later. Previously I had judged this transition as expensive and the knowledge transfer as low. But it could also be seen as a way to spread out the cognitive load of learning to program: First you learn some general algorithmic concepts and ideas about abstraction. Then, with that confidence and vocabulary under your fingers, you move on to a more powerful and sensitive tool like a text editor. Structured well, a lot of concepts can transfer directly.
Seeing BYOB in action, I got a gut sense that the overhead for new students to start using it would be relatively low. They could do it for as little as a few weeks or as much as a few months before moving to another environment. And in the transition, there’s an opportunity for them to talk in more abstract terms and reflect upon how they think about programming. This might bring some of the benefits of learning multiple languages for a much lower cost.
Speculation aside, this was an important step for me in understanding how to face the challenge of opening up computer science to more students. The fully graphical tools do have a place for the students who are just starting down the path of learning about programming. I can honestly say that everyone learned something at CS Ed Day.