Reading Academic Literature – #2



The Int. J. of Human Computer Studies specifically require the abstract to: “state briefly the purpose of the research, the principal results and major conclusions”. And in RES 701, Clare has told us an abstract should: tell you three things   “a) what the research topic is  b) what the authors/researchers did and   c) what they discovered.” (Clare Aitkens,

Below, is the abstract in full:

Programming may be more di$cult than necessary because it requires solutions to be expressed in ways that are not familiar or natural for beginners. To identify what is natural, this article examines the ways that non-programmers express solutions to problems that were chosen to be representative of common programming tasks. The vocabulary and structure in these solutions is compared with the vocabulary and structure in modern programming languages,to identify the features and paradigms that seem to match these natural tendencies as well as those that do not. This information can be used by the designers of future programming languages to guide the selection and generation of language features. This design technique can result in languages that are easier to learn and use, because the languages will better match beginners’ existing problem-solving abilities.

(Pane et. al., 2001)

  • the need (why they are conducting the research, )
    • The authors suggest that programming may be unnecessarily difficult, due to the need to adhere to strict syntax and structures peculiar to the programming language. It has been suggested that these structures may not accurately reflect the way in which nonprogrammers naturally approach a subject
  • the what (what they are examining and roughly their planned research methods)
    • this research is a step towards defining what is “natural” to nonprogrammers by creating controlled problems to be solved by nonprogrammers. Based on existing research, Pane et al took considerable care to design test-cases that did not lead the participants in any particular direction, or enforce a single ‘optimal’ approach.
  • the outcome
    • here, Pane et al only hint at their results, suggesting that there may be results that could be used in designing future programming languages / interfaces. Beyond this, Pane et al do not elaborate or draw any further conclusions in the abstract.

My summary:

The Natural Programming group (Carnegie Mellon) have undergone extensive research in the attempt to create a more intuitive programming interface for beginners and nonprogrammers based on the observation: that programming is a difficult and specialised field but that “programming languages make the task more difficult than necessary because they have been designed without careful attention to human-computer interaction issues” (Newell & Card, 1985). pane et al address a specific sub-area, namely how nonprogrammers structure and express their solutions to programming problems.

Experiments were conducted where participants were given programming tasks that highlighted a number of programming concepts, including: Boolean logic, variable assignment, arithmetic, iteration etc. The test problems were related to scenarios in the PacMan game. Pane et al observed that previous studies were flawed and the experimental design were biased and influenced the participant’s answers. In this study, considerable care was taken to provide enough information, but remain suitably vague so as not to bias the results. To compare the results, a second scenario involving database query was also used.


Pane et al conclude that participant’s solutions would not map particularly well into existing programming structures. On the whole, the solutions were not thoroughly described and sometimes imprecise. However, the structure and algorithms described in the ‘natural solutions’ did satisfy the problem, but were just in an informal style. Pane et al suggest that future programming languages may benefit by supporting multiple programming styles, especially event-driven styles and consider alternatives to Boolean logic and iterative control structures.

My two cents:

As a beginner programmer, I can relate to some of the findings in this article. In particular, I can relate to the suggestion to ” aggregate data access through set creation and manipulation” as opposed to iterative or recursive loops. All ‘beginner; programming classes spend considerable time on iteration, and I believe this is because it is inherently odd. In my mind, it is easier to think “add 5 to everything” than it is to think:

int my_array[5] = {1, 2, 3, 4, 5};
for (int i=0; i < len(my_array); i++):
    my_array[i] = my_array[i] + 5;

This is one of the key shifts in thinking that you need to undergo as a programmer.  (baaha, yes I have deliberately chosen C over a less complicated-looking language :p)

I was particularly interested in the findings around programming style (i.e. event-drive cf. OO). Procedural programming is very linear, do ‘x’, then ‘y’ and get ‘z’. I imagine it is easy to teach, and probably why most beginner classes start here – but you have to ‘think computer’. Contrast this with event-driven programming, and you get a more ‘everyday’ type of flow, there is state and action-reaction. Retrospectively, if I had been exposed to event-driven programming earlier I would have taken to it quite naturally.

The concepts of OO are simple and appealing (well, if they are presented with an analogy you can identify with) BUT, they are also quite abstract! It was very interesting to see that OO concepts of inheritance and polymorphism were not observed in the natural solutions.

Functional programming was not really discussed in the article. I have a feeling this might be more ‘me’ and will look forward to trying my hand at this later this year. I wonder if functional programming will be more ‘natural’?

For me the most compelling statement made by Pane et al was:

A large part of the programming task is to take a mental plan for solving a problem and transform it into the particular programming language being used. These studies attempt to capture these plans before they undergo the transformation into a programming language.

This is the CREATIVE art of programming! Circumvent the syntax, structure and rules and programming really does become an artform 🙂


3 thoughts on “Reading Academic Literature – #2

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s