Learnable Processing Programming: Part One

Brett Victor recently posted an intriguing essay entitled Learnable Programming. I’ve been a fan of many of his essays (e.g., [1] and [2]). Victor is quite a pioneer of what we might refer to as design-based computing pedagogy as opposed to a programming or assessment driven pedagogy. And this essay surely lives up to his previous work; I think I could write fifty blog posts reacting to this single essay. T-49 …

Pedagogical Processing

I use Processing in my introductory computing class at Bard. This semester is my third iteration of the class. I chose Processing for a variety of reasons, some of which overlap:

  • Processing allows artists and designers to write real code with relatively little pain.
  • Processing balances developing powerful programmed artifacts with a relatively simple programming interface.
  • Processing has a welcoming, productive open-source community.
  • A ton of libraries and examples help students write relevant, meaningful sketches (e.g. with video, images, sounds, etc.)

Although I agree with almost all of Victor’s points concerning pedagogical programming environments and with Processing’s downsides (e.g. the lack of modularity, it’s manic reliance on an imperative style, the bad genes inherited from Java or Javascript), I disagree with his implication that it is unsuitable for learning programming. Victor claims that programming environments should aim:

  • to support and encourage powerful ways of thinking
  • to enable programmers to see and understand the execution of their programs

These two goals are important. But they aren’t the whole story. If that were the case, his cited cases of smalltalk, hypercard and logo would still be popular. Sadly computing is not only driven by pedagogy, but also pragmatic concerns. Our students want to write real programs. Programs that run in browsers, run at 60 frames per second, and connect to webcams. And although we should always strive to develop new pedagogical environments that do all of these things, reality is reality.

And within these pragmatic concerns, I would argue that Processing can indeed meet Victor’s two stated goals, if used properly from a pedagogical point of view.

  • Processing, especially when compared to Photoshop, Gimp, iMovie, and Illustrator supports and encourages powerful ways of thinking
  • The graphical elements available in Processing enable programmers to see and understand the execution of their programs

Although certain Processing programs aren’t easily understood using its graphical elements, such programs will always exists. There will always be programs that defy 2D, 3D, or 4D visualization. That said, we can use Processing’s graphical approach as a powerful way to make a program less opaque. For example by avoiding loops in the first four or fives weeks, I’ve found Processing’s graphical elements capable of visualizing variables, expressions, function calls, and conditionals. The following sketchpad.cc example is an example:

It is our job as computing educators to discover or invent programs that elucidate the underlying programming concepts in the most effective way. Some programming environments make this difficult, others make this a joy. I’ve found Processing to be mostly a joy. This is not to say we shouldn’t invent better programming environments, of course we should (and I am). Visualizing the internal states of our programs is important, but it is not the silver bullet.

Leave a Reply

Your email address will not be published. Required fields are marked *