Contextualization of Programming Learning: A Virtual Environment Study

Abstract


In this paper, it is presented a study concerning about the use of the three-dimensional virtual world Second Life (SL) to visualize and contextualize the learning of computer programming. SL allows students to use avatars to create 3D objects and program their behaviours, process data, and interact with external servers, using Linden Scripting Language (LSL), a language with C-like syntax and a state machine. Scripts can execute concurrently, and several students can simultaneously work over the same object and/or script. Through action research, we explore and analyse the potential of SL for teachinglearning introductory computer programming in computer science undergraduate courses. We believe this virtual environment has potential to help students, since it presents an immediately visual feedback of the program execution.


INTRODUCTION

Many software tools have been built and tested with the main goal of improving teaching and learning activities, and the subject of computer programming is no exception. Nevertheless, teachers have continued to seek new ways to overcome difficulties met by novice students when initiating the study of programming concepts. Recent technological developments raise new opportunities in the educational field, such as the three-dimensional (3D) virtual world which provides educators an accessible means of creating a rich and compelling 3D context for situating learning, communicative tools to support discourse and collaboration [1]. However, comprehensive academic research about the use of these environments as a platform for teaching/learning computer programming is lacking. There has been some recognition in the academic literature about the benefits for the learning of programming derived from visualization [2], contextualization the study [3] and the use of games [4] but not the use of 3D virtual environment as platform to support programming learning. Hence, the aim of our study is to develop a framework for the use of a 3D social virtual world - Second Life (SL) - as platform for teaching and learning introductory computer programming in Computer Science (CS) undergraduate courses, based on meticulous academic research [5]. Essentially, we propose teaching introductory computer programming using SL, i.e., replace traditional language-development environments altogether by the SL environment. We have done so using SL's internal scripting language, LSL, albeit the features of the language itself are not a focus of study. For our research we employed an iterative action approach to analyze the teaching and learning process. This paper is divided into four parts. First, our motivation and related work is outlined. Then, the project methodology of focus groups is described. Finally, the findings and implications are discussed and possibilities for further research are identified.


MOTIVATION AND RELATED WORK


Learning how to program a computer is a difficult and demanding task. To become good programmers, students have to acquire several skills far beyond the syntax and semantics of the underlying programming language [6]- [7]. Students need to know how to solve problems and learn to elaborate algorithms, which make the computer programming learning process difficult. In fact, many students experience difficulties which result in high levels of failure in introductory programming courses typically taught in the beginning of computer science studies. Several research studies can be found concerning the causes of this failure [8]-[9]-[7]. One of the reasons mentioned is that many students entering their first programming courses are not prepared to think. In their previous college studies, they were generally exposed to a numeric computation that they didn’t have problem solving abilities [10]-[11]-[12]. Even the students, who have adequate problem-solving skills and are able to construct an algorithm for a given problem, present difficulties in pass that algorithm in an appropriated programming language [10]. Another reason for failure is that students claim that they don’t like programming because they have some difficulties in understanding even the most basic concepts of programming [6]-[10], such as variables, data types or memory addresses because these abstract concepts don’t have an equal representation on real life [10]. In addition to these difficulties, the traditional teaching method, often based on lectures and specific programming language syntaxes, fails a lot of times in what concerns to the students’ motivation in getting involved in meaningful programming activities, as Lethbridge [13] said “In no other discipline is the gulf between best practice and typical practice so wide.”

Visualization has been proposed as a way of reduce students’ difficulties. Several studies have been published trying to evaluate how visualization could help programming learning and which type of visualization and accompanying material are more effective [14]-[15]. Although it is possible to find studies with contradictory conclusions, it is also probable to find interesting suggestions and comments. For example, Hundhausen [14], in his visual feedback study, concluded that, at least in the case of novice imperative programming environments, the benefits of delivering a continuously updated visual representation of a program’s execution may fail to justify the substantial costs of implementing such feedback. Andries van Dam [16] defends that visualization and visual tools in learning help students to understand better the concepts because physical, spatial or visual representations are easier to retain and manipulate. Having an immediate display of the results of an action, students can find out at once if their idea is right or wrong. If it is wrong, in that case they have to correct, rethink their solutions and consequently this will stimulate their critical thinking [4]-[17].

Papert’s LOGO [18] language creates a mathematical world in which principles of geometry are visible. LOGO offers students the opportunity to create a line drawings with an electronic turtle displayed on a screen. In this environment, users can receive an immediate feedback about their programs, easily determine what has happened, quickly spot and repair errors and can experience creative satisfaction. Karel, The Robot [19] uses the same principles, and it is a programmable visualization software robot. The robot executes a sequence of commands that the user has written as part of a program moving about two-dimensional grid. Alice is a 3D interactive graphics programming environment for windows [20]. It is also an object-oriented by writing simple scripts which its users can control object appearance and behaviour. The benefits of using it allows students to be involved and at the same time have the ability to develop an intuitive understanding of basic concepts in a visual feedback environment [21]. These results influenced some of the opinions we have had when we think about using 3D virtual world Second Life (SL) as an environment to teaching / learning a programming language. Before we proposed the utilization of SL to our students and colleges, we felt the need to do a study with the aim to explore the viability of this environment. In the next section we will present the experience that we have been developing.


DESIGN AND METHODS

