a study of learning to program from an experiential perspective

Computers in Human Behavior, Vol. 9. pp. 185-202, 1993 Printed in the U.S.A. All rights reserved.

0747.5632/93 56.00 + .OO Copyright 0 1993 Pergamon Press Ltd.

A Study of Learning to Program From an Experiential Perspective

Shirley Booth

University of Gothenburg

Abstract - Part of a study investigating aspects of learning to program a computer, from an experiential perspective, is described. A group of computer science and computer engineering undergraduates were followed for a half-year while they took an introductory course in programming, first using Standard Meta- Language @ML), a functional language, then Pascal. Six interviews were held during that period, touching on broad themes recurrently and specific technical aspects of programming and the languages more topically. In addition, textbook problems were posed both to uncover conceptions of technical content and to investigate approaches to problem-solving. The overall aim is to study learning to program as a complex learning activity, in order to illuminate the didactic issues involved in planning, implementing, and evaluating programming education.

The research is in the phenomenographic tradition; the central phenomena of programming have been analysed in terms of qualitatively distinct conceptions identified among the students. This article describes and discusses four alternative conceptions of programming languages found - code, utility, medium of communication, and medium of expression - in detail, and conceptions of programming - computer, problem, and product orientations - and the computer - tool, facilitator, machine, and universal engine - in summary. Learning is discussed as the development of interphenomenal and intraphenomenal relationships.

Programming and learning to program have become increasingly common subjects of study, from a number of different perspectives and with accordingly different goals. The overall perspectives include those of computer science, cognitive science, psychology, ergonomics, and that which is the primary concern of this study, education. Goals are shared across these disciplinary boundaries, and include the ergonomist’s and the computer scientist’s broadly pragmatic aims of improving the programming environment with regard to the design of programming languages, interfaces, and program development tools, as well as the ways in which these are

