PHENOMENOGRAPHIC ANALYSIS OF LEARNING TO PROGRAM

Get Complete Project Material File(s) Now! »

PROGRAMMING: A REVIEW AND DISCUSSION

T here has been considerable research into computer science education, in particular programming, in the last 20 years. This interest in the teaching and learning of programming is not only a part of the general growth spurt in computer education, but also a field of research in its own right.
Programming is a challenging task and programming courses are generally regarded as difficult by many introductory students (Buck & Stucki, 2001; Mahmoud, Dobosiewicz & Swayne, 2004). Programming courses often have high dropout rates or, if completion of the introductory courses is achieved, there is a strong possibility that many students are still not able to program. Most educators involved in teaching programming agree that many students struggle in this field.
Results from a recent project by McCracken et al. (2001) are compelling, (my emphasis) because of the number of authors from differing educational institutions and cultures. The 10 authors teach introductory programming across 8 universities, in 5 countries. Each author tested his/her own students on a common set of programming tasks. The students performed much more poorly than the authors had expected. The students did not simply fail to complete the set task; most students did not even get close to solving the task. (Lister & Leaney, 2003) To this end much topical literature concerns the teaching and learning of programming at different levels of education. Some key concerns or questions in the literature are:

• What are the properties of expert programmers?
• What resources and processes are involved in creating or understanding a program?

During the period between the 1970s and late 1980s there has been extensive literature related to these questions and regarding programming as a cognitive process (Bishop-Clark, 1995; Brooks, 1977; Dijkstra, 1989; du Boulay, 1989; Linn & Dalbey, 1989). More recent literature highlights studies of object-oriented programming (OOP) and its relationship to the procedural approach to programming.
Studies of programming can be divided into two main categories, those with a software engineering perspective, and those with a psychological/educational perspective (Robins, Rountree & Rountree, 2003). Studies with a software engineering perspective focus on experienced or professional programmers. These programmers typically work in teams and often develop software projects. However, my interest is in the initial development of individual programming skills. This does not mean that an understanding of basic software engineering principles will play no part in the study or be given no attention. However, in this review learning to program is addressed from an educational perspective.
As already stated in chapter 1, the national curriculum for the discipline of computer studies at school spells out a change in the programming language from one of procedural, to one of object-orientation. It is, therefore, necessary for an understanding of both in-service and pre-service teachers’ experiences of learning to program to include some comparison and to elaborate on the different programming paradigms and related languages. The next section (2.1) provides an overview of programming in general and programming languages relevant to this study. Drawing from the different sources of literature, several trends and topics can be identified, as indicated in sections 2.2-2.7. Section 2.8 discusses the difficulty of programming by considering factors such as aptitude, learning style and motivation. In section 2.9 the issues relating to the teaching and the pedagogies of programming are reviewed. Three didactic models are reviewed and a fourth model is suggested. Section 2.10 discusses the kind of thinking that is characteristic of programming and Bloom’s taxonomy is also given attention with regard to programming, while section 2.11 reviews the role mental models play in the comprehension of programs.
Section 2.12 concludes the chapter.

Programming review