The main objective of this study is to find out if and how could SL be used as a platform for teaching / learning the imperative programming language paradigm that is commonly taught in college-level computer science courses. For this purpose, we have employed action research (AR) methodology, that is, a cyclical process approach that incorporates the four-step processes of planning, action, observing and reflecting on results generated from a particular project or body of work [22]. This choice was made in view of two main advantages of AR [23]: it allows us to study a problem while introducing controlled changes, with the aim of discovering how to improve the processes of learning and teaching [24]; and it provides the researcher with a large degree of flexibility, something of great importance when acting within an evolving information technology project concerning a problem about which little was known beforehand [23]. The first action research cycle started by planning a model for teaching introductory programming concepts in SL. To that end, it was necessary to make a preexploratory research and pre-observation with the goal of identifying problems and planning actions [25]. Initial plans were formulated, and actions for their prosecution were devised and implemented. While the action (teaching-learning) took place, results were monitored for reflecting later on. The data collected for the reflection step of the action research methodology was based on daily session reports, classroom images and questionnaires. The reports, written down by the teacher-researcher at the end of each session, describe what happened during the class, indicating all the critical incidents and its implications. Classroom images (screenshots) have been taken in order to assist the teacher to review the lesson when necessary, such as when a critical incident had happened. Questionnaires with open questions concerning the learning / teaching method were presented to students at the beginning, middle and end of the process, to provide further information on the learning process. These elements are used as a tool to adjust and improve the learning / teaching approach. The final step in the first research cycle was reflection upon the outcomes and based on them planning the next cycle. This goes on until the reflection of a cycle showed that the problem was then solved or level of knowledge achieved is fixed, the study was concluded and a report prepared [23]. In this study we have made a pre-exploratory research, a first and second cycle. The pre-exploratory research took place during the second semester of the academic year 2006/2007 and the first/second cycle of action-research append in first semester of the current year (2007/2008)

I .Participants

Our participants are computer science students from the University of Trás-os-Montes e Alto Douro (UTAD), in Vila Real, Portugal, and of the Higher School of Engineering and Management (ESTG – Portugueselanguage acronym) of the Polytechnic Institute of Leiria, Portugal, as elective alternative assignments on the compulsory subjects: Laboratório de Informática I of the 1st curricular year (Lab I); Laboratório de Informática II (Lab II) and III (Lab III), of the 2nd curricular year (at UTAD); and Projecto I, (at ESTG). In all cases, these subjects have their main aims to allow students to develop a semester-long project, to improve programming skills. We had three types of students: a group of beginners (group A); a group with some knowledge of programming (group B); and a group experienced in programming concepts (group C).

The A-group students, at the UTAD, were enrolled in the 1st year, 2nd semester, at an initial stage of learning how to program, even though they had been exposed in the previous semester to introductory aspects of the programming, in about 30% of two subjects (vd. table 1). The project made in SL was the first contact with a programming project (not just an exercise) for these students.

The B-group students were more advanced in learning how to program: at the UTAD, they were enrolled in the 2nd year, 1st semester, and had studied in the previous semester introductory aspects of the C programming language and developed a command-line project in C, and while participating in this research they were also taking a course on object-oriented programming in C++. At the ESTG, students were enrolled in a post-secondary technical course (CT) and had previously studied C programming (vd. table 1). The project developed in SL was their first project (i.e., not just an exercise).

The C-group students, at the UTAD, were enrolled in the 2nd year, 2nd semester, and thus at a more advanced stage of learning how to program: they had completed courses in C and C++ programming, and developed a command-line project in C++ (vd. table 1). Although still requiring teacher support often, these students had already some autonomy in using and studying programming.

In the exploratory research participated 5 students from group A and 4 students from group C, in both cases from UTAD. In the first and second action-research cycle, students were only of group B (10 students from UTAD and 6 from ESTG).

II. Materials and tasks

All participants worked on Pentium IV computers running the windows XP operating system, with 1 GB of RAM and

somewhat limited bandwidth. We proposed a project for students to develop, i.e. we specified what kind of object should be devised, including features and behaviour, and students had to construct objects following thisspecification.

II.I Programming environment

The programming environment was SL itself, not any offline editor. SL is a persistent on-line 3D virtual world conceived by Philip Rosedale in 1991 and it is publicly available since 2003 [26]. It allows large numbers of users to connect, interact and collaborate simultaneously at the same time and (virtual) space. Figure 1 shows a typical programming session in this research: we can see 6 avatars on black rugs (students programming) and two other – teachers’ avatars.

SL programming is done with a scripting language named Linden Scripting Language (LSL), which has Cstyle syntax and keywords. 3D objects created in SL can receive several scripts that are executed concurrently. Each script has its own state machine: program flow is sequential, but structured by triggering events and responding to them (through either environment interactions or programmatic components), besides common methods from imperative programming, such as procedures and flow-control primitives. The programmer defines the states of each state-machine and how/when to switch state. The language’s programming libraries include functions for communication with external servers: sending and receiving e-mail, XML remote procedure calls, and HTTP requests and responses. SL enables synchronous collaboration among students because the system permits two or more avatars to edit the same object and share the same code while programming it. Figure 2 presents two avatars editing the same object (a car): left window shows the car’s contents, one being a script that is opened by double-clicking. The script code (figure 3) collects the name of all cars nearby and shows them to the car’s owner (function listProdut ).

III.II Procedure

The project was presented to all students in the first session, after which some students volunteered to participate in this research. From this point on, they formed groups of two elements and developed their projects inside SL, collaborating with each other. Teachers and students met in-world once a week, for about two hours, to keep track of students’ progress, exchange ideas and make suggestions. Face-to-face meeting did not take place, because the teachers-researchers were in Leiria and the students in Vila Real, 270 km apart. Once a month we meet us at Vila Real to talk about the project.