Requests for reprints should be addressed to the author at Department of Education and Educational Research, University of Gothenburg, S 431 26 M(ilnda1, Sweden.

185

186 Booth

integrated into the workplace and work method (see e.g., Krasner, Curtis, & Iscoe, 1987). The research of the cognitive scientist and the psychologist tends towards using programming as an example of the use of cognitive skills in general, whether problem-solving, learning, or correcting mistakes, with the prime aim of develop ing or confirming theories of cognition in terms of representation and manipulation of knowledge (see e.g., Andersson’s work on students learning LISP in connection with his ACT* model of cognition and the acquisition of cognitive skills - Andersson, 1982; Andersson, Pirolli, & Farrell, 1988).

Research into learning to program within the field of education has had two main foci. The first is that of programming in Logo (Papert, 1980), the programming language devised specifically to provide young children with a rich environment for the development of cognitive skills, and the second concerns the devetop- ment of good methods of programming instruction. In the case of Logo, research has included case studies of the development of infants given a free hand with the spatially interesting graphics aspect of Logo (Lawler, 1985), studies of the development of classes with intensive computer usage in various contexts (Pea, 1986), and the development of specific mathematical and programming ideas (e.g., Fay & Mayer, 1987; Kurland & Pea, 1985). In the more general sphere, research has looked at the effects of individual differences on learning to program for students in various age ranges (e.g., Kagan & Douthat, 1985), instruction for effectuating the transfer of problem-solving skills from specific teaching in programming to other areas such as physics or radically different programming environments (e.g., Linn, 1985), and the effects of the use of concrete representations of the computer in conjunction with instruction of different content (e.g., Mayer, 1981).

There are a number of review articles and books (e.g., Booth, 1987; Hoc, Green, Samursay, & Gilmore, 1990) on the field of research into learning to program. The subjects mentioned above serve as a background to the study to be presented here that is rather different in conception and research methodology. The research aim is to describe the experience of learning to program, learning from the point of view of the learner, in a phenomenological, specifically phenomenographic, tradition (Marton, 1986).

METHOD

The Subjects of the Study

The study is of undergraduates learning to program, first in the very high-level, functional programming language called Standard Meta-Language (SML), and then in Pascal. They were in their first year of study of a 4 l/2-year degree course in computer science and computer engineering at a Swedish university of technology. The degree program is intended to educate computer professionals in the broad range of computer engineering, and this course was the first of a number of obliga- tory and optional courses on software design and production, studied in parallel with ma~ematics, physics, and electrical enginee~ng, as well as hardware design and production.

The first of the two languages, SML, is a functional programming language, with its roots in the branch of mathematics called lambda calculus; this means that programs are written as functions in the strict mathematical sense of returning only one result, and causing no side effects. Thus, the correctness of a program written

Learning to program 187

in strict SML is mathematically provable rather than dependent on validation by testing. To the extent to which a program can be written in strict SML, the program is a formal expression of the specification. It was chosen as first programming language partly to stress the specification of programs (Wikstrom, 1986). Other claims for teaching a functional language first are that they are more problem-oriented than conventional languages so that the jump from a formal specification to a functional program is much shorter and easier, and that functional programs are gener- ally shorter than their conventional counterparts and thus easier to enhance and maintain (Glaser, Hankin, & Till, 1984).

The work is based on an intensive study of a group of 14 university students during their first year of studies towards a degree in computer science and computer engineering, who were interviewed closely on six occasions over the 5 months the course lasted. A number of second-year students were also interviewed once. The semistructured and basically open interviews covered a wide range of aspects of programming, from the most general to the specific constructs of the languages involved, and went into the ways in which the students studied, approached writing programs, and experienced their learning.

The subjects, selected from the 120 students on the course, indicated their will- ingness to take part in the study according to their response to a questionnaire. (The questionnaire was administered by their teacher before their formal studies began, in order to get an idea of their educational, work, and programming backgrounds; university students in Sweden tend to have diverse backgrounds, because school education can be complemented by adult education to provide acceptable qualifications, men commonly complete their military service before starting higher education, and it is normal to work for a time after school in order to satisfy the stringent entrance qualifications for professional studies.) In the first place, 15 were chosen to represent roughly the composition of the whole group, according to educational and work background and gender, but 1 changed study program after a few weeks, leaving 14. There were 2 women and 12 men, ranging in age from 19 to 31, and with programming experience varying from none to considerable - the latter having learned as hobbyists, at school, or in the workplace.

The Phenomenographic Research Approach

The phenomenographic tradition offers a radically different approach to research in the area of programming compared with the studies mentioned earlier in that it aims in the first instance to describe rigorously the experience of learning - that is to say, learning from the point of view of the learners themselves - rather than to bring theory to bear on the observations. Such research does not try or intend to present objective measures of learning, in terms of exam grades or theories or hypothesis confirmation. It presents instead descriptive categories that attempt to catch the essence of, and the essential differences in, the ways in which things or concepts or events are understood or experienced. In the second place, such research results can be brought to bear on relevant aspects of the instruction by providing the teachers with greater insight into their students’ learning than are otherwise to be found.

The phenomenographic approach to research has implications for the collection, analysis, and presentation of results. The main method of collecting data is through interviews that give the subjects room to express their ideas on the points of interest to the researcher. Thus, a typical interview will have an outline structure but will also allow for diversions and deviations in order for the researcher to probe

188 Booth

more deeply into areas of promise, to follow interesting threads, and to attempt a variety of approaches to a topic. The balance of the interview is of importance in that the person being interviewed should have the opportunity to range freely over the area under discussion, but at the same time the interviewer has to steer it towards the areas in which he is most interested.

The following can be offered as an example of the open, phenomenographic interview style employed. One of the general and recurrent themes taken up was the nature of programming languages, and to uncover the students’ understanding of this one might simply ask them, “Now, I would like you to tell me what you think a programming language is.” But instead of such direct questions, which force the subject into making a considered response, indirect approaches were made to the theme, such as, “Why do you think there are so many programming languages?, ” “What do you think makes a good programming language?,” and “Tell me how programming in SML compares with programming in Pascal.” There, the phenomenon of “programming languages” is in focus, but the students are offered a number of ways of expressing their ideas about them, and at the same time the researcher is presented with a variety of aspects on the individual student’s delimitation of the phenomenon “programming language” and its meaning.

The interviews are transcribed and the researchers immerse themselves in them, reading them carefully, focussing on different themes of interest, being aware of all their data at the same time as they look at a single statement. The researchers look for similarities and differences in the subjects’ statements, and their understanding of the statements hovers in a state of uncertainty, looking for further implications of the original interview context and the context of the totality of interviews. One differentiates between the first-order perspective, from which the researcher takes a subject’s statement and measures it against some predetermined standard, and the second-order perspective, from which the researcher sees statements as reflecting the subject’s own understanding of the phenomenon in question. It is believed that, however illogical and inconsistent statements and actions appear from the first- order perspective, by adopting the second-order perspective and taking the position of the subject the researcher can find a consistent picture based on the understandings the subject holds. Thus the researcher must be open for alternative views of the world and its constituents, and all the time seek an interpretation of an interview that does justice to the subject.

The analysis process is essentially dialectical - the statement, the individual interview, the totality of interviews, all lend meaning to one another. The interviews have to be seen simultaneously as a whole, as taking up individual themes in certain sections, and as being permeated with references to the totality of themes of interest. To return to the example of seeking understandings of programming languages, at the same time as the students were focussing on programming languages, they were also exposing their ways of understanding programming itself. Certain statements get lifted into focus while the rest recede into the background, and this is a continuing experience until the whole makes sense in the way desired - that is, as a set of qualitatively distinct categories of understanding. When such a set of categories has been arrived at the data is reviewed anew in the light of them; thus the descriptions of the categories are refined successively until the researcher is satisfied that they do justice to the data.

The fundamental results of a phenomenographic study are careful descriptions of the categories found. The categories of understanding of a phenomenon are most often referred to as conceptions, which means the phenomenon as delimited from

L.earning to program 189

its context by a subject or group of subjects. These fundamental results can then be put to use as appropriate for the research context.

The Research Procedure

Interviews were held with each of the students on six occasions, investigating general themes recurrently - namely, programming itself, programming languages, learning to program, and the computer, as well as specifically topical aspects. The students were also asked to solve problems typical of those met in the course, partly to investigate conceptions of the programming constructs involved in the problems, and partly to look at approaches to problem-solving (specifically at approaches to writing programs). In addition, single interviews were held with 10 second-year students in which the general themes were touched upon and more advanced technical topics taken up.

A computer program developed in a Macintosh HyperCard environment was used in the early stages of analysis for handling text extracts from the transcribed interviews (Booth, 1990). Using this the researcher can take extracts from the transcrip- tions, categorize them roughly under theme headings, attach notes to them, flip to and fro between the extract and the context of the original interview, refine the themes, and ultimately sort and shuffle the extracts according to groups of themes.

The first and sixth interviews with the first-year students and the set with tbe second-year students have been analysed, and in the rest of the article the resulting categories of understanding, or conceptions of, programming, programming languages, and the computer will be presented.

RESULTS

This section is divided into three parts. In successive parts the categories of understanding found for the nature of programming languages, the nature of programming, and the nature of the computer will be presented in detail, followed by a discussion.

Conceptions of the Nature of Programming Languages

Discussions of programming languages take place throughout the interviews, either deliberately brought up as a topic for exploration, or incidentally in the context of other topics, as described earlier.

Four qualitatively distinct conceptions of the nature of programming languages have been identified, namely:

l Programming languages as a code, in which the language is seen as a set of instructions, commands, symbols, and constructs;

l Programming languages as a utility program, in which the language is seen as enabling the programmer to achieve certain effects;

l Programming languages as a medium of communication between the programmer and the computer, in which the language is the means the programmer has to make the computer do the tasks required; and

l Programming languages as a medium of expression, in which the programmer can express the solution to a problem or idea in such a way that the computer can effect it.

190 Booth

Now these four will be exemplified and refined with reference to the interviews analysed.

Description of the Conceptions Found

Programming language as a code. Here the word code refers to a formal set of symbols and rules rather than a one-to-one correspondence, like a code used to send secret messages. In computer programming terms it refers above all to the syntax and semantics of the language. Typical for it is that students refer to the intuitive nature of a programming language - that a word used for a command, such as PRINT, should correspond in meaning to its meaning in natural language, that + should mean add rather than multiply. They refer often to the structure of the language, and when this means the way in which the program shifts control from one part to another, it can be taken to indicate the code conception.

One example of this is:

A. BASIC is a bit like that I think. It’s sort of, there are English words and suchlike, that tell you roughly what’s happening . .

A student who has worked in the computer industry for a few years, and had programming as a hobby for even longer, also expresses this conception in the first interview, when describing his favourite language, Forth:

K. Forth is a good language

I. What makes you say that?

K. Because you can do so much with it, as I said before. You can do everything yourself, define all the commands yourself. . . . You have to think in a new way. Say that you’ve been programming before in BASIC for example. There you’ve just got a line number, then you write a few commands, then take the next line number, write a few more commands. Then you can take a look, just at the program listing, and you see what the program does. You don’t see that in Forth. What you’ve programmed, or made, are your own commands, so you don’t really know what lies behind them. And then combining all these commands, that can bc a bit tricky.

Here, and in the discussion that follows it, both Forth and BASIC are character- ized by their internal structure, the sort of commands the languages contain, and the way in which the programmer approaches them.

The code conception is actually only found in a few of the first interviews, but appears much more frequently in the sixth set, often in a more complex form, and it appears in the responses to several lines of questioning. For example:

I. When it comes to programming, when you arc actually programming, how does it feel? Arc there any differences [in programming in ML and Pascal] there?

G. Of course there arc. In Pascal you have to declare all your variables, but you don’t have to do that in ML. And . . . well, there arc big differences in all ways, because in . . . in ML there is no what I think you call iteration, loops.

A second year student says of a good programming language:


F(2). It should be able to . . . it shouldn’t be muddled, and it should be able to, it should be strict, there should be good strict rules so that it, it is sort of well organized. A program needs to have a section where it carries out all its calculations, different routines, subroutines, different places where it does its output. Of the languages we’ve studied so far I like ML best. I think I would say it’s more logical, largely like maths, but there are logical forms that you can prove. In Pascal you make loads of declarations for variables and constants.

Although these last two extracts are more sophisticated in their reference to programming languages than the first two are, they focus exclusively on the internal structure of the language and how that relates to programs written in the language. Contrast this focus on internal structure with the next category, which focuses rather on the language as an object in itself.

Programming language as a utility. The word utility is used for a program that is used in some way in connection with the system, rather than as an application a user might wish to use. Such an understanding of programming languages sees them as belonging with the computer system, having large-scale features, such as efficiency or speed, and being able to bring about effects in the computer. The large-scale features are often said to fit the language to one purpose more than another, but why this is so is left undetermined, often explained by the fact that the language was developed for that purpose. Another large-scale feature is that of speed, which might be explained by the fact that a language is compiled rather than interpreted, or that it is intended for a particular sort of computer.

One expression of this large-scale utility conception from the first interview refers to a long list of languages given to the class, which was asked to state the extent to which the languages were familiar:

I. Why are there are so many programming languages?

T. I really think there are unnecessarily many languages. There are, like Pascal here, that’s a typical scientific language. If you want to control a robot for example, then it’s better with Pascal. Cobol is a typical administrative language - you can set up big databases and keep customer records and so on. And then there are slightly different versions of all these. A lot of technology and finance go together, the administration of a small firm, so some of them might have been adapted to both bits, sort of thing. And then there’s BASIC, that’s basic, the start sort of, the beginner’s language.

The utility conception is indicated in a few cases when students say that there are too many programming languages and some genius could combine them all, for instance:

S. It would have been best if somebody could have coordinated it in some way, but it’s not possible because of all the different machines and everything.

I. But is there anything good about having so many languages?

S. People earn money from it! Ah well, there are certainly some languages that can do one thing and others that can’t cope at all with it, or they’re more suitable for writing programs for one thing than another. . . . But it would be. good if there were some genius who could coordinate it so that we had some gigantic super language that could be used for more or less everything . . .

192 Booth

Another utility aspect brings in the suitability for the computer:

B. And then it [a programming language] should also be such that it is easy for the machine to understand, if I can put it that way, so that it is easy to carry out and fast to execute.

The second-year students often express this utility conception, referring especially to the demand that a programming language should enable programs to be easily read by others. Here is a response to the question about what makes a good programming language:

H(2). Well, it depends. There are different aspects to it, it’s actually difficult to answer that because if I write a program then I think that a good programming language, it should make it possible for somebody else to take over from me and that person should be able to understand what I have written.

Thus, a programming language should have the large-scale property of creating easily understood programs.

In summary, then, the utility conception is one that sees the programming language as an object in itself, with large-scale properties.

Programming language as a medium of communication. This conception of programming languages sees them as providing a link, via the program, between the programmer and the computer, and/or between the user of the program and the computer.

The conception is expressed more often later in the series of interviews, and was only indicated once in the first interview, by a student who said that machine code is actually the perfect programming language, but is hard to program in:

I. In what way is it perfect?

M. It is sort of perfect for the computer. It is the computer that sets the rules for what you can do basically. It is . . . but then it’s certainly difficult . . there isn’t just one language, one machine code, that suits another computer. So they can’t be used either. .

He is saying that the programming language enables the programmer to instruct the computer, communicate with it.

A second-year student indicates this conception of a programming language, in that one should be able to communicate with the computer on the computer’s terms, but also achieve a sort of communication with the problem to be solved in abstract terms, thus:

C(2). I think a good programming language is one in which you can go very close to the computer and make precise instructions so that you are almost at the machine level, but then at the same time move away and be very abstract.

Another straightforward statement from Neil that comes among several criteria for a good programming language, is:

N. And then, as I said before, it must have communication, a good system in which you can communicate with the computer, the user and so on.


It could be argued that this indicates the utility conception, but the significant difference is that it refers explicitly to the links that exist between the user, the computer, and the program, rather than the unspecified reasons for the large-scale features that indicate the utility conception.

Thus, in summary, the communication conception focuses on the links that the programming language creates or facilitates between programmer and machine, and between machine and user via the program.

Programming language as a medium of expression. The fourth conception that has been identified is one that sees the programming language as a means of expressing the solution devised for a problem. Some statements imply this directly, especially those in response to questions like, “what do you see as a good programming language ?” Others, typically in discussion of programming in the two languages SML and Pascal, imply this conception less directly.

Here are two examples of the more direct statements. The only supporting statement from the first set of interviews is this:

D. A good programming language should be able to do the things you want to do.

This indicates that the student wants to be able to express himself and his programs in the language if it is to be considered good. In the sixth set of interviews more imply this conception. For example:

R. A good programming language, . . . well, 1 suppose a programming language can’t be best at everything. If you take a language that is specialized to one area maybe, like ML in maths, well, then you want that in that area you won ‘t come across any limitations.

This might appear at first reading to indicate a utility conception, but the itali- cised phrase puts it firmly into the expression category; rather than focussing on the areas in which the language might be intended for use, focus is on specifically avoiding limitations in what the programmer wishes to do.

The indirect statements implying this conception are often made when discussing the differences and similarities between programming in the two programming languages they have learned. One example is:

I. Are there any similarities between programming in ML and Pascal?

M. Oh sure. Absolutely. Because you, programming as programming, you have to solve the problem in some way, and you do that presumably in the same way for both, and then it’s only a question of applying them in different ways so that you . . write the program itself. So the thinking that lies behind it is just the same, I think. But you have to approach it in a slightly different way when you write the program.

The students in this example see solving the problem as being independent of the language used, but the final solution is then expressed in the language; in other words, one first solves the problem and then writes a program in the language.

Discussion of the conceptions of programming languages. Four qualitatively different conceptions of programming languages have been identified and described. It would be wrong to imagine that a student consistently expresses only one of

194 Booth

these conceptions throughout an interview. On the contrary, two or even three might be expressed, differentiated by the context. The important point is that they do exist and are distinctly different qualitative understandings of what a programming language is, or might be.

Two of them have corresponding features in the theory of programming. The code conception corresponds to that part of programming that deals with the syntax and semantics of a programming language; syntax here refers to the words and symbols that make up the language, and semantics refers to the rules that determine the effect brought about by combinations of the words and symbols. The utility conception refers to the large-scale features, which roughly correspond to the prag- matics of a language, or the ways in which the language is seen to perform. As pointed out already, the significant difference between these is that the former focuses into the language while the latter looks at it from outside.

The means-of-communication conception can be seen as referring to the ways in which the language enables programmers to communicate with the computer in use, as well as enabling them to write programs that facilitate communication for the user. The expressive-medium conception refers to the aptness (or inaptness) of the language to the solution to a problem, or even to the problem itself.

For the beginner, the identified conceptions form a hierarchy, representing both the development of the language as it unfolds in any typical programming course, and the sequence of layers of awareness that develop. For the experienced programmer, however, each sort of conception has its uses. For example, while the beginner who sees the programming languages he or she is learning only as a code will have difficulties in following discussions of the relative merits of available programming paradigms, the experienced programmer needs to drop down from his higher conceptions to just this code conception when debugging or improving the efficiency of a program. The point to make here, however, is that certain conceptions are essential for making sense of the activity of programming in certain languages and/or environments.

Two points can be made here about the appropriateness of different conceptions for the learner. The first is a general point, and refers to research in programming in natural language. Among the students showing a predominantly code conception of languages, reference was often made to the desirability of intuitively under- standable symbols and keywords. This is all very well, and of course + should mean add and PRINT should mean output to paper rather than anything else. However, when researchers have asked students to prepare “programs” to solve certain problems typical of normal programming activity, it has been found that the use of natural language tends to induce an assumption that the computer has an intention to understand and interpret the commands given, as would another person receiving the commands (Miller, 1981). Pea has identified three “superbugs” in novices’ programming, and two of these can also be linked to an expectation of mutual understanding based on the closeness of the programming language to natural language (Pea, 1986). Thus, this undeveloped conception of what a programming language is - a code, and that as near to English as possible - has dangers for the beginner.

The second point is specific to programming in SML. Programs in SML are, as described earlier, written in the form of strict mathematical functions that can be proved to do exactly what they claim to in the mathematical sense; there are no unexpected side-effects. Thus, a program correctly written in strict SML inevitably satisfies its specification and is therefore a correct program. Thus, for writing programs in SML it is the specification of the solution to the problem that is of great-


est importance. Now it is seen that the conception of programming languages as systems of code is quite inadequate for coming to terms with SML as a programming language; the next two in the set of conceptions - utility program and means of communication - are virtually irrelevant because SML is poor in terms of the performance prized by students, and the strict core of SML has, on princi- ple, no communication aspect. (Communication is nonfunctional in that it inevitably causes side-effects, and more extensive commercial programs have to deviate from the strict functional nature of SML for their communication routines.) The fourth conception, that a programming language has to enable its user to express exactly what he or she wants the program to do without experiencing any limitations, is seen to be essential for accepting SML as a programming language. The fact that such a conception was indicated very rarely, and hardly at all among the first-year students, accounts for much of the confusion and intuitive dislike for SML that was sometimes expressed, and the relief that was shown when the course went over to Pascal.

Conceptions of the Nature of Programming

Three qualitatively distinct conceptions of programming have been identified.

l Programming as a computer-oriented activity, in which focus is on programming as centered on the computer, above all mastering the computer, or communicat- ing with the computer;

l Programming us a problem-oriented activity, in which focus is on programming as a problem-solving activity, either creative or educational; and

l Programming us a product-oriented activity, in which focus is on the end-product, either in terms of its fitness for the user, or as it will be used and maintained by colleagues or purchasers.


Programming as a computer-oriented activity. The single distinguishing feature of statements that imply the computer-orientation conception of programming is that the role of the computer is focussed on. Some extracts from interviews can illustrate different variants. The simplest and least differentiated statement is of the type:

I. What is programming actually?

G. Well, you sit at the computer and play a bit at the keyboard.

These were found in the first interview as G’s only thoughts on the subject. A more thoughtful statement, but one equally focussed on the computer, is:

C. It’s to sit in front of the computer screen and . . . ah . hm . . . how can I put it . to get the machine to achieve something, something that you want it to do.

And another:

E. It’s about making the computer usable. . . You have to write a program in order to use the computer for something.

196 Booth

These three statements show a clear conception of the essence of programming involving the programmer in a one-way relationship with the computer, making the computer do something (unspecified) in some way (also unspecified).

A development of this one-way relationship in an unspecified activity is expressed by John:

J. It’s composing, or putting together, a plan of action for the computer which is to do something in a certain way. . . _ It’s putting together instructions for the computer.

Here the activity starts to take form, that of putting together a plan of action for the computer to follow.

Programming as a problem-oriented activity. The problem orientation is implied when the problem that gives rise to the need to write a program is in focus. One clear statement implying the problem orientation is:

B. It’s about getting a problem on paper and having to solve the problem, or teach the computer to solve the problem, so that you don’t have to sit there and solve it. Yes, try to teach it as easily as possible, so that it can do it as well as possible, sort of. . .

And another:

A. I suppose you have to start from having a problem that has to be solved, and first it needs a hell of a lot of thinking, I suppose . . . wondering about how to make it good, and then...err... we11 then it is the typing itseff I suppose.

ln both cases the computer is mentioned, but it is secondary in importance to the problem; overall, these statements, especially taken in the context from which they were taken, indicate a focus on programming as solving a problem, thin~ng about the problem, and making the computer solve the problem.

Programming as a product-oriented activity. The third conception of programming focuses on the program that is produced rather than on the problem that gave rise to it or the computer’s role. There are two distinct foci; first there is the focus on the program as an object that will be used by other programmers, in maintaining it in the future.

K. He should write programs that everybody can understand, even if he’s dead and buried, you should be able to understand his programs later. . . . Those who use them might have changed their requirements after a few years, you might want to make smaI1 changes. And then if nobody knows where they should be changed, you have to get new prog~~e~ who have to do everything over from the start again.

The second focus is on the program as something that users will use, and that the program should be easy for them to use, as expressed here:

B. They make good programs that work well, so that the user understands, doesn’t understand what is happening maybe, because that’s . . . but understands what he has to do sort of. I think there are a lot of programs with poor info~ation coming up on the screen sort of, they should be easy to follow.


In both extracts, programming is referred to in the context of discussing what the qualities of a good programmer might be, but the conception is also expressed in other contexts, as here, when the demands of programming are being discussed:

P. It [the program] should be usable by those for whom it is intended, and tested many times as well, it should be tested a lot even for extreme cases I think. That’s important before you release it.

This statement also illustrates the reason for considering both foci to be part of one conception, in that common concerns - here the need for thorough testing and elsewhere the demand for good documentation and clear screen layout - are often taken up with a definite concentration on the final product and the interests of both the user and the subsequent maintaining programmer.

Discussion of the conceptions of programming. Three conceptions have been identified, and one asks oneself about their status for the learner. At first glance, the computer-oriented conception might be thought of as a “hacker’s approach” to programming, and therefore undesirable for a professional programmer. The first of the extracts quoted is certainly such, but the others show a more considered approach to programming, without reference to initiating problem or intended product. It must be emphasised that this article is concerned only with charting the conceptions found among the students irrespective of epoch, but the ultimate goal is to describe the developments seen during the course of instruction.

Reflection on the working life of the professional software engineer, which these students will become if they specialise in software rather than hardware, shows that there are times when each of the conceptions is of superior worth. At the design stage there must be a focus first on the problem and then on the product, followed in all probability by a switching between the two, as the program design emerges to solve the problems posed and satisfy the user’s needs. Then, well-developed problem and product orientations to programming are needed. As the computer industry is developing today, the same person will probably do a good deal of the development of the program, at the prototyping stage if not at the coding stage, and then the computer orientation is necessary, with focus on the keyboard, the symbols, and the details of getting a working program code into the computer.

Conceptions of the Computer

Four qualitatively distinct conceptions of the computer have been identified, which will be described in contrasting pairs. The first pair is the computer as a tool and the computer as a facilitator; the second is the computer as a machine and the computer as a universal engine.

l The computer as a tool, in which the computer is seen as being equipped to perform certain tasks - one can use the computer to do lots of things that would otherwise be more difficult, such as calculations, or text-processing.

l The computer as a facilitator - the computer has the potential to enable one to do the things one wants to do, they facilitate actions or wishes, they offer the potential to fulfil needs.

l The computer us a machine - the computer can perform enumerable specific tasks, be made to act like a number of specific machines.

l The computer us a universal machine or “universal engine, ” in which the computer can be made to perform innumerable tasks, there is no limit to its

198 Booth

possibilities - given enough ingenuity one can make the computer do absolutely anything.


The tool and the facilitator conceptions. The tool and the facilitator conceptions both focus on the tasks performed by the computer; the former emphasizes the sorts of applications that are made, while the latter emphasizes the potential for application. The following two quotes illustrate them and the difference between them. The first describes the computer as a distinct number of tools:

I. What can computers be used for?

K. Calculations, administrative tasks, control of different processes, at Volvo for example.

I. On the production line?

K. Yes, on the line. robots have already taken over there, adjustable robots.

While the second shows the facilitator conception in saying:

B. I think the computer is going to take a bigger place in society, that’s clear. We are going to get more help from them, a lot of heavy jobs will possibly disappear . . . people won’t have to sit and sort through a mass of paper because it can be done in the computer instead. . .

Both of these refer to what the computer can do for its users, what use can be made of them. While the actual processes performed by the computer might be identical, the subject’s view of them is different - in the tool conception the relationship between the user and the computer is taken for granted and seen as fixed, whereas in the facilitator conception an active role is given to the user/society in the relationship.

The machine and ~~~i~ersa~ engine conceptions. The second pair, the machine and universal machine conceptions, concern the perceived limits of the uses to which the computer can be applied. The machine conception of the computer is quite simply that the computer is no more or less than a machine, special only in as far as it can take on the role of many different machines. This is impIicit in a great deal that is said in direct reference to the computer - computers do things, computers have to be instructed or controlled - and is implied by statements to the effect that computers have no feelings, and that computers can only do what their programmers make them do. The next extract expresses both parts of this:

M. Last year I worked in the chemical industry and there there are computers for control and absolutely everything.

I. Where might the limits lie?

M. The limits are actually what you yourself b&eve the computer can do, sort of . . . I mean, the computer won’t do anything it’s not told to do, will it? So I think that the computer has no limits, but it is man himself that sets the limits.

L-earning to program 199

It is striking how often it was said that computers can be used for doing everything. While the extract above says that the computer has no limits, it deliberately steps back from the universal engine conception of the computer with the qualification that it is man that sets the limits. The full-blown conception involves belief that the computer can indeed do anything, it is merely a question of time and effort and ingenuity:

I. What can computers be used for?

E. Everything!

I. Everything?

E. Yes . . . control, process control and that sort of thing .

I. Is there anything that computers cannot be used for?

E. Yes of course there are. . . . Feelings and all that, the computer cannot show feelings.

Discussion of the conceptions of the computer. As with the conceptions of programming and programming languages, the conceptions of the computer described here are those found throughout the interviews, without reference to development of conceptions. The most striking aspect of the conceptions is that there is so often expressed, either explicitly or implicitly, the belief that the computer can be used to do absolutely anything. A well-known result in computer science is that there are tasks the computer cannot accomplish, the travelling salesman problem being the best described; there are problems for which it is not possible to define an algo- rithm. This does not lie within the experience of the normal entering student and is not mediated by instruction until a much later stage in the programming course.

Also of interest is that even students who believe that the computer can do anything draw back when it comes to the computer expressing human emotion, if not cognition; there is no sign of anthropomorphic conceptions of the computer.

LEARNING TO PROGRAM

Learning in the phenomenographic tradition seeks to describe not the process of learning as such, but rather what is learned in different situations. At its simplest, learning is seen as the replacement of one conception by a qualitatively superior one, and this can be illustrated in this study by the example of developments of conceptions of the nature of programming.

The simplest case is that of Clive. In the first interview he says of programming:

C. It’s to sit in front of the computer and . . . ah. . . hmm . . . how can I put it. . . to get the machine to achieve something, something that you want it to do.

Thus his conception of programming is computer-oriented and very simple - the programmer makes the computer achieve something that is only specified in terms of the programmer’s own wishes. In the sixth interview he says:

200 Booth

C. It’s to solve a task you get, to solve a problem. And . . . to get it to work as well as possible.

This now takes in the problem and the product, in more specific terms. The problem is specified as something input to the programmer (“a task you get”), who uses the computer to make something, the product, that has the property of working as well as possible. The programmer, the problem, and the product are all present, while the computer is only implicitly involved. Clive can be said to have developed his conception of programming in that he has acquired qualitatively more advanced conceptions involving problem and product.

Neil is rather different in that he is more experienced than Clive from the outset. In the first interview he says of programming:

N. Well, first of all it depends what you are going to do. But if you consider it in general, then you’ve got to sit down with the problem. I discovered that the first time I wrote a program that was going to be sold to somebody. I wrote the program and then I asked what it was going to be used for, and that was rather a mistake. . . First you need to find out how to program before you start programming. And then it depends what language you are going to use. . . . But as I said, first you’ve got to sort out the problem.

This is a problem-oriented conception of programming, where the focus is on the problem as it affects the task of the programmer. The program is only an inci- dental interest - it is not a “product” in the sense of the product-oriented conception. The computer is not specifically mentioned here, and the programming language is taken as given. By the sixth interview Neil says of programming:

N. It’s to analyse a problem in a sensible way, to see a problem and then transf- . or realise the problem in program code in whichever programming language you are using. And to do it in a structured and sensible way and preferable effectively, so that you use the least possible time to achieve the result. The result should be optimal on all fronts, whether it is program code, efficiency, exploiting computer power and so on. That’s what you do yourself, but when you work with others you have to get into communication with your colleagues, first with the customer, understand what his problem is, not to build a castle when he wants a bungalow so to speak. And that’s also a sort of aspect of programming, when you are are working with others, programming in a group, that you should effect a communication between them, that you have the same level of understanding of the problem. That’s what I think programming is, but then the programming itself, the sitting and typing, that’s only the result of all the thinking and analysis of the problem.

This statement extends the conception of programming to the product orientation, referring to both the user and the programmer’s colleagues; the problem is still seen to be the most important input to the programming activity, but the programming community and the user’s demands for the product are also brought in, as is the quality of the product. Thus, learning is again indicated in the development of a qualitatively superior conception.

However, learning in this simple sense - replacing a conception by a qualitatively superior one - is inadequate to describe learning to program. In this complex domain, where there is a constituting framework of general themes and a structure of context-specific and language-specific concepts as well as problem- solving approaches, learning cannot be seen so simply. It is not only the development of qualitatively more advanced conceptions of the constituents of programming, but also the development of quantitatively more conceptions of the con-


stituents. And on top of that, learning is the development of an intuitive awareness of the appropriate set of conceptions to the task in hand. Then handling these conceptions and approaches, intuitively or automatically being able to bring into play the best of them, or grouping of them, according to the needs of a particular context, is what underlies the efficiency of the programming skill and overall programming competence. A glimpse of such development can be seen in Neil’s statements above, in that in the first interview he focuses strongly on the problem aspect of programming, mentioning the language in passing, while in the last interview he airs all three conceptions of programming and relates a much more complexly related view of programming, still focussing partly on the problem to be solved but now taking in the language more specifically, and product efficiency from the user’s and the computer’s point of view.

This article has not set out to describe learning to program as such, but the grounds on which that work is being built. The work in progress is also looking for conceptions of the constituent technical constructs of programming in SML and approaches to writing programs, as well as the development of conceptions and how they are brought to bear on writing programs.

Acknowledgments - The author would like to acknowledge financial support for this work from the Swedish National Board of Education, and from the Tercentenary Foundation of the Royal Bank of Sweden through its funding of the project Interactive Didactic Environments.

REFERENCES

Andersson, J. R. (1982). Acquisition of cognitive skill. Psychological Review, 89,369-406. Andersson, J. R., Pirolli, P., & Farrell, R. (1988). Learning to program recursive functions. In M. T.

H. Chi, R. Glaser, & M. J. Farr (Eds.), The nature of expertise (pp. 153-183). Hillsdale, NJ: Erlbaum.

Booth, S. A. (1987). Learning to program: A review of some recent investigations (Publikation 1987:02). Giiteborg, Sweden: University of Giiteborg, Department of Education and Educational Research.

Booth, S. A. (1990). FOP I. A program for use in phenomenographic research. Theoretical background and the development of a descriptive specification (Didakta 1990:02). Goteborg, Sweden: University of Gtiteborg, Department of Education and Educational Research.

Fay, A. L., & Mayer, R. E. (1987). Children’s naive conceptions and confusions about Logo graphics commands. Journal of Educational Psychology, 79,254-268.

Glaser, H., Hankin, C., & Till, D. (1984). Principles offunctional programming. London: Prentice- Hall.

Hoc, J.-M., Green, T. R. G., Samurcay, R., & Gilmore, D. J. (1990). Psychology of programming. London: Academic Press.

Kagan, D. M., & Douthat, J. M. (1985). Personality and Learning FORTRAN. International Journal of Man-Machine Studies, 22, 395-402.

Krasner, H., Curtis, B., & Iscoe, N. (1987). Communication breakdowns and boundary span- ning activities on large programming projects. In G. M. Olson, S. Sheppard, & E. Soloway (Eds.), Empirical studies of programmers: Second workshop (pp. 47-64). Norwood, NJ: Ablex.

Kurland, D. M., & Pea, R. D. (1985). Children’s mental models of recursive Logo programs. Journal of Educational Computing Research, 1,235-244.

Lawler, R. W. (1985). Computer experience and cognitive development: A child’s leaning in a computer culture. New York: Halsted.

Linn, M. C. (1985). The cognitive consequences of programming instruction in classrooms. Educational Researcher, 14,5-29.

Marton, F. (1986). Phenomenography - A research approach to investigating different understandings of reality. Journal of Thought, 21.28-49.

202 Booth

Mayer, R. E. (1981). The psychology of how novices learn computer programming. Computer Surveys, 1,121-141.

Miller, L. A. (1981). Natural language programming: Styles, strategies and contrasts. IBM System Journal, 20, 184-216.

Papert, S. (1980). Mindstorms: Children, computers and powerful ideas. Brighton, England: Harvester Press.

Pea, R. D. (1986). Language-independent conceptual “bugs” in novice programming. Journal of Educarional Computing Research, 2,25536.

Wikstrlim, A. (1986). Functional programming using Standard ML. London: Prentice-Hall.

a study of learning to program from an experiential perspective

Documents