• No results found

Programming Notations and Associated Environments McIver (2000) states that:

The Process of Learning to Program

R 10 : Promote correct use of secondary notation

3.3 Pedagogical-PDEs

3.3.1 Programming Notations and Associated Environments McIver (2000) states that:

“…although they may be easily corrected, these (syntax) errors can still be disruptive and frustrating. …novices are forced to deal with details of syntax and individual elements of their algorithms, sometimes to the exclusion of the broader picture of the problem at hand. The more details a language requires the novice to recall, the less space is available for algorithms and the problem itself.”

The effect of the programming language on the process of learning to program has lead to a growing body of research into programming notations and associated PDEs that are suitable for novice programmers. Both textual and visual programming notation solutions are being researched.

From studies conducted regarding the use of these environments by novice programmers, it is known that simpler interfaces tend to be appreciated, errors tend to persist over fewer compiles with “reduced” or “subsetted” languages, and that novice

programmers interact with the pedagogic-PDEs differently than professional-PDEs (de Pasquale III, 2003, Heeren et al., 2003).

Mini-languages are small programming languages designed to be initial, temporary programming languages used to teach programming. The mini-languages are then discarded as novice programmers move on to general purpose programming languages. Scripting languages are programming languages embedded within other applications, such as Internet Explorer (Microsoft, 2006b), while visual languages use visual metaphors to represent programs.

The remainder of this section discusses mini-languages, scripted languages and visual languages in turn. A discussion of the general features of the PDEs within which each kind of programming language functions follows.

Mini-Languages & Micro-Worlds

Mini-languages are programming environments (programming notation and PDE) that have relatively few instructions and commands (Crews, 2001). The programming notations have been designed to be intuitive and easy to use for novice programmers, allowing them to explore the problem-solving context without being hampered by syntax construction of little significance. A set of basic commands is provided that allow simple solutions to be created. Mini-languages are not intended to replace general purpose programming languages, but rather to be used as short-term introductory programming languages (McIver, 2001).

One of the earliest mini-languages was Logo (Papert, 1980). Novice programmers were able to create pictures by issuing commands to an imaginary turtle with a pen attached to its tail. The turtle was represented on-screen as a triangle and could be issued simple commands: the turtle could be told to walk forward, turn left or right, pick the pen up or place it down.

Later mini-languages following a similar idea of an imaginary actor that could be requested to perform actions are Karel the Robot (Pattis, 1995), an object-oriented version of Karel the Robot called Karel++ (Bergin et al., 1997), Jeroo (Sanders & Dorn, 2003), ALICE-3D (Ko, 2003a, Cooper et al., 2003) and PigWorld (Lister, 2004). The environments in which these mini-languages function are also classified as

micro-worlds, because the programmer interacts with entities within a bound, imaginary world in which there are set entities and relationships between entities. GRAIL is a mini-language that is an extremely small textual programming language designed specifically to be intuitive, “unsurprising” and easy for novice programmers to use (McIver, 2001). The language is designed to aid in the instruction of and learning to program. The design of GRAIL was not motivated by existing programming languages or implementation issues, but derived from a strict set of pedagogical design rules. The language is purely procedural, even though all types of paradigms were considered in an unbiased manner. Initial findings suggest increased levels of novice programmer motivation when learning to program.

CS1-Sandbox (de Pasquale III, 2003) and MiniJava (Roberts, 2001) are both programming languages that are restrictions on C and Java respectively. CS1- Sandbox restricts the novice programmer to specific programming constructs, disallowing the compilation and execution of any program code containing these constructs. MiniJava, on the other hand, is a restricted subset of Java that removes the “intimidation factor” of Java and adds new programming constructs, such as foreach, to simplify certain types of problems.

Scripting languages

Scripting languages have been proposed as an alternate notation to general purpose programming languages in introductory programming courses. JavaScript (Warren, 2003, Mahmoud et al., 2004), VBScript (Gibbs, 2002) and Python (Shannon, 2003, Donaldson, 2003) are some of the more popular scripting languages used in introductory programming courses. Scripting languages are interpreted languages that are typically embedded within another system, such as a web browser. Scripting languages have hooks into the underlying system allowing the scripts to be run from within the system, in effect enabling functionality the underlying system was not originally designed for.

Python is a dynamically-typed programming language that supports object-oriented and functional programming (Donaldson, 2003). Dynamic typing removes the rigid type specification and checking of variables and values found in other general purpose programming languages. Variables need not be declared, simply assigned values and

the correct internal representation is determined. The syntax of Python is simple and allows for the use of secondary notation. Python is different from many programming languages in that the structure of code is inferred from the indentation of program code. The language has enforced rules on the use of indentation within a program. Due to the interpreted nature of scripting languages, it is possible for the novice programmer to execute single statements interactively to determine their effect. This allows novice programmers to test programs incrementally and receive feedback, which is one of the requirements specified in the design of programming notations and environments for novices (Pane & Myers, 1996).

The interactive nature of scripting languages makes them appropriate for novice programmers (Stajano, 2000), allowing novices to concentrate on algorithmic issues rather than implementation issues (Cilliers, 2005, Gibbs, 2002, Warren, 2003). Anecdotal evidence has shown that novice programmers using a scripting language in the introductory programming course have a higher level of motivation to succeed than those using a general purpose programming language (Mahmoud et al., 2004).

Visual Languages

Visual programming languages are programming notations that have a visual, rather than a textual representation. Programs are constructed by dragging-and-dropping visual elements into valid configurations that represent programs. The PDE only allows valid configurations of visual entities and minimal typing is required. This results in the possibility of syntax errors being greatly reduced. The aim is to reduce the cognitive burden of learning by shrinking the conceptual distance between actions in the real world and programming (Fischer et al., 2004).

There are different types of visual programming languages: flowchart simulators, dataflow programming notations and iconic programming languages:

• flowchart simulators represent programs as flowcharts, where the flowcharts specify the flow of control;

• dataflow programming notations represent functions with inputs and outputs. Once all inputs have been obtained, a function executes and produces output; and

• iconic languages, such as BACCII/BACII++ (Calloni & Bagert, 1997) and B# (Figure 3.3) (Cilliers, 2005), represent programming constructs as icons that can be linked together. A number of the iconic PDEs allow programs to be traced step by step and the values of variables displayed.

Figure 3.3: PDE for the Iconic Programming Language, B# version 3

Iconic PDEs, such as B#, can also produce program code in a specific textual programming language. This code can then be exported and executed in another environment, if desired. The code produced is free of syntax errors and will execute without any compilation errors. In addition to this, the program code is formatted using consistent style rules, thus exposing novice programmers to how their program code should look when formatted correctly.

PDEs associated with Programming Notations for Novice Programmers

The majority of the programming notations mentioned in this section provide a PDE that is simple to use and has limited features. In general, each of the PDEs employs a minimalist interface design that is no where near as complex as professional-PDEs.

Most, such as the CS1-Sandbox (Figure 3.4) have a simple interface with minimal controls. Each has a single window in which commands or programs are typed, an optional window for displaying the world (in the case of micro-worlds) and a window in which feedback is provided.

Each PDE allows for the opening and saving of files and provides buttons for the execution of a single command or a whole program. Some PDEs allow programs to be traced and variable values to be watched, while a few provide online help regarding programming language syntax and error message explanations.

Figure 3.4: CS1-Sandbox

Table 3.2 lists the features of the PDEs associated with programming notations specifically designed for novice programmers. The programming notation and associated PDE meet many of the requirements that pedagogical-PDEs supporting the mechanics of programming should, but there are a number of requirements not met. Instead of the programming notation being modified to allow novice programmers to create syntax error-free programs, another approach has been to instrument the program editor so that the probability of syntax errors being possible is reduced. Code structure editors are program editors that as thus instrumented and are discussed next.

Features

Pedagogical-PDE Requirements Programmin

g notation for n ovi ce s Deb ugg er

Simple GUI Syntax Highli

ghting

Visual representat

ion of progra

m

s

R1 Recognition, rather than recall 9

R2 Aesthetic and minimalist design 9 9

R3

Eliminate finer implementation details of

programming process 9

R4 Appropriate language usage

R5 System status visibility

R6 User control and freedom

R7 Support novice programmer tasks 9

R8 Help recognise, diagnose and recover from errors 9

R9 Use of signalling 9 9

R10 Promote correct use of secondary notation

Table 3.2: Programming Notation Associated PDEs Feature List