The general procedure for a given virtual world sessions was as follows. Upon arriving at their virtual lab section, students inform the teacher (on-line), what doubts they may had and what they had been done in the project, since last section and then they continued their work. When students had some difficulty about the code they had implemented, they shared it with the teacher, so they could observe and at the same time find out what was wrong and follow the teachers’ indications/instructions. In this way, the students corrected the code and went on. At the beginning of a lab session, the teacher explained the concepts that students had doubts and stimulated them to find out the solution to their problems. At the closing of the session, the teacher said what they have to do during the following week.


PRELIMINARY FINDINGS


In the pre-exploratory research several difficulties were found:

Teacher’s perspective:

1. Managing communication amongst participants – a public chat was used to communicate and when there were more than two people talking at the same time, which turned it difficult to understand who was saying what;

2. Spatial arrangement of student avatars - students were disperse on the lab space, so teacher avatar had to move very often near one group of students to observe and explain the doubts that they might have and then move again around to another group. This way, teacher might lose the notion of the global class.

3. Discovering students’ difficulties during selfstudy - Outside the weekly guidance session, the students kept on developing their work and in the following lesson, they could tell the teachers the difficulties they had faced and present what they had already done. For a better guidance, it would be useful to have a mechanism that could inform the teacher, by email or another outside system, about what the students had done throughout the week, the difficulties they had felt and attempts to overcome them.

Students’ perspective:

1. Difficulties using the SL interface – students felt some difficulties in the use of the SL editor, for instance, how to link, copy or to line up the objects.

2. Understanding compilation errors and LSL semantics - students who were in the beginning level of the study felt some difficulties to understand the LSL semantics and deal with the compilation errors.

3. Selecting adequate library functions for object control- The biggest/greatest difficulty felt by students in advanced level consisted in selecting the functions to use and implement one kind of functionality. By reflecting upon these problems, we devised a first structured approach to prevent, minimize or tackle them, forming the basis for the first cycle of action research. During this cycle, different computer classes (B group from UTAD and ESTG), employed LSL/SL to develop two kinds of projects: programming motions and behaviours, and more traditional text data processing. In the second cycle, we have done some changes on the projects proposed to the students, namely in the introduction of a more traditional text data processing, a graphical component and in the other project a text data processing. In this way, we intend to observe the students’ reaction, i.e. if there is a change on their behaviour and motivation.

The 1st and 2nd problems reported in pre-exploratory research, in teacher’ perspective, were completely solved. To communicate, we made the following procedure: a public chat has been used only by a teacher to explain contents or give advices to all students; a private channel called instant message has been used by the teacher and students to communicate individually among them. Students said they liked this way of communicating because they felt they had a private teacher and could put their doubts without feeling embarrassed to be lagging in relation to the others. In the teacher’s point of view, a deep connection was set up between teacher and pupil and that is not so easy to achieve in traditional classes. Students, in the virtual lab session, were distributed around the teacher in areas of work that were defined by a black rug. In this way, and because of the communication mechanisms that were used, the teacher doesn’t have to move around and doesn’t lose the overview of the class. For the 3rd problem, we tested a solution but it didn’t work. So,we are still looking for a better answer to it.

The problems found in the students’ perspective were partially solved. To the students from A and B groups, it was decided that they should begin with simple examples that they had to try and modify. Every time they had difficulties in understanding it, some explanations were made in each part of the code. Therefore, students could understand what these small programs could do and the objective of each one. According to the personal experience of the programming teachers and by the literature read in this area [10], it is known that this situation is difficult to reach when students learn to program in traditional environments, as command line for C compilers, where the students generally feel great difficulty in perceiving the programming objective. A particular important aspect in programming learning is the students’ reaction to the compilation errors [7]-[3], which are inevitable in the learning process. In group C, the students corrected the compilation errors whenever they happened without the teachers’ help, whereas the group A and B, the students found themselves without knowing the reason why it occurred and didn’t know how to correct it as well. So, they need the teacher’s help to correct the problems. Through questionnaires review and by the conversation between teacher and students, it has been remarkable that: most students do have a positive or neutral attitude towards graphics richness of SL, but a minority dismisses it as “unserious,” “awkward,” or “complex”. Students learning how to program by programming physical interactions in SL (e.g., making a dog follow you and obey your voice command) are typically motivated. Students, who focused primarily on non-visible techniques such as data structures and string processing, benefiting from the environment just for enhanced context and not a source of feedback for programming behaviour, did not seem to exhibit any motivational advantage over students who employ a traditional console-oriented (text-only) approach.


CONCLUSIONS


This study has not finished yet. We are still working with one more group of students. The current findings from these efforts indicate that 80% of participants had a bad experience in learning a programming language and because of that they want to try a new form of learning. This shows a few dissatisfaction by the way students learn a programming language, Lethbridge [13] refers the number of students in computing disciplines have decreased in U.S. since 2000, and points out some reasons for that such as: young people are so immersed in computers that they do not see the excitement to them any more and the stereotype of the ‘nerd’ coding all night with no social contact, leave the students avoid these areas. With SL, we observed the opposite: the students are not without social contact when programming and they are excited. Two events have impacted students’ engagement that were: we have a student that received a proposal by an avatar in SL to buy his programming assignment, not as a violation of the student’s conduct but as a sanctioned exchange of virtual commodities; another student received a professional proposal to provide SL programming services for a company. Scripting, we learned, is a marketable skill in SL even at an introductory level. By deploying our students in a publicly accessible virtual world, thus, we inadvertently exposed them to the powers of an authentic microeconomy, and these social forces serendipitously contributed to our students’ “on-the-job” engagement in developing the very core skills targeted by our experimental unit.

