2.3.4 PRINCIPIO DE ÚLTIMA RATIO.

Program development spans all phases of the software lifecycle and tools exist to support each of these phases. However, most conventional, introductory courses focus on implementation (Robins, 2003). Further, the problems studied are so small that structured problem analysis in particular is not needed. Additionally, the practice of building programs is an appropriate starting point since it involves a clear process of engagement to motivate students through small-scale software development. Consequently, the majority of tools exist to support the design or implementation phases, with the most sophisticated tools addressing both, and here the focus is on these.

FLINT, by Ziegler and Crews (1999) helps students develop problem-solving and critical thinking skills. Through the use of flowcharts students work in a reduced syntax environment. It is clear that the focus of FLINT is to help students with problem formulation as opposed to program formulation. Importantly, FLINT has been developed within a dedicated programming module aimed at non-computer science students. The purpose of the module is to teach problem-solving skills and programming is chosen as a vehicle to teach these skills. However, the aim of the majority of programming modules is to teach programming, and primarily to computer science students. Although problem formulation is critical these students still need to be taught program formulation, which cannot be done in a reduced syntax environment.

For support at the implementation stage, there are many tools and here we discuss in chronological order CAP, Datlab, InStep, the toolkit from Lang, Expresso and CmeRun. CAP (Schorsch, 1995) is a self-assessment tool that allows students to check their code for syntax (for example a missing semi-colon), logic (for example failing to update a loop variable) and style errors (for example failure to indent nested statements). CAP recognises the need to replace compiler error messages with more user-friendly ones for the novice programmer. CAP also recognises the common semantic mistakes that novices make, for

example missing loop counters and the benefit in providing support for these errors. Schorsch (1995) acknowledges that students could become dependent on this level of support and recognises that a tool should give less directed support as the module progresses.

Datlab (MacNish, 2000) was developed in recognition of the students’ dependency on class tutors to solve trivial mistakes. Datlab aims to provide feedback to the students and support them in resolving their own mistakes. MacNish (2000) raises the issue of providing the student with too much help and acknowledges that a support tool could be used to complement rather than replace existing teaching methods. InStep (2001) takes advantage of the common errors that students make to predict the likely cause of a problem in a novice program. However, InStep is limited to a small problem base with ‘fill-in-the-blank’ questions that do not fully support students in program formulation. Lang (2002) also recognised the need to provide students with simplified error messages. Lang suggests that as students gain confidence in their programming abilities they will become less dependent on a support tool.

Expresso (Hristova et al., 2003) has also been developed through recognition of the advantage in replacing compiler errors with more simplified messages for the novice programmer. Similar to CAP, Expresso also detects some common logic errors that novice programmers are known to make. CMeRun (Etheredge, 2004) is recognised as a useful demonstration aid in the classroom, specifically to support the need for one-to-one teaching. CMeRun allows the student to see each statement and variable value during execution. On execution CMeRun indiscriminately interleaves the code with print statements to indicate program state. This is not needed for all program parts and not suitable for all problems, e.g. small world teaching as in Karel the Robot, and is something that the students could do themselves using their own print statements.

For support at the design & implementation stage, PROUST, the Lisp Tutor, SWANN and IVC are discussed. PROUST (Johnson and Soloway, 1985) characterises a problem in terms of a number of programming plans needed to effect a solution. An expert system links goals in the stated problem to one or more (correct) plans and derives the intended plans of the

student. Correct and intended plans are compared and the student is directed towards the closest correct plan. This approach allows variant solutions to a problem and this in turn promotes independent learning in students since they are not constrained by a single ‘correct’ solution and are free to explore approaches with a variety of constructs. Further, the associated feedback is linked to both the closest plan and the intended plan. Johnson and Soloway also indicate that PROUST contributes to the tutoring process. However, PROUST requires that the student is sufficiently capable of constructing a plan in code of adequate sophistication to derive the goal set from the program for comparison and only (necessarily) operates on complete or nearly complete implemented plans since it is, in essence, pattern matching.

The Lisp Tutor (Anderson and Skwarecki, 1986) is a fully integrated learning environment which provides immediate feedback to the student to help them complete their program whenever they produce an error. The Lisp Tutor also predicts the construct that the student is attempting to create and provides them with a template to complete the rest of the code. Although the Lisp Tutor has been proved to help the students, it is also recognised that the immediate feedback can be too intrusive and does not support those students who would rather request assistance when they need it. Indeed, the immediate feedback presented exploits the line-by-line runtime interpretation afforded by Lisp and this is not common. SWANN (Brna and Mathieson, 1993) is an environment that supports the debugging of a small number of predefined programs written in Pascal. SWANN provides feedback to the novice in the form of (non-programming) plans or outlines. SWANN is able to provide a range of suggested solutions to the novice. The support is limited to a small subset of programs and requires a substantial attempt on the part of the student for the analysis to be useful. In addition to this, some of the suggested fixes are not sufficient to correct the program and may actually direct the student further away from the desired program operation.

IVC (Moore and Taylor, 2005) is an online tutor that presents the student with a series of programming exercises and provides context sensitive error messages and links to relevant

tutorial pages. The error message support provided includes syntax and recognised common semantic errors. IVC also allows students to ask questions in English. Allowing students to have a simple conversation with the support tool helps to guide the students towards a solution whilst supporting deep learning.