A program is a set of instructions that a computer can execute to perform a task. This is a simple enough idea, but for the computer to process the instructions, they must be written in a form that the computer can use. Therefore, programs have to be written in programming languages. There are two basic aspects of programming: data and instructions. To work with data, one needs to understand variables and types of data (in the case of procedural programming), and objects encompassing attributes and actions (in the case of OOP); to work with instructions, one need to understand control structures and subroutines (in the case of procedural programming) and interacting objects and methods (in case of OOP). The rules that determine what is allowed and not allowed are called the syntax of the language. Syntax rules stipulate the basic vocabulary of the language, and how programs can be constructed using techniques like loops, branches, and subroutines (methods).
So, to be a successful programmer, one has to develop a detailed knowledge of the syntax of the programming language that one is using. However, syntax is only part of the story. It’s not sufficient to write a program that will run: a program that will run and produce the correct result is needed! In short a semantically correct program is required. A semantically correct program is one that does what you want it to, i.e. the meaning has to be correct. The meaning of the program is referred to as its semantics.
For the procedural programmer, the basic building blocks of programs are variables, expressions, assignment statements, subroutine call statements and control structures. For the OO programmer, the basic building blocks are objects that consist of data and functionality. Stringing the relevant building blocks together in order to obtain a semantically correct program to perform a specific task, is what makes programming a challenge and what many consider to be difficult (Jenkins, 2002; Thomas, Ratcliffe & Thomasson, 2004). A distinction between “programming in the small” and “programming in the large” is made in the literature. Eck (2004) refers to programming in the small (sometimes called coding) as that of filling in the details of a design, i.e. the step-by-step instructions for performing fairly small-scale tasks. The design of the overall structure of a program (complex programs) that makes use of many classes (in the case of OOP) and many procedures (in the case of procedural programming) is referred to as “programming in the large”. One needs both experience and intuition to solve even the simple, small-scale tasks. To develop a complex program, an even greater effort is required.
For a long time, both teachers and students in high schools have been using a procedural language and procedural approach to programming. They have done this with some success. Java, an internet-savvy and OO language, has gained popularity in tertiary institutions and very recently has been introduced in high schools. The attractiveness of the internet has contributed in part to the change of language (object-oriented language). This change has incited a lot of discussion and debate with regard to implementation of the language. Some of the issues of debate in and amongst higher education institutions involve when and how object-oriented programming should be taught in the introductory programming courses (Zhu & Zhou, 2003; Kölling, 1999; Kölling & Rosenberg, 2001) and whether or not the object-oriented approach should be taught in a language-free scenario (Fincher, 1999). These concerns seem to make appropriate the need to highlight the difference between the two approaches to programming.

Comparison of procedural and object-oriented languages

There are many programming languages. Languages are categorized into procedural (or structured, also often referred to as imperative), logic, functional, and object-oriented languages. The popular languages traditionally taught in schools and universities were procedural languages, mainly Pascal¹ and FORTRAN. However, in recent years, object-oriented languages such as Java have become one of the influential programming languages in implementing the OO paradigm. Object-oriented programming is characterized by programming with objects, messages, and inheritance within hierarchies of classes. The terms need to be clarified. An object is a program construction that has data (that is, information) associated with it and can perform certain actions. When the program is run, the objects interact with one another in order to accomplish whatever the program is designed to do. The actions performed by objects are called methods. A class is a type or kind of object. All objects in the same class have the same kinds of data and the same methods associated with that class (Savitch, 2001). Object-oriented programming shifts the emphasis from data, as passive elements defined by relations or acted on by functions and procedures, to active elements interacting with their environment. In contrast to procedural programming, the emphasis shifts from describing control flow to describing interacting objects.
Programs must be designed. Few people can simply sit down at the computer and compose a program of any complexity. The discipline called software engineering is concerned mainly with the construction of correct, working, well-written programs.
The traditional primary software engineering design methodology was structured programming. The term structured programming was coined to describe a style of programming that emphasizes hierarchical program structures, in which each command has one entry point and one exit point. The goal¹ of structured programming is to provide control structures that make it easier to reason about procedural programs. The structured programming approach to program design was based on the following principle: divide and conquer. More specifically, to solve a large problem, break the problem into several pieces and work on each piece separately; each piece is then treated as a problem which can itself be broken down into smaller problems. Eventually you will work your way down to problems that can be solved directly, without further decomposition. Next, the sub-solutions must be reassembled to generate the solution to the problem. This step probably involves creating an algorithm² that controls the sequence of events. This approach is called top-down programming (Eck, 2004; Morgan, 1991).