Throughout our study, we observed that students are more interested and motivated in learning, so we are in tune with Lethbridge [13] when he says it is necessary to improve the education of software engineers. This study is a first step in that direction because the students who are studying in a traditional way feel unmotivated and don’t understand the reason why they have to learn writing code. Morgado [27] points out that SL, a cutting-edge technologically advanced 3D immersive environment, may harbour opportunities for powerful “back to basics” learning of introductory programming, in terms both of content and context: content - SL coding employs simple devices and practices, without complex development environments or complex compiler errors, with immediate perceptual feedback; and context - beginners’ applications are quite similar in look and feel to experts’, as it was the case in the old days before the graphic users’ interfaces. As future work and research to be developed, we point out the need to find out an automatic mechanism that follows the student in the world, answer their questions and clarify their doubts when the teacher is not present, at the same time record all this and send it back to the teacher. So, the teacher could follow the student’s progress / effort and help him / her in a more effective and direct way. We also intend to develop a blackboard inside the world so the teacher can write quickly his / her ideas and share them with the group.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • Twitter
  • RSS

Affective Aspects in Learning and Teaching Programming

Abstract

Learning programming evokes strong emotions in people. These emotional responses can be either positive or negative. In this paper we start by looking at how we as educators can utilise these responses. The affective domain in education focuses on the feelings associated with learning. We describe some traditional educational theories on affective education and how they could apply to learning programming. We argue that affective issues are important and educators should be aware of them. One of our aims is to see if there are practical ways in which we as educators can increase the level of affective attainment of students and in so doing improve their cognitive development in programming.

Introduction

Anyone who has programmed is aware of the “highs” associated with success and the “lows” associated with a program that will not work. These emotions can often be extreme (we look at some examples of such extreme emotions in the following section). In this paper we are not only talking about these emotional responses, but also the broader issue of how programmers feel about programming, such as to what extent they are willing to accept or value a new programming concept.

Our aim in writing this paper was to attempt to develop some understanding of the dimension of
feelings in learning programming. There is clearly a link between achievement and feelings: if we
succeed, we feel good and this encourages us to succeed more. There is also a reverse link. If we
feel bad about a subject this can cause a major block to success. In a study of a CS1 course, McKinney & Denton (2004) showed that affective factors including interest, perceived competence and value were significantly correlated with course grades. We therefore ask whether there are ways in which we can influence learners’ achievement and therefore their feelings and whether there are ways in which we can influence learners’ feelings and therefore their achievement.

In this paper we firstly look at the topic of emotional responses in the context of learning to program. The aim is to see whether we can use these responses to achieve educational objectives. We then look at affective objectives as defined in the taxonomy of Krathwohl et al. (1964), and see how these can apply to learning programming. Finally we discuss the close relationship between the affective and cognitive domains, and how this interdependence can be used to facilitate attainment of both cognitive and affective objectives.

Emotional responses

Students often experience strong emotions when learning to program. The following two quotes were extracted from a journal written by a school teacher learning to program in a new language (quotes marked with an asterisk have been translated from Afrikaans into English):

Saturday 27/09/03: “Somewhere there is a mistake in my Tree class’s setRate method, but I can’t find it. I feel so stupid!!! And frustrated!!!” *
Sunday 28/09/03: “What a wonderful feeling to eventually succeed after so much struggle and frustration – now I feel so CLEVER!!!!!” *

Here we see a teacher’s emotions swinging from one day to the next from feelings of frustration and stupidity (punctuated by 6 exclamation marks) to the wonderful feeling of being clever (punctuated by 5 exclamation marks!). Similarly we found most teachers’ journals littered with emotive words and phrases like: “I feel terribly pleased with myself”*, “I am ready to throw in the towel”, “It gives me such a kick”*, “learning another language can be a painful experience”, “the fact that it did what I wanted was a miracle”, “I HATE Java with a passion”, “Java is like a drug. Certain people just get hooked!!”

This kind of emotional energy is evident in our learners. Do we as educators understand this energy and are there ways of harnessing it?

Positive emotions

In this section we look at the “highs” of programming. The positive emotions that result from success in programming can serve as an important motivator for further success. As the following teacher expressed: “What made all the trouble worthwhile was when I managed to get
something right. Then I would tackle the next section eagerly and enthusiastically”*. What is it about programming that makes it so enjoyable? If we understand more about when and why these emotions arise, it could help us to ensure that there are sufficient opportunities for motivation at different stages of a course.

In the “Mythical Man Month”, Fred Brooks (1982) gives a number of reasons as to why he thinks programming is fun: “First, it is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design.” Students seem to derive great pleasure from successfully writing a program which performs a task which they have devised themselves. For example, the following teacher (after having been shown how to do simple textual output in Java) decided to draw a tree shape using stars. He wrote the following in his journal:

“I am thoroughly enjoying learning about Java… I think what influenced me was when I wrote my very first program. It went something like this [code listing with 4 output statements which draws a tree shape] … the fact that it did what I wanted was a miracle. The fact that I understood what I had done was an eye opener to me. It demystified computers for me and I was immediately curious as to what else I could do”

The fact that the program did what he wanted he saw as a miracle. This supports Brooks’ idea that the adult enjoys building things, “especially things of this own design”. To keep motivation high, we should therefore build in enough opportunities for students to devise and implement some of their own ideas at appropriate stages of a programming course. We also need to ensure that these ideas are manageable, because success (the program working) is critical to the resulting positive feeling. Incorporating simple graphics or the use of colour at an early stage can be especially motivating for students – probably because the results of the program running (which is what students need to see) are more dramatic.

The second point made by Brooks is:

“Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful.” To fulfil this desire to develop programs that are useful to others, we need to give students problems that are relevant (or could lead to problems that are relevant) to keep motivation high. This couldfollow on from the simpler “irrelevant” problems which initially only satisfy students’ need to make something that works, as observed by the following teacher: “With graphics, learners become excited when they learn how to draw houses, but they soon start to question the application value of these programs.”

For interest, we list the remaining points made by Brooks:
Thirdly, “… the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning.” He equates this to the fascination of the pinball machine and the jukebox mechanism.

Fourthly, is the enjoyment of continually learning, because programming is generally nonrepetitive in nature.

Finally, is the enjoyment that comes from “working in such a tractable medium”. From a pure idea, a programmer can produce a concrete program which produces visible outputs. In summary, the practice of programming has an inherent motivational quality which we as educators should use. Some of the ways of maximising motivation is to ensure that students achieve visible success with initial programs; they have opportunities for implementing their own ideas and they are given problems that are relevant or will lead to programs which could be useful to others.

Negative emotions

Unfortunately, not all experiences of programming are positive. Just as the “highs” of programming can be very motivating, so the “lows” can be extremely demotivating. One of the reasons why programming can result in such extreme negative emotions could be because it requires us to perform perfectly (Brooks, 1982). The smallest, most trivial error can result in a program that does not work at all.

These “lows” of programming cannot be avoided. As educators we need to try to equip student with coping mechanisms. Skills such as debugging skills, being able to collaborate with others, problem solving strategies, etc. can help students to move out of the doldrums of programming.
We can, however, do more than this. The nature of programming can present us with the opportunity to develop affective competencies such as selfcontrol and confidence (Elliott & Peelle, 1975).

Programming is an environment where both success and failure occur on a regular basis. When a
program does not work (failure), things will not improve unless the programmer does something
about it. It also does not help to “take it out on the computer”, since the computer does not respond. In this way the programmer can learn self-control and that he/she has to take responsibility for improving the situation. For this learning to take place, the educator may need to act as the facilitator:

acknowledging and discussing feelings, so that students can develop the consciousness of self and
control over emotions. If students can learn to deal with their emotional reactions to failure in programming, it could help them to deal with failure in their own lives in more mature ways. So we see that maturity in dealing with emotions is an affective outcome that can be developed because of the nature of programming. Are there other affective objectives which we should be aiming to achieve with our students? In the next section we look at affective attainment in general, and see how this applies to programming.

Affective objectives

There are affective objectives besides emotional maturity that we strive for in teaching programming. For example, we want our students not only to understand concepts, but to value them and apply them because they believe in them. Krathwohl et al. (1964) proposed a taxonomy of affective educational objectives which specifies levels describing feelings, emotions and degrees of acceptance in learning. This taxonomy was developed subsequent to the well-known Bloom’s taxonomy on the cognitive domain (1956). Although cognitive objectives were generally considered to be the most important component of learning, and the easiest to evaluate, many educators affirmed the importance of affective objectives in teaching and learning. Krathwohl, Bloom and Masia therefore set about specifying a taxonomy for the affective domain equivalent to Bloom’s taxonomy of the cognitive domain.

The affective domain Krathwohl’s taxonomy of affective objectives describes a continuum, from merely being willing to receive and accept new ideas, through to constructing a world-view of beliefs and values, in the form of a hierarchy of levels. Note that this hierarchy does not specify levels of intensity of emotional responses; Krathwohl et al. describe it as a continuum of increasing internalisation. In other words, the levels describe degrees to which learners attach personal value to ideas. Each of the levels are divided into sublevels. In the following table we describe these levels and their sublevels and provide an example relevant to object-oriented programming.

Students can be at different affective levels at different stages of learning. For example, consider
the following comment made by a teacher: “OK, I have been naughty. I suppose it is because I have built up this aversion for Java. I walk past the books and the computer and just keep going; I feel I just cannot any more!”. This teacher is not even on Level 1 of affective attainment. Her ‘aversion’ to the subject is forming an obstacle to her ability to receive the material.

As a further example, consider the following:

Students were given a problem to solve in Java which involved the user typing in any even integer and the program continually halving and printing this until the number became odd. One student’s program included the following comment:

// I am going to try to solve this
// problem in an object-oriented
// way. Change Ex9b to a class
// called Halve which is called by
// the main program below. I will
// also do method overloading. *

Although object-oriented principles had been introduced in this course, the student called the class “Halve”. This was a poor choice of name since it did not describe an object but rather a process. His application of method overloading was also flawed in that it resulted in duplication of code. What is interesting about this example is the willingness of the student to apply object-oriented ideas when not specifically required. This student was therefore at level 2 of affective attainment. Even though he did not fully comprehend object-oriented principles, he was showing a positive response through his willingness.

We have attempted to show that the affective taxonomy as described by Krathwohl et al. is applicable to learning programming. But should specific affective objectives be built into teaching programming, and if so, how can this be done? Affective objectives in programming As teachers of programming, we do not merely want our students to understand the concepts and principles of programming. We also want them to believe that these concepts and principles are worthwhile. When they have to work as programmers in their jobs, we trust that they will resist the temptation to produce quick-and-dirty solutions, even when they are under time or other pressures. We hope that they will gain personal satisfaction from writing good code. The only way that they will make good programming practice a personal issue is if they have internalized the concepts and principles and made them their own.

We can add affective objectives to the desired outcomes specified in the curriculum statement of our programming courses. For example, consider the following objectives:
• the student should become aware of the advantages of code re-use
• the student should develop an appreciation for good code
• the student should develop an attitude of positive self-criticism in order to debug code
/ produce better programs
Although these objectives depend on cognitive abilities, each expresses an affective aim. The keywords in this case are: “become aware”, “develop an appreciation” and “develop an attitude”.
Of course, to make the specification of such affective objectives meaningful, we need ways of
achieving them. One way this can be done is by utilizing the interdependence of cognitive and
affective objectives.

The link to cognitive attainment

In this section we briefly describe the cognitive domain and discuss its interdependence with the
affective domain.

The cognitive domain

Bloom’s taxonomy (Bloom, 1956) was developed prior to Krathwohl’s affective taxonomy. It proposes a hierarchy of cognitive educational objectives, each level representing a type of cognitive learning or understanding of increasing complexity. In the following table we briefly outline these levels and provide an example relevant to object-oriented programming.

Bloom (1956) divides each of the levels in this hierarchy into sublevels. We do not discuss the hierarchy (interesting as it is, particularly in its application to learning programming) and the sublevels any further in this paper. We refer the reader to Bloom (1956) for a more detailed exposition of what these categories represent and to Scott (2003) and Masterson & Meyer (2001) for examples of its application to programming. Although we distinguish between the cognitive and affective domains, this does not mean that we believe that human beings have them as separate faculties. This is supported by Scheerer (1954): “... behavior may be conceptualized as being embedded in a cognitive–emotional–motivational matrix in which no separation is possible. No matter how we slice behavior, the ingredients of motivation– emotion–cognition are present in one order or another”. The cognitive and affective domains are therefore simply different aspects of behaviour as seen from different points of view.

We now discuss the mutual dependence of cognitive and affective attainment, in particular affective attainment leading to cognitive attainment, cognitive attainment leading to affective attainment, and the alternation between the two. Affective attainment leading to cognitive attainment Krathwohl et al. (1964) state that one of the main affective ways of promoting cognitive attainment is by increasing interest and motivation. Students “are more likely to learn and remember material for which they have a positive feeling”. An affective stimulus is often necessary to open the door to receiving and understanding; to engage and draw the student into the learning experience. As we discussed in the section on “Positive emotions”, motivation can be increased through fun programming exercises (by using graphics, for example).

Apart from overtly motivational techniques, there are small scale affective objectives lower down on the hierarchy that are intimately connected to and even a prerequisite to cognitive development. The first level of the hierarchy of affective objectives is Receiving. The student has to have a positive disposition towards, not just learning programming in general, but also to the specific concept being dealt with, to be able to receive and understand it.

This means that if there are affective blocks preventing cognitive attainment, these need to be addressed before effective learning can take place. As discussed before, to motivate students, programming examples should preferably solve meaningful problems. If a student's immediate reaction to an example is “What does the program do?” and there is no answer besides “It illustrates the concept”, then the example will probably constitute an affective stumbling block to the student receiving the concept. Even if the example does solve a problem, but the student's first question is "But who would ever write a program to do this?" there is a danger of a negative affective effect.

Abstract or meaningless examples can alienate the learner from the concept being dealt with, especially when there is no handle to grasp and connect/relate the new concept to something which is already known or understood.

Cognitive attainment leading to affective attainment

Being able to apply programming concepts successfully has a positive affective outcome, as the following quote from a teacher shows: “With programming in general I find that what influences the pupils most positively ... is that they can see results of their labours and when they start to gain enough knowledge to be a bit creative then this motivates like nothing else.” Conversely, students’ failure to understand makes them feel negative towards programming: “The biggest problem for me is writing classes. Therefore I have a negative attitude towards programming with Java. But I know that once I understand classes, I might feel different about it.”

In a certain sense, higher level affective objectives can only be attained after the cognitive objectives of understanding and being able to apply concepts and principles. Valuing and believing in a concept or principle is a product of having understood and applied the concept or principle in various situations and needs time to develop. For example, we cannot hope that our students will believe in the power and usefulness of object oriented programming before they have understood what it is and how it can be applied.

Note that we are not saying that the development of desirable values is a guaranteed consequence of having attained certain cognitive competencies. For example, a student may fully understand classes and be able to write them when required, but might prefer to put everything in the main method when not specifically required to use classes. This would be because they don’t value classes (an affective goal).

Alternating attainment

Sometimes it is not easy to tease out which comes first: affective or cognitive attainment. They either occur simultaneously, or an instance of affective attainment at a particular level leads to some cognitive attainment, which in turn leads to affective attainment on a higher level, and so on. As Krathwohl et al. put it: “In some instances, the joint seeking of affective and cognitive goals results in [the use of] one domain as the means to the other on a closely-knit, alternating basis.”

As an example, consider the following scenario. Say we want our students to be able to apply the
concept of inheritance. (This represents a cognitive objective.) To attain this objective, a student first needs to be willing to pay attention to (i.e. receive) an explanation of inheritance (affective attainment level 1). This hopefully leads to some understanding of what inheritance is and why it is useful (cognitive attainment level 1). Only with some understanding can the student respond positively to further examples, seeking out instances of inheritance (affective attainment level 1) and testing them against her understanding to see if they match up, making adjustments to her understanding if they don’t (cognitive attainment level 2). A willingness to practically try out the new concept (affective attainment level 2) is needed before the student implements exercises using inheritance (cognitive attainment level 3). Satisfaction in her efforts (affective attainment level 2) is important in gaining the confidence needed to try further problems using inheritance (cognitive attainment level 3). Through the application of good examples, the student sees the power and usefulness of inheritance and starts valuing the new concept (affective level 3). Since the student believes in inheritance, she chooses to use it often and through this practice develops the ability to analyse when inheritance is appropriate to solve a problem (cognitive attainment level 4).

In this way the affective and cognitive stages feed into each other, with attainment in one domain acting as a stimulus for attainment in the other.

Conclusion

As teachers of programming we have a unique situation. Strong emotions are inherent in the practice of programming and we can use them. In this paper we have shown, through practical examples, how educational theory on the affective domain is applicable to learning programming. The affective and cognitive domains are linked:

attainment in the affective domain can act as a stimulus, or even as a prerequisite, to attainment in the cognitive domain, and vice versa. In programming this relationship is particularly important to understand because the associated emotions tend to be so extreme. As educators, we can utilise this link in our teaching by incorporating affective objectives in our programming courses.

References

Bloom, B. S. (Ed.) 1960. Taxonomy of Educational Objectives, Handbook I: The Cognitive Domain, New York: Longman
Brooks, F.P. 1982. The Mythical Man-Month: Essays on Software Engineering, Addison- Wesley Publishing Company.
Elliott, P.C. and Peelle, H.A. 1975. “Computer Augmented Teacher Training”, SIGCUE Outlook 1, si (January 1975):19-30, ACM Press.
Krathwohl, D. R., Bloom, B. S. and Masia, B. B. 1964. Taxonomy of Educational Objectives.
Handbook II: Affective Domain, New York: Longman.
Masterson, T.F. and Meyer, R.M. 2001. “SIVIL: A True Visual Programming Language for Students”, The Journal of Computing in Small Colleges 16, 4 (May 2001).
McKinney D and Denton, L.F. 2004. “Houston, We Have a Problem: There’s a Leak in the
CS1 Affective Oxygen Tank”, in Proceedings of SIGCSE ’04, Norfolk, Virginia, USA (March 2004), 236-239.
Scheerer, M. 1954. Chapter 3: Cognitive Theory, in Handbook of Social Psychology, Volume I. Cambridge, Ass.: Addison-Wesley.
Scott, T. 2003. “Bloom’s Taxonomy applied to testing in Computer Science Classes”, The Journal of Computing in Small Colleges, 19:1 (October 2003).
  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • Twitter
  • RSS

Problems of Learning Programming Language

Abstract

Novice students normally will fear of anything new like programming language. They are introduced with programming terms that they are not familiar with and are needed to visualize the processes that happen in the computer memory on their own. Weak students find this a burden and therefore end up memorizing the processes, without understanding them. This
situation will cause students to get low grades in their programming subjects. This research aims to insist students develop the foundational capabilities needed to become successful programmers, that will help them learn how to effectively analyze, design, and implement software systems. Focus will be on the first semester students taking Fundamentals of Programming subject from three different programs offered in MIIT-UniKL (formerly known as Unikl- IIM), namely, Diploma in IT, Diploma in Multimedia and Diploma in System and Network. Findings indicated that percentage of passes for algorithm is higher than programming. Several factors are identified as contributing factor to the difficulties in grasping programming concepts.


1 Introduction

In MIIT-UniKL (formerly known as Unikl-IIM), Fundamentals of Programming is one of the subjects offered to first semester students. Enrolled as either Diploma in IT, Diploma in Multimedia or Diploma in System and Network students, they cannot escape from taking that subject. Many students no longer view programming as central to the course and a substantial number of today’s first year undergraduate students find learning programming is difficult. Learning a new language and new set of problem-solving techniques, as in programming, is a complex activity (Chalk et al. 2003).

It can be seen that the previous academic performance of the students was not the main contributor to the failure. Therefore, we believed that the problem is due to something that is not done right during the process of teaching and learning this course itself. In this paper, we focused on whether mastering algorithm will contribute to the understanding of programming language.

1.1 Problem Statements

Currently in MIIT-UniKL (formerly known as Unikl-IIM), students undergo Fundamentals of Programming were assigned with 2 periods of class lectures and 2 periods of lab session. One period is equivalent to 50 minutes of lecturing or lab session. Previous examination result shows a poor performance of students for this subject. Some students need extra amount of exercise and explanation to cope with the subject. The students need to understand the key concepts of the subject in order to be successful. Therefore, for the purpose of evaluating these issues and providing guidelines, the following research questions and objectives were formed.

1.2 Research Objectives

The main objective of this research is to obtain factors that affect student low performance in learning programming subjects. To carry out the objective, the following sub-objectives are executed.

a. To measure the percentage of passes of two different programming concepts
b. To compare the percentage of passes from three different programs.

1.3 Research Scope

The study took place at MIIT-UniKL (formerly known as Unikl-IIM) and focuses only on first semester students. The students are from Diploma in IT, Diploma in Multimedia and Diploma in System and Network. Final examination answer scripts for subject Fundamentals of Programming were analyzed and discussed.
2 Background of Study

One of the main courses in first year study in most CS programs and related disciplines is still programming and learning programming seems to be a very difficult task for many students. Different aspects of the problem have been discussed, it has been pointed out that new programming languages are more complicated to learn and teachers should consider carefully what programming language to choose for novice programmers. Universities also have to consider how to assist students in their learning, because we need more young people in the field, both male and female students (Ásrún 2004).

In similar study, few students find learning to program easy. There are many factors that contributed to these deficiencies in programming skills. Less attention has been paid to the subject of programming itself, changes must be made to the when the subject should be introduce, who should be teaching, the suitable teaching style and the adequate support to students (Jenkins 2002).

The main focus is the staff per student ratios have climbed as a result and there is less time to support students to gain essential programming skills in their first year. Some of the problems of teaching programming to student are identified and point out that good use of tutorial groups and various mean of assessment help student to learn programming language better (Jefferies 2002).

Dunican (2002) discusses some of the fundamental problems encountered by student on first year computer programming courses. Most of the programming students do not have logic/problem solving ability prior entering first year. Different categories of novice programming student are identified and adequate pedagogical techniques must be utilized to guide the student. Teaching of initial programming is a significant pedagogical problem for computing departments. It is shown that by understanding the changing characteristics of computing students helps to identify their learning approaches and requirements. These findings are used to explain the rationale for the development and use of a virtual learning environment to support the learning of introductory programming (Allison, Powell & Orton 2002).

