Goals, Plans and Code

In a previous post, I discussed the idea that experts do not construct a program by reasoning line-by-line, but rather program from templates in memory. This is not a new model, and was explored in the 1980s by Elliot Soloway and various co-authors in a few papers. In this post, I’ll look at that work, and discuss what happened to it.

Goals and Plans

In an article in Communications of the ACM in 1986, “Learning To Program = Learning To Construct Mechanisms and Explanations”, Soloway talked about plans: small program skeletons that expert programmers have learnt, such as looping until a particular (“sentinel”) value is encountered. He discusses how a lot of the problems that programmers run into (after they have grasped the basic syntax and semantics of a knowledge, something he dismisses as fairly easy) is knowing these plans and being able to merge them. Soloway suggests that many bugs arise from incorrect merging of these plans. Implicitly, the research into plans focuses on intermediate and expert programmers. Novices have not yet learnt these plans, so this idea of plans and merging them does not apply to novices.

Where did this model go?

Soloway’s model seems reasonable. However, as far as I can tell — but I may be wrong — there was not much more work continuing down this line of thinking about plans and merging plans. If I was to speculate as to why, I think a major difficulty in this work is cataloguing all the plans — which seems like a mammoth task. There are all sorts of issues, such as the sheer number of plans, the plans being specific to a programming paradigm, deciding the level of abstraction at which the plans should sit and so on. For example, Soloway has the “sentinel-controlled running loop plan” — in Java this is roughly:

int sum = 0;
data = read();
while (data != sentinel)
    sum += data;
    data = read();

Soloway also refers to the “sentinel-controlled counter loop plan” — in Java this might look like:

int counter = 0;
data = read();
while (data != sentinel)
    counter += 1;
    data = read();

If I was classifying the plans, I would say that each of these is already a compound plan, with the underlying plans being “sentinel-controlled loop” and then “running-total loop” or “counter loop”. Can you imagine making these kinds of decisions and classifications for hundreds or thousands of programming plans? Not to mention the isomorphic possibilities for implementing the sentinel-controlled loop: involving do/while (aka repeat-until) loops, having a break in the loop, having an if condition in the loop and so on.

On top of this, Soloway was working in Pascal. In modern terms, Pascal is a very small language. No objects, no first-class functions, no generic programming, little pointer use — each of these additions would add a whole slew of further plans. A programming language may have, say, fifty different source constructs, but these can be combined in so many ways that I suspect the number of plans is well into the hundreds, if not thousands. It seems quite impressive that programmers will have memorised them all, but cataloguing them is much more work. We all know most of the words in a dictionary, but the effort required to write that dictionary is phenomenal.

From model to pedagogy

So, we have this model of expert programmers using learnt plans and merging these plans to create programs. Soloway suggested that not only should this be a model to understand expert programming and its mistakes, but that we should also use this model as a way to teach programmers:

[Expert programmers] have built up large libraries of stereotypical solutions to problems as well as strategies for coordinating and composing them. Students should be taught explicitly about these libraries and strategies for using them.

One frequent pedagogical question seems to be: experts do X — should we therefore explicitly teach students to do X as well? And at what stage of their learning? Going back to the dictionary analogy, we don’t teach students by going through the dictionary, we instead learn language through seeing it in its natural context. The end point might be to effectively embed the contents of the dictionary into their head, but that doesn’t mean we teach from the dictionary to do so.

The plans remind me of design patterns, which I’ve always thought are useful as an after-the-fact classification to give names to things people use. But surely no-one uses design patterns by thinking “hmmm, what do I need here?” and going to a giant book on the shelf and thumbing through for the pattern they need. Experts tend to know the pattern already and just use it. If you don’t know the plan, you’re surely as fast engineering it through programming, rather than by reading a giant list of plans until you are sure that you have found the right plan you need (from a list of hundreds or thousands). Via a later review paper by Guzdial, here is a screenshot of a “Goal-Plan-Code” system that Soloway and others designed:

The GPCeditor interface, as shown in this review paper by Mark Guzdial.  Click for larger image.
The GPCeditor interface, as shown in this review paper by Mark Guzdial. Click for larger image.

This is a bit artificial, because it’s trying to show all the features in one screenshot. But I believe that even a pared down version would be too complex to use effectively. The problem with the plan catalogue is that as I said above, even if it is usefully sorted, I think it would take too long to find the right plan. The problem with the decomposition view is that I worry it does not add knowledge in a way that will be accessible enough. The extra effort in relating the decomposition view to the composition view seems like it would be too much to gain a benefit. I believe this is probably why this kind of interface never caught on. (A 1998 paper by Guzdial et al showed some positive results for using GPCeditor, but on a small cohort with no control group.)


Plans seem like a potentially useful device for understanding how experts think about programming. However, it’s not clear to me from Soloway’s work that they translate into a useful teaching device. Where I think they may remain interesting is in the study of intermediate mistakes. A lot of programming education seems disproportionately focused on the early end of programming — syntax mistakes and so on — probably because it’s the easiest area to analyse. But there are a lot of fascinating problems in learning to be found in intermediate-level programming, and this goal-merging work still seems like an interesting avenue to understand the mistakes of intermediate programmers. I think the difficulties lie in forming a catalogue of the plans, and in trying to create analysis techniques to relate student mistakes to these models in a systematic fashion.


5 thoughts on “Goals, Plans and Code

  1. Neil, I believe that by identifying at least a subset of the plans we can begin to define “what” can (and should) be taught to beginners. There’s a reason that expert programmers learn a set of plans: because they’re used repeatedly. Just as we teach common vocabulary first to beginning readers, we should teach the most common plans to beginning programmers. It would be another effort to create a common curriculum regardless of language, objects first/middle/last, etc. So while I agree that cataloging *all* plans seems like an enormous effort, defining the most commonly used plans might actually be quite useful.

    1. Thanks for your comment. That’s true, we don’t necessarily need all (or most) of the plans. One thing I’ve heard mentioned in the past is the idea of flash-cards with common programming “recipes” on them (e.g. for how to do scores in Scratch), so maybe a similar technique could be used for common programming plans.

  2. Hi Neil,
    a slightly more light weight approach is possibly to explicitly teach students about variable roles. Roles include “fixed value” for those languages that don’t have a constant keyword. “Stepper” for a variable that holds a predictable sequence of values and so on.

    The variable roles website lists all of the relevant research related to the impact of explicitly teaching these as well as a whole host of examples and explanations of the different roles that a variable can perform.

    The website is http://cs.joensuu.fi/~saja/var_roles/ as well as being a resource on the CAS online community site.

  3. I was about to add a pointer to Sajaniemi’s work on variable roles as well – I use those terms a lot when I’m teaching. Regarding the difficulty of cataloging hundreds of patterns or plans, I think that’s a chicken-and-egg problem: I learned different kinds of electronic circuits as an undergrad because engineering considers design and analysis first-class citizens. If software analysis and code review were a first-class subject in the CS curriculum, I expect that our catalog would take shape quickly and naturally.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s