ABSTRACT 
ACKNOWLEDGEMENTS 
GLOSSARY OF TERMINOLOGY 
1 INTRODUCTION.
1.1 BACKGROUND TO THE STUDY
1.2 THE SIGNIFICANCE OF THE STUDY.
1.3 RATIONALE OF THE STUDY
1.4 OUTLINE OF THE STUDY.
2 PROGRAMMING: A REVIEW AND DISCUSSION
2.1 PROGRAMMING REVIEW.
2.2 PROBLEM SOLVING AND PROGRAMMING
2.3 EXPERTS VERSUS NOVICES.
2.4 KNOWLEDGE VERSUS STRATEGIES
2.5 COMPREHENSION VERSUS GENERATION
2.6 MISCONCEPTIONS IN GENERAL PROGRAMMING
2.7 PROGRAMMING: ISSUES
2.8 THE DIFFICULTY OF PROGRAMMING
2.9 PEDAGOGY OF PROGRAMMING
2.10 THINKING IN PROGRAMMING
2.11 MENTAL MODELS AND PROGRAM COMPREHENSION
2.12 SUMMARY
3 A FRAMEWORK FOR THE STUDY
3.1 NATURALISTIC INQUIRY.
3.2 AN OVERVIEW OF THE PHENOMENOGRAPHIC PERSPECTIVE
3.3 COGNITIVIST PERSPECTIVES ON LEARNING
3.4 A PHENOMENOGRAPHIC PERSPECTIVE ON LEARNING: DEEP VERSUS SURFACE APPROACH.
3.5 A LIMITATION OF PHENOMENOGRAPHY
3.6 ACTIVITY THEORY
3.7 SUMMARY AND CONCLUSION.
4 RESEARCH DESIGN AND METHODOLOGY.
4.1 RESEARCH DESIGN AND RATIONALE
4.2 THE PILOT STUDY
4.3 THE MAIN STUDY: HOW PRE-SERVICE AND IN-SERVICE STUDENTS LEARN TO PROGRAM IN A NEW LANGUAGE
4.4 ANALYSIS OF DATA
4.5 VALIDITY AND RELIABILITY OF THE STUDY
4.6 CONCLUSION
5 A PHENOMENOGRAPHIC ANALYSIS OF LEARNING TO PROGRAM
5.1 WAYS OF EXPERIENCING THE ACT OF LEARNING TO PROGRAM
5.2 OUTCOME SPACE
5.3 FURTHER ANALYSIS
6 DATA ANALYSIS: HOW DO STUDENTS PROGRAM AND SOLVE PROBLEMS?
6.1 DESCRIPTION OF THE FOUR “STEPS” EVIDENT IN THE STUDENTS’ PROGRAMMING
(PROBLEM SOLVING PROCESS)
6.2 THE TWO QUALITATIVELY DIFFERENT APPROACHES USED BY THE STUDENTS
6.3 A BRIEF SUMMARY OF THE CONTENT OF THE PROBLEM TASK (TEST) USED IN THE
STUDY
6.4 ILLUSTRATIVE DATA ANALYSIS OF APPROACH A AND APPROACH B
6.5 SUMMARY
7 THE LEARNING CONTEXT: IMPACT ON APPROACH TO LEARNING TO ,PROGRAM AND PROBLEM SOLVING
7.1 BRIEF DESCRIPTION OF THE CONTEXT AS USED IN THIS STUDY
7.2 ANALYSIS IN TERMS OF THE SETTINGS
7.3 SUMMARY OF THE INSTITUTIONAL SETTINGS
7.4 ADDING TO THE CONTEXT: UNIVERSITY LECTURERS’ PERCEPTIONS OF LEARNING
AND TEACHING PROGRAMMING
7.5 CONCLUSION
8 ANALYSIS OF STUDENTS’ PERORMANCE IN EXAMINATION QUESTIONS
8.1 PERFORMANCE IN ASSESSMENTS OF IN-SERVICE TEACHERS
8.2 SECONDARY ANALYSIS OF THE PERFORMANCE IN SPECIFIC QUESTIONS
8.3 SUMMARY
9 SYNTHESIZING THE STUDY: INSIGHTS, DISCUSSION AND REVIEW.
9.1 OVERVIEW OF THE RESEARCH FRAMEWORK.
9.2 DISCUSSION
9.3 IMPLICATION FOR TEACHING PRACTICE
9.4 LIMITATIONS OF THE STUDY.
9.5 RECOMMENDATIONS FOR FURTHER STUDY.
9.6 CONCLUSION
REFERENCES.
APPENDICES
GET THE COMPLETE PROJECT
Learning to Program, Learning to Teach Programming: Pre- and In-service Teachers’ Experiences of an Object-oriented Language