3 Methodology

The methodology as depicted in Figure 3.0 was used for the purpose of this study.

Figure 3.0: Methodology Used

This study was conducted in the July 2005 semester at MIIT-UniKL (formerly known as UniKL-IIM). The study was done on students of three different programs offered in UniKL, namely, Diploma in Information Technology (DIT), Diploma in Multimedia (DIM) and Diploma in System & Network (DSN). The data and fact-findings are done through document sampling. There are a total 29 student from DIT, 36 students from DIM and 26 students from DSN sat for the final examination for Fundamentals of Programming paper. Out of this total 20 students from each program were randomly selected as samples for this study.

3.1 Document sampling

Document sampling is one of the fact-finding techniques, which is used to capture information. According to Whitten et al. (2001), a good analyst always gets facts from existing documents rather than people. Final examination paper of Fundamentals of Programming subject from the selected samples was collected in the information gathering phase, analyzed in the data analysis phase and interpreted in the interpretation phase.

The analysis was done only for the final part of the examination paper. The final part of the examination question consists of two related questions. The first question emphasizes on testing students’ understanding on algorithm. While the second question is the implementation of the algorithm (writing a full program code) solved in question 1. Each question carries 10 marks and the passing mark is set to 4.

Figure 3.1 shows excerpt from the final examination question paper for Fundamentals of Programming subjects.

Figure 3.1: Excerpt of Final Examination Paper

4 Results and Discussions

4.1 Document sampling

The final examination marks document involved in this study was gathered and studied deliberately in order to get the actual criteria contributing to the problems stated in section 1.1 earlier. For the purpose of this study, the following were analyzed from the final examination samples:
1. Percentage of passes and failures (Question 1 and Question 2) for DIT
2. Percentage of passes and failures (Question 1 and Question 2) for DIM
3. Percentage of passes and failures (Question 1 and Question 2) for DSN
4. Percentage of passes (Question 1 and Question 2) for all programs.
5. Percentage of failures (Question 1 and Question 2) for all programs.

Table 4.0 presents the percentage of passes and failures from 20 DIT students. These values were obtained from final examination marks for question 1 and question 2 only. Figure 4.0 shows the comparison between passes and failures for each question.

Table 4.0: Detailed Percentage of Passes and Failures for DIT Students



Figure 4.0: Percentage of Passes and Failures for DIT Students

Table 4.1 presents the percentage of passes and failures from 20 DIM students. These values were obtained from final examination marks for question 1 and question 2 only. Figure 4.1 shows the comparison between passes and failures for each question.

Table 4.1: Detailed Percentage of Passes and Failures for DIM Students




Figure 4.1: Percentage of Passes and Failures for DIM Students

Table 4.2 presents the percentage of passes and failures from 20 DSN students. These values were obtained from final examination marks for question 1 and question 2 only. Figure 4.2 shows the comparison between passes and failures for each question.

Table 4.2: Detailed Percentage of Passes and Failures for DSN Students


5 Conclusion

The analysis that had been done to the collected data showed that percentage passes for algorithm problems (question 1) is higher as compared to programming problems (question 2). Though the percentage passes for algorithm is higher than programming segment, it indicated that student still lacks of knowledge to transform the algorithm into valid program codes. Through discussion, students have to spend more time in understanding the programming syntax and converting algorithm into working program codes.

Thus, it shows that the students really need to grasp the programming concept in order to excel in programming. In terms of percentage of passes, it can be concluded that DIM has the highest, DIT falls for second highest and DSN has the lowest among all programs.
From the findings, we can summarize that:
1. A proper training in teaching and motivating students is required
2. A method for teaching programming effectively need to be developed
3. A guideline for converting algorithm into program should be properly planned
4. Excessive written programming exercises should be given prior to lab sessions
5. Type of questions should not be mathematic oriented, instead it should bevaried.

6 Future Work

There are few matters such as students’ understanding and their perception on programming subject can be further studied. Different instructional styles can be explored and conducted to see if the performance of the students can be improved.

Hopefully, a set of instructional guidelines that can help to encourage students to perform better in the first programming course and to have a positive attitude towards higher level programming courses.

References

Allison, I., Powell, H. & Paul, O (2002). A Virtual Learning Environment for Introductory Programming. In Proceedings of the 3rd Annual Conference of the LTSN-ICS, Loughborough, U.K.
Ásrún Matthíasdóttir (2004), Learning objects in a multimedia interactive environment.The Codewitz project. International Conference on Computer Systems and Technologies – CompSysTech.
Chalk, P., Boyle, T., Pickard, P., Bradley, C., Jones, R., Fisher, K., (2003). Improving Pass Rates in Introductory Programming. Proceedings of 4th Annual Conference of the Learning and Teaching Support Network for Information and Computing Science, Galway, Ireland.
Dunican, Enda (2002). Making The Analogy: Alternative Delivery Techniques for First Year Programming Courses. In Proceedings of the 3rd Annual Conference of the LTSN-ICS, Loughborough, U.K.
Jefferies, Amanda (2002). Size Matter – Teaching Initial Programming to Large Groups of Students. In Proceedings of the 3rd Annual Conference of the LTSNICS, Loughborough, U.K.
Jenkins, Tony (2002). On the difficulty of learning to program. In Proceedings of the 3rd Annual Conference of the LTSN-ICS, Loughborough, U.K.,
Whitten, J.L., Betley, L.D & Diltman, D.C (2001). System Analysis and Design Method (5th ed) Boston: Mc-Graw- Hill Education.
  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • Twitter
  • RSS