CBL Systems for Programming

There have been three full-scale surveys carried out on CBL applied to programming (du Boulay et al. 1987; DeWolf et al. 1992; Deek et al. 1998). For this research, it is

sufficient to overview those surveys, and some other key systems reported after the recent survey. du Boulay et al.’s work (1987), the first of this type, is very interesting and

valuable, and covers almost all the important early CBL systems for programming. They classify the systems based on two factors: the educational role they play and the type of knowledge they deploy, and they group them into three main classes: Tutors (and coaches), Bug Finders, and Support Environments. They characterise ‘Tutors’ based on Hartley’s definition (see Section 2.3.2 for more detail (Hartley et al. 1973)), and they

differentiate ‘Bug Finders’ as a group of systems that can find a bug in a program, analyse and advise (if they are asked to do so). The ‘Support Environment’ is described as

“…usually intelligently designed (rather than inherently intelligent) to provide easy-to- use tools for different part of the programming process…” (du Boulay 1988, p. 1).

After five years, the next survey was conducted by DeWolf et al. (1992). They classify

the systems into two dimensions: competence in domain knowledge and competence in teaching capability. In particular, under the domain knowledge dimension they divide

constructions, program verification, or neither of them. Each of these divisions closely matches with Tutors, Bug Finders and Support Environments, respectively. For example, the systems which have knowledge in program constructions may provide interactive help. If they can also address individual students they will become du Boulay’s (Intelligent) Tutors. Knowledge in program verification is essential for debugging. For support environments, none of this knowledge is essential.

Deek (1998) divides the systems into four categories. His classification schema also matches closely with that of du Boulay’s but with slightly different labels. In addition to the three groups mentioned before, he includes a new category called the intelligent programming environment. This architecture has now become prominent in CBL research, since it includes advantages of both artificial intelligence and constructive learning theories. Deek (1998) and du Boulay (1988) warn that their classifications do not follow any hard-and-fast rules, and therefore, should not be considered as a clear-cut division.

There have been some research attempts to migrate existing learning systems to the web (Brusilovsky et al. 2003). Since the millennium, there has been considerable research

reported in the literature on CBL systems for programming. Most of these studies concentrate on designing learning systems for internet (or intranet) platforms (see (Deek

et al. 2001) for detailed discussions on some earlier web-based systems for

programming).

Intelligent Tutors and Bug Finders

Tutors have some capacity to monitor students’ actions and they can also teach, instruct, or coach appropriately, whereas Bug Finders can only locate logical errors in the students’ completed solutions and provide appropriate feedback. LISPITS (Anderson et al. 1984)

and PROUST (Johnson et al. 1985) are classical examples of a Tutor and a Bug Finder,

respectively. Some recent examples include PROPL (Lane 2003) of a Tutor, and (Xu et al. 2003) of a Bug Finder.

LISPITS is based on ACT* theory (Anderson 1983). Production rules are included to represent the potential solutions as well as deviations. The model tracing approach is employed for instruction. Each new symbol the student enters will be parsed. If the system identifies that the student’s solution path is correct it will allow them to proceed. Otherwise, if the system identifies it as a known deviation, it will provide appropriate feedback. For any unknown behaviour, the system will provide suggestions for alternative actions. Similar to Formalizer (Flynn et al. 1989), the editor includes place holders for the

students to fill; and therefore, they are freed from worrying about the syntax of the language. There is a computational advantage by the restriction of the potential paths and the provision of place holders. This approach may also be helpful for the students at their initial stages of learning. For advanced students, however, this approach may be frustrating due to its lack of flexibility.

PROUST can successfully detect a variety of logical errors (Johnson et al. 1985).

However, unlike LISPITS, it is not pro-active; it can debug programs only after the task is completed. It includes a rich set of empirical data based on both correct and incorrect answers for certain programming problems from potential novice learners. The program specification is given as a sequence of goals. Each goal can be associated with a sequence of plans. The students’ solutions are dissected and their intentions are identified as a structure of goals and plans. PROUST is powerful in a limited range of problems, but it can however, be easily fooled and it cannot work interactively (du Boulay 1988).

PROPL (Lane 2003) is a dialogue-based coach for program planning. Before attempting to write a program, similar to BRIDGE (Bonar et al. 1986), learners are asked to identify

programming goals and the best way to achieve them. The design ideas for a programming problem are elicited from the student through a natural language dialogue (Shapiro (1982) uses dialogue strategy in the debugging stage). This approach has been tested with sixteen subjects, and the authors claim it is a success where the coached students performed better than the control group.

Xu et al. (2003) describe the transformation-based strategy used in their ‘Bug Finder’.

The errors in students' programs are diagnosed by incorporating control-flow analysis and data-flow analysis in program analysis. Similar to LAURA (Adam et al. 1980), another

than five hundred real student programs (for nine different programming tasks), and the results were encouraging.

Visual (or Textual) Support Environments

Tutors and bug finders do not exploit the exclusive features of the programming domain, and concentrate instead on tutoring the problem solving skills. A learning system for programming should help the learner to create the appropriate mental model of the dynamic behaviour of the program and underlying notional machine (Ramadhan 1992a). Eisenstadt et al. (1992) are of the opinion that the traditional ITS for programming will

not succeed and any CBL systems for novices needs software visualisation and other supports, rather than teaching alone. This type of belief and the advancement of hardware technology made it possible to create several data structure visualisation and memory animation tools (e.g. BALSA (Brown 1987)) and other text-based support tools (e.g. SODA (Hohmann et al. 1992)) for different aspect of programming.. The classic system

BRIDGE (Bonar et al. 1986) may be considered as an intelligent support environment.

BRIDGE provides an environment for learning program analysis, design and coding. It supports the learner to develop relevant code in an evolutionary fashion from a problem given in natural language. Firstly, to solve the problem, higher level goals (textual phrases) are selected from a menu. If the solution is correct, the plans are formed for each goal (using a menu again). Finally, the code segments are selected to facilitate the plans. BRIDGE and PROUST dissect problems into goals and these goals into plans. However, BRIDGE works in top-down fashion (goal to code) whilst PROUST works bottom-up (code to goal). BRIDGE provides a declarative view of the problem (but it is intended to teach a procedural language). It is an interesting feature, since even declarative languages, such as LISP, are usually taught in procedural fashion within CBL systems (e.g. LISPITS).

Computers are now powerful enough to provide complex interactive graphical tools in real time, in order that the learners can visualise the dynamics of the underlying notational machine. Nearly all the recent research in CBL systems for programming includes visual

supporting environment. Meta studies on visual support environment for programming can be seen in Bednarik et al (2005) and Hundhausen et al (2002).

An remarkable example of a visual supporting environment is JELIOT-3 (Moreno et al.

2004). It is more than a program visualisation tool designed for learning and teaching Java. Learners may interact with the system during visualisation, and therefore, it provides an active learning environment. Furthermore, Bednarik et al. (2006) are

conducting research into incorporating eye tracking for identifying learners’ intentions. In future, Jeliot-3 may include a Learner model, and may become a full-fledged collaborative intelligent learning environment (Bednarik et al. 2006). The system has

been tested and shown to be useful for novice students with difficulties in programming.

Intelligent Learning Environments

Intelligent Environments are similar to ITSs, with an additional supportive environment (or in other words, support environments with significant intelligent support). Typical examples include ITEM/IP (Brusilovsky 1995), and DISCOVER (Ramadhan 1992b), and ELM-PE for LISP (Weber 1993). ELM-ART (Brusilovsky et al. 1996) is a web-based

intelligent environment based on ELM-PE. There has been very little research undertaken recently into intelligent learning environment for programming. Exceptions include a web based system for learning Lisp programming (Wong et al. 2003), and a learning

environment for debugging (du Boulay et al. 2003).

ITEM/IP is claimed to be an integrated intelligent environment that supports various features, such as knowledge sequencing, task sequencing, editing environment, debugging and investigation etc. DISCOVER provides a visual conceptual environment that enables novices to relate problem solving with both language and machine. Also, it automatically analyses the student’s program for logical and semantic errors, and provides intelligent feedback.

Wong et al. (2003) discuss an agent based learning environment that facilitates reciprocal

tutoring of functional programming on the net. The authors claim that the tutor agent in their system is similar to Lisp Tutor (Anderson et al. 1985). They also claim that their

programming environment (Bhuiyan et al. 1994).

Du Boulay et al. (2003)) describe an interesting attempt to design an intelligent

environment for learning debugging skills. The CRUSADE project (Romero et al. 2003),

which is the origin of the above idea, aims at exploring the role of perspective, modality and individual differences in program comprehension, and designing a visual debugging environment for novice programmers and learners of programming. The proposed tutor is based on the experimental results of two debugging empirical studies (du Boulay et al.

2003). The first experiment was performed with a static Software Debugging Environment while the second one employed a dynamic, more interactive Software Debugging Environment. du Boulay et. al. conclude,

“These studies suggest that good debugging performance is associated with taking advantage of the resources available in the debugging environment. For modern, multi-representational debugging environments, two important resources are the supporting visualisations and the facility to execute the program in steps. A crucial skill in taking advantage of these resources is the ability to decode the information comprised in the supporting visualisations”.