Blocks as a Gateway
Since starting work on Madeup, I’ve been trying to read everything I can on procedural design. My most recent discovery is John Maeda’s Design by Numbers. The author makes it his mission to teach programming principles by drawing on a 100×100-pixel canvas with a very simple language called DBN. In chapter 6 of his book, which discusses iteration, Maeda makes this statement:
Before a Repeat can be introduced, the concept of a block of code must be discussed. Organizing your program into blocks serves a purpose similar to adding comments in the sense that blocks establish clarity within a program. The key difference is that a block is also a meaningful structural entity in a program.
Like C and Java, blocks in DBN are sandwiched between curly braces. I rarely, if ever, use standalone blocks when I program. Even less do I teach them to my students. However, Maeda’s comment makes me wonder if discussing blocks before functions and control flow might be a good idea. I can see it having the following positive outcomes:
- Students see the notion of chunking code into logical units for pure organizational purposes. Usually we discuss program organization at the same time as functions, the mechanics of which are more difficult and distracting.
- Students see very early in the semester the importance of indenting their code to see structure of multileveled algorithms.
- Students see how data flows in and out of blocks—or doesn’t, in the case of local variables—without at the same time trying to understand conditional logic. This would serve a useful counterpoint when we eventually introduce functions.
Of course, introducing standalone might have no impact at all. Talk to me next September, when I teach our CS1 again.