Applying Constructivism in a First Programming Course

Reviewed Papers

Saving Weak Programming Students: Applying Constructivism in a First Programming Course Andrew K Lui1, Reggie Kwan1, Maria Poon1, Yannie H. Y. Cheung2 1

School of Science and Technology Open University of Hong Kong 30 Good Shepherd Street, Homantin, Hong Kong {alui,rkwan,mpoon}@ouhk.edu.hk 2

Department of Sociology Chinese University of Hong Kong, Hong Kong [email protected] Abstract The Perform approach aims to improve the success rate of weak students in a first programming course. The approach, based on constructivism, takes a tight control on the mental model construction process in the weak students, and allows the students to navigate through many conceptual pitfalls in programming fundamentals. The paper covers a discussion of applying constructivism in programming, exposes common hazards in the learning process, illustrates why weak students are weak, and then suggests several guidelines that can help the weak students to attain at least foundation level programming. The paper ends with a summary of our experiences in the effect of the Perform approach. Keywords: Programming, constructivism, computer science education, mental models

1. Introduction Education for all succinctly describes the mission of the Open University of Hong Kong, and as computer programming instructors at the institution, our goal has become programming for all. Programming for all goes beyond the provision of programming courses for everybody. We hope that even weaker students can learn programming successfully - at least reaching the foundation level such as program control, subroutine calls, and primitive data structures. Students with this programming skill level have an opportunity to sample more advanced concepts including data structures and algorithms, and therefore in a better position to reflect whether computing is still appealing to them. Achieving the goal of programming for all is very challenging. The well-known fact that programming is hard is only a superficial view. Each year we notice that about 10 to 20 percent of students get stuck at the very beginning of the course and never got past the first assignment. These weak students have often acquired an incorrect understanding in essential and fundamental programming concepts: the working of a variable, the execution of a program, the association of input/output and program code, etc. Frustration entails as they see

inroads – The SIGCSE Bulletin

unexpected outcomes when they apply incorrect concepts in programming. After years of futile attempts to save these weak students with different student support schemes and learning aids, we recently identified that the elusive key to success lies in a tightly controlled concept construction. Any construction of incorrect concepts, happened either before or during the course, is considered harmful. We therefore put these weak students through a learning process that rigorously avoids the construction of incorrect concepts. At the same time, the process also facilitates students to avoid using previously acquired incorrect concepts. If weak students are particularly susceptible to the construction and the use of incorrect concepts, then this instructional approach could steer them away from the learning pitfalls in the early part of the course. They would have a higher chance to make to the end of the course. We developed a courseware for weak introductory programming students based on what we call the Perform approach. The Perform approach not only helps weak students to survive. It also helps average students to better consolidate their programming skills. In the development we went back to the basics and analyzed the process of learning using theories from cognitive science and constructivism. Constructivism, in particular, offered a 72

Volume 36, Number 2, 2004 June

Reviewed Papers example, variable is one of the many elements in introductory programming. Learners cannot construct models directly from the design model of variable, but through a textbook for how variables work instead. Then the constructed mental model of variable is tested and adjusted through programming practices and textbook revision. Figure 1 illustrates the relationship between the mental models, the design model, and the interface that projects the design model to the learners. Constructivism is an education paradigm that addresses how learners construct mental models. As described in [1], effective learning in constructivism demands the construction of viable models – models that match the actual design models. Learners are not seeking truth in constructivism, but rather constructing models that could correctly explain the reality. The construction of mental models is a recursive process. New mental models can appear after existing mental models are adjusted or dropped according to experience gained from interacting with the world. Learning to program is difficult because the above learning process is susceptible to following hazards. The first three potential hazards concern with the interface, and the next two concern with mental model construction.

handle to understand the process of learning to program. Constructivism has been applied in physical science education for many years and it is emerging as the main learning theory. Recently its application to computer science education began to appear in the literature [1][3][6]. The remainder of this paper is structured as the following. The paper first discusses the challenge of learning to program from a cognitive science and constructivism perspective. We identified the obstacles that hinder weak students from learning to program. Then we outline the principles of Perform approach and discuss how these principles could resolve the obstacles. The paper ends with a discussion of preliminary results on the effectiveness of the Perform approach, and an experience sharing in applying the approach to a first programming course. 2. A Constructivist View on Learning to Program There is an abundance of literature on better ways to teach introductory programming, but scarcely any targeting at saving the weak students. The more original learning theory of constructivism can offer a promising starting point. In this section we will briefly describe how constructivism explains the problem of weak students and suggests a solution to the problem.

Learner

Mental Models Models of computer programming elements as constructed by the learner

Interfaces (System Images)

Programming Language Designer

Models of the elements as presented in study materials, lectures, or programming languages and environments

Design Models Actual models of computer programming elements

Cognitive Gap

Figure 1: Learning to Program from the Cognitive Science Perspective.

1.

From the perspective of cognitive science, learning to program involves the mental construction of models of computer programming elements. Learners are successful if they can construct viable models that match the design models of computer programming elements. There is however no direct access to the design models. The learners must rely on an interface of the design model, such as a lecture on computer programming, content in study materials, or a programming environment. Learners interact continuously with the interfaces to allow them to probe the actual models, to construct associated mental models, and to test already constructed mental models. For inroads – The SIGCSE Bulletin

2.

73

Presenting a high fidelity interface of programming model in textbooks or lectures is challenging. Computer programming models and their interactions are complex. It is not unusual that programming instructors inadvertently present wrong programming models to learners. Common first programming languages, such as C and Java, pose difficulties to novice learners with abstract symbols and implicit concepts, from which the learners use to probe the underlying programming model at the interface.


Reviewed Papers 3.

4. 5.

developed a number of guidelines called the Perform approach. The guidelines can be summarized by the following three simple thrusts in instructional design. Avoid the construction of non-viable models/Facilitate the construction of viable models. Avoid the invoking of inappropriate base models during knowledge construction. Facilitate the invoking of appropriate base models during knowledge construction. The main idea of these guidelines is protect the weak students against the hazards. We believe that when the weak students have at least reached the end of foundation programming, they will become more tolerable to the hazards.

Most programming practice, for probing the programming models or checking the mental models, requires learners to carry out a number of actions in editing, compilation, and execution before a feedback is obtained. Blackwell [2] commented this as the loss of direct manipulation. The actual programming model is not continuously presented to the learner at the interface. The learning process is interrupted and it could be a source of frustration to learners who are inexperienced in using programming environments. The construction of new knowledge is usually based another piece of knowledge, which the learner may not have already correctly constructed. The learner may have used an unsuitable piece of knowledge as the basis to construct new knowledge.

3.1 Guideline 1: Show-Behavior No-Analogy Analogies or metaphors are popular instructional tools but their applications in learning to program are prone to eliciting inappropriate mental models in students. A classic example is the use of box analogy for variables that brings out the misconception of a variable capable of holding more than one value at a time, and the value is removed from the variable when the variable is used [4]. Computer programming is all fabricated that finds few parallels in the physical world and we believe that most analogies could potentially cause problems in some students. Multiple examples should be used to illustrate the behaviour of programming models instead, so that students could use the examples to construct their own viable mental models. Multiple examples should always be used to allow students to construct, test, and refine their mental models.

We suggest that weak students are weak because they are less tolerable to these hazards. All students would encounter these hazards but the weak students would get stumbled and stalled more easily. In the following we will explain the characteristics of weak students that magnify the effects of these hazards. The discussions will involve not just the cognitive domain but also include the affective domain. Hazard 1. Weak students do not have confidence in themselves, instructors, or the study materials. Each error discovered after already learned a concept dents the confidence further and dampens motivation. On the other hand, stronger students would acknowledge the error and relearn the concept. (Affective) Hazard 2. Weak students are lack in training in abstract thinking and the ability to build cognitive structures from abstract ideas. (Cognitive) Hazard 3. Weak students are not skilled in computing and the tasks in compiling and executing programs are already too challenging. (Cognitive) Hazard 4. Weak students do not have already owned the needed background knowledge. There is no basis for constructing new knowledge. (Cognitive) Hazard 5. Weak students are not resilience in knowledge construction, and they have entrenched habit to apply a mental model in building new concept even if the model is already shown to be nonviable. On the other hand, stronger students are more flexible and have greater readiness to refine existing models. (Affective)

3.2 Guideline 2: Concept-Building-First Jargon-Last Technical terms or jargons also have the uncanny ability to inappropriate wrong mental models in students. For examples, showing the terms escape sequence, recursion, functions, etc either make no sense to novice students at all, or worse causing students to make an incorrect presumption. Students could completely misread the instructions or explanations that follow (e.g. keep thinking functions as mathematical functions). A programming course should introduce the concepts using examples first, before introducing the technical terms that label the concepts. While using section headings or lecture titles is inevitable, effort should be made to clarify terms that known to cause problem (e.g. tell students not to associate program functions with mathematical functions immediately after the title is introduced). This could delink the association with inappropriate base models during knowledge construction.

3. Perform Approach for Weak Programming Students To save the weak students, we reduce the threats of these hazards. We will not deal with Hazard 2 because we still want a conventional programming language in our first programming courses. For all other hazards, we have inroads – The SIGCSE Bulletin

3.3 Guideline 3: Constant Repetition Constant repetition of examples illustrating a concept is needed for the construction of viable mental models. Multiple examples can be designed with small variations, which serve to highlight the common elements of the 74


Reviewed Papers 4. Discussions and Conclusions We applied the above guideline in the development of a C programming courseware for weak programming students. The courseware has been offered to students of an introductory C programming course for two years with very positive results. The courseware has an online version and a classroom version, both containing a set of lessons. In each lesson, students complete a set of targets, which contain examples, exercises, and instructions. The classroom version consists of sets of PowerPoint slides, with which a group of students use under the supervision of an instructor. The courseware initially offered 8 lessons covering the fundamentals in programming such as variables, selection, repetition, arrays, and strings. The effectiveness of the Perform approach in saving weak students is still being measured. We have so far collected some positive indicators and they are briefly summarized in the following. Survey Feedback. Most students indicated that their confidence in programming had improved due to the Perform approach. Of the 15 students indicated their confidence in programming was low at the beginning of the course, 13 of them reported that their confidence has significantly increased. Written comments from students also included the program is very useful, and thanks for alternate help. Observations on Student Work. Our observations on the assignment work and examination scripts showed that pass borderline students were more able to write simple programs (with selection and repetition structures) than the previous years without Perform. Assessment. The pass borderline students' performance in examination has significantly improved. The number of fail students has dropped by around 40 percent. Topics of Discussions. Significantly fewer discussion messages were about programming fundamentals in our online learning discussion forums compared to the years without Perform. Interviews. Students asked on their perception of Perform reported that they could make progress in the course after joining the classroom version of the Perform courseware. Some of them moaned that the Perform courseware had not covered more advanced topics like recursion and linked-lists. We see this as a positive sign that these students could progress to a position for more advanced topics.

concepts and peripherals not relating to the concepts. A useful exercise is to encourage students to identify the common features and later to spot the differences in those computer programs. 3.4 Guideline 4: Readiness in Concept Construction Knowledge construction is recursive, therefore ensuring students to have the necessary background knowledge is important. Students are considered ready if they have at their disposal and they have identified the appropriate mental models as the basis for knowledge construction. Instructors of a programming course would have no control over the past learning of the students. Therefore considering all prior mental models about computing and programming owned by the students are non-viable is a conservative but effective measure for weak students. In addition, sequence the topics carefully by making sure necessary prior knowledge is introduced beforehand is necessary (e.g. the process of compilation is described when pre-processor directives are introduced). Avoid leap of faith with small incremental steps in the sequencing of materials. 3.5 Guideline 5: Building a Repertoire of Key Programs Building a repertoire of carefully selected key programs allows students, especially weak students, to readily recall and apply constructed concepts. Writing a program from scratch is challenging for all students, but a memorized program could provide an easier starting point. Rote learning is often criticized, but in the case of weak students memorizing key programs and program segments can consolidate viable knowledge construction. 3.6 Guideline 6: Programming without Compilers The editing, compilation, and execution cycle can drain away the patience and confidence of weak students. Failure to compile a program is also frustrating. Many students would feel unable to deal with the cryptic compilation error messages. Perfectly correct example programs could still cause problems with careless mistakes like pressing a wrong key. Programming exercises for weak students should, at least in the initial stage, make the students to stay away from compilers or other integrated development environments. An easy-to-implement replacement of paper and pencil or their electronic equivalences could be used instead. The execution outcomes of example programs are illustrated by screen dumps and elaboration. Students tackle exercises and write programs on paper, and then compare the work with printed solution. Paper and pencil programming creates a low risk environment for weak students. It also reduces the latency in obtaining feedback to their programs and facilitates more efficient learning.


The development of the Perform approach and the guidelines was significantly influenced by the Suzuki Method in mass violin education. In fact, all the six guidelines given above have a similar principle in the Suzuki Method. The founder, Suzuki Shinichi, observed that no child would fail to learn the mother tongue, and with a proper method everybody could play violin. We come to believe that the cognitive aspects of the Suzuki Method are also rooted in constructivism, and it requires 75


Reviewed Papers further work to find out. Please refer to [5] for details of the Suzuki Method. The Perform guidelines are language independent. We have also developed a Perform courseware for Java programming. We found that from the Perform perspective, Java is substantially more complex to teach and learn. Constructivism could provide an interesting

perspective to the debate of C vs. Java as the first programming language. The approach of tight control the mental model construction process may lead to the view that creativity and innovation is discouraged. Even if this critic is true, we argue that creativity and innovation are luxuries for weak students. Our aim is to help students getting started on programming. These luxuries could come next.

References [1] Ben-Ari, M., Constructivism in Computer Science Education, Journal of Computers in Mathematics & Science Teaching, 20(1), pp. 45-73, 2001. [2] Blackwell, A.F., What is Programming? In Proceedings of 14th Workshop of the Psychology of Programming Interest Group, Brunel University, 2002. [3] Boyle, T., Constructivism: A Suitable Pedagogy for Information and Computing Sciences, In Proceedings of 1st Annual Conference of the Learning and Teaching Support Network Centre for Information and Computer Sciences, University of North London, 2000. [4] De Boulay, B., Some Difficulties of Learning to Program, Journal of Educational Computing Research, 2(1), pp. 57-73, 1986. [5] Hermann, E., The Suzuki Method: A Philosophy for Life Education, Warner Brothers Publications, Oct 1995. [6] Hadjerrouit, S., A Constructivist Framework for Integrating the Java paradigm into the Undergraduate Curriculum, SIGCSE Bulletin,

30(3), pp.105-107, 1998.

Ask a colleague to join

SIGCSE


76
