Discussion

The results of the observations reveal similar patterns across the different student groups. At each university and over each academic session the graphs illustrate:

i. a rapid decline in Environmental errors; ii. a general reduction in Syntax errors over time; iii. a general increase in Schematic errors over time;

iv. infrequent Semantic and Strategic errors that pose significant problems.

The graphs also show large differences among Syntactic, Semantic, Schematic and Strategic errors towards the end of the observational period. The differences among the five categories for the University of Abertay Dundee in the session 2002-2003 are still evident but are less pronounced, although the streaming used to create a group of students with limited programming aptitude could account for this. Importantly, in spite of differences in teaching approaches at the two universities, significant differences in the size of the exercises posed, and year-to-year variance in cohorts, two patterns are evident. First, the relative trends of each of the categories are conserved across the study groups. This indicates that there is a consistent dynamic to the learning of programming independent of the teaching model used, as described in i) to iv) above. To further support that the observations reveal at least program formulation problems that are general to many programming exercises, results of the observations for program formulation are also consistent with other studies. As noted, Jadud (2005) undertakes a comprehensive study of syntax errors in Java and the range and type of observed syntax errors are consistent with those identified here. Further, the semantic errors identified at the two host institutes have clear overlap with those errors identified by Schorsch (1995) in Pascal, where for example misplaced ‘;’ and failure to update loop counters were recognised logic errors.

Secondly, more detailed analysis of the recorded dialogue for encountered errors reveals evidence that the root cause of a given error is located in one or more levels of knowledge. For example, the reduction in the number of syntax errors that the students are unable to solve towards the end of the module indicates that the students gain competence in the application of syntactic knowledge to formulate a program and are able to interpret compiler error messages without assistance. However syntax errors persist throughout the observation period, even when no new syntax is being taught. Further analysis of the observation records

reveals that some of those (persisting) syntax errors have root causes in more sophisticated levels of knowledge, and are recorded as syntax errors based on their manifestation and not the underlying level of the lack of knowledge.

A simple example of this is in the error ‘else without if’. This is observed to occur because of a failure to include any scoping braces in a program that by indentation reflects a multiple line if (true) block, i.e. a syntax error. The same error may occur when a semi-colon is placed at the end of the ‘if statement’, i.e. ‘if (condition) ;’ - a valid line of code in itself but a semantic error regarding the role of ; in a program. Finally the error may occur when an ‘else’ exists where no ‘if’ is present in the program, and this is a structural (schematic) level problem when the student does not use the complete selection construct in the solution to the problem, i.e. the conditional element of the selection is not present.

The collective review of the observed errors indicated that manifest problems can have root causes in multiple levels of knowledge. Here, four case studies drawn directly from the observation logs are described to highlight this issue.

4.7.1 Case 1

During week four of the observations at the University of St Andrews in the academic session 2002-2003 a student asked for assistance with the following problem:

“I’m not sure how to write the code for the header of my constructor.”

In this particular case, it was clear that the student understood that they had to write a constructor and they appeared confident that they understood the purpose of a constructor. The tutor asked the student what information they were passing to the constructor and the student listed a name, credit, total and balance. The tutor then asked the student what type of things they were and the student explained that they were a string, Boolean, int and int. The tutor then explained how the header of the constructor should be written, i.e. public Account (String name, Boolean credit, int totalling, int balance). The student had not asked for help with a compilation error, nor were they confused by the running of their program. The student understood exactly what they wanted to do but needed assistance with the syntax

formulation. This is an example of a problem in the student’s syntactic knowledge that has manifested itself as a strategic error (it could appear that the missing constructor meant the student hadn’t understood that this was a requirement of the question).

4.7.2 Case 2

During week three of the observations at the University of Abertay Dundee in the academic session 2003-2004 a student asked for assistance with the following compiler error:

‘cannot resolve symbol’ on a line of code that read robby.move();

The program required the instantiation of an existing class, Robot, used for teaching that was typically named ‘robby’. The tutor reviewed the student’s program and identified that they had failed to declare an instance of the Robot class. This mistake could have happened for two reasons: the student had simply forgotten to declare the object, or the student did not realise that object declaration was necessary and therefore did not understand its purpose. The tutor had to establish why the error had occurred before helping the student resolve the problem. The tutor told the student that the computer did not understand what ‘robby’ was, whilst watching the students face to gauge their reaction. The tutor then asked the student if they knew what robby was, for example was robby a dog. The student replied that robby was a Robot. The tutor further explained that the student had to tell the computer that robby was a Robot, and that the computer knew the commands that Robots could do, such as move but could only allow robby to do that command if it knew that robby was a Robot. The tutor then showed the student the relevant lecture slide from that week’s lecture, which demonstrated the objects instantiation necessary to use the robot class. Although this was a simple and common syntax error, it required reference to the lecture notes and an explanation of object declaration for the student to understand why the error had occurred and what was necessary to resolve the error. This is an example of a problem in the student’s semantic (operation of memory) knowledge, which has manifested itself as a syntax error.

4.7.3 Case 3

During week four of the observations at the University of Abertay Dundee during the academic session 2002-2003 a student asked for assistance with the following compiler error:

‘else without if’

This error commonly occurs if the student has included too many ‘}’ in their ‘if statement’ and has consequently closed it too early. The tutor reviewed the student’s code and established that this error had occurred because the student had written the else statement as part of a while loop. It was clear to the tutor that this had occurred because the student had no knowledge of the semantics of either construct and did not understand which construct was necessary to solve the problem. The tutor explained to the student the difference between a ‘while loop’ and an ‘if statement’, with reference to the lecture notes. The tutor then discussed the practical exercise with the student and asked which construct (an ‘if statement’ or a while loop) was required for the program. The student was now able to recognise that an ‘if statement’ was necessary. The tutor then helped the student write the appropriate syntax for the ‘if statement’. This is an example of a problem that manifested itself as a syntax error but required an explanation of the semantics of programming constructs. The student also needed assistance at the schematic level to select which construct was appropriate for the problem and then at the syntactic level of assistance to write the required code.

4.7.4 Case 4

During week eight at the University of St Andrews in the academic session 2003-2004 a student was observed to request assistance when their program was not displaying the expected output. The tutor asked the student to run their program and show the output. The tutor then reviewed the code and identified the source of the problem: the student had written number=min instead of min=number. The tutor explained to the student that in an assignment expression, the value on the right hand side of the equals sign was assigned to the left-hand side. The student was satisfied with this and did not need any further support. This was an example of a problem that had its root causes in syntax (the student not knowing the rules of