Teaching and Learning Forum 2000 [ Proceedings Contents ]## Starduster: A different vehicle for presenting difficult programming conceptsRick DuleyComputer and Information Science Edith Cowan University -
Traditional teaching of computer programming typically follows the transmissive model with lectures given to large groups followed by individualised laboratory work in which the students implement the theory covered in the lecture. Small programs set in assignments in these workshops are often perceived by the students to be toys with little relevance. As a result long term problems can develop with students applying programming concepts to the resolution of real world problems. (Turner & Zachary, 1999, p. 43) (Jimenez-Peris, Khuri, & Patino-Martinez, 1999, p. 252)
Programming, once seen as central to a Computer Science curriculum is now increasingly viewed as secondary to the comprehension of concepts. Students must be given the opportunity to grapple with problems with multiple possible solutions and to accept, in the implementation, the consequences of their options. (DARPA Overview, 1996) Utilisation of a graphical user interface and the implementation of computer games are coming under increasing discussion as a means to motivate students to comprehend these concepts and develop the skills to master real world problems. Visual impact is proving to be an effective means of catching student interest. (Roberge, 1992, p. 230) This paper discusses a prospective initial programming project (Starduster, which is based on an exercise in an experimental course at a United States university (McFall & Stegink, 1997).) in which the higher complexities of implementation are hidden from the students who are then left to concentrate on the resolution of a cumulative series of problems. In the process the students are introduced to selection statements and to the concept of data type in a concrete rather than abstract situation. Successful resolution produces immediate visual feedback to encourage the students to proceed to subsequent, more complex, stages. |

Traditional teaching of computer programming typically follows the transmissive model with lectures given to large groups followed by individualised laboratory work in which the students implement the theory covered in the lecture. Programming, once seen as central to a Computer Science curriculum is now increasingly viewed as secondary to the comprehension of concepts. Students must be given the opportunity to grapple with problems with multiple possible solutions and to accept, in the implementation, the consequences of their options. (DARPA Overview, 1996) Visual impact is proving to be an effective means of catching student interest.

Current impetus towards registration of Software Engineers as a recognised profession, on par with Civil, Mechanical, Chemical and other Engineers (Werth, 1999), is generating a call for a specific Software Engineering curriculum with an emphasis on the creation of software rather than Computer Engineering or Information Technology. Of necessity, programming will occupy a central role in such a curriculum, and this, in turn, makes finding ways to teach programming in a modern technological context an urgent issue. Experiments are under way around the world, including 'Spider' [http://www.seas.gwu.edu/~mfeldman/cs1book/software.html, a modern rendition of the LOGO Turtle (Papert, 1980)], writing video games (Jimenez-Peris et al., 1999), real world problems with graphical output (Roberge, 1992) and real robots using LEGO(r) [http://www.oreilly.com/catalog/lmstorms/]. This paper discusses a prospective initial programming project in which the higher complexities of implementation are hidden from the students who are then left to concentrate on the resolution of a cumulative series of progressively more complex problems.

*Starduster* opens an high resolution graphics window and fills it with randomly coloured pixels at random positions. Code for this general situation is shown in Code Sample 1 as *procedure No_Filter.* It is possible, however, to select from the stream of pixel lighting instructions those which correspond to a specific area of the window and to override the random colouring with a specified colour. By this means, the programmer can create predefined shapes and patterns. Selecting *Standard Filter* from a menu screen produces the effect shown in Figure 1. Again, the student never sees the coding for this effect - the example only serves to illustrate what is possible.

**Figure 1:** Starduster Standard Filter

Here, the student has been introduced to the standard format (in Ada) for a *procedure* (or program segment) but now there are two more concepts:

*Parameters*(X & Y - the window coordinates of the pixel to be lit;*Hue*- the random colour in which it would be lit) and;*Screen coordinates*- the system by which the position of a pixel in the window is defined (which are the same as those for the fourth quadrant of a mathematical graph) with the maximum coordinate values in this window being X=800, Y=600.

How the information arrives does not matter at this stage except to know that it is transmitted from the hidden package. How the information is used is shown in the line *AdaGraph.Put_Pixel( ... )* in the second to last line of *procedure No_Filter.* This, translated, simply tells the *package AdaGraph* to light the pixel at window coordinates *(X,Y)* in colour *Hue.* One more linguistic construct is required - that of a *selection statement* or *if* statement. In Ada this follows a standard English language interrogative format, using the words *if, and, then, else* and *end* as one would in a normal prose sentence.

Solving the problem is a matter of defining the colour of any pixel for which X>700 and Y>500 to be Yellow while allowing randomicity to persist for all others. Code Sample 2 shows the completed procedure.

(Another concept has been introduced here, what is known in Ada as a *shortcut,* where the use of *and then* means that if X is not greater than 700 the program will not check the Y value but simply proceed to the alternative action. This is not really necessary at this level, but it is good programming practice.)

**Figure 2:** Task One Effect

Task Two increases the complexity of the problem without requiring additional linguistic tools. Again, a rectangular area of the window is to be lit with pixels of a prescribed colour, but in this case all four sides of the rectangle have to be defined by the programmer. Code Sample 3 shows the solution (and gives an example of the usefulness of the *shortcut* use of *and then* since, if X is less than or equal to 300 then the other three conditions remain untested and the alternative action is taken). *procedure Task_Two* results in a rectangle in the centre of the window being lit yellow and the rest in random colours.

Task Three requires a more mathematical solution in that the programmer is required to highlight a circle in the window. The author did this using an implementation of Pythagorus' Theorum - there are, no doubt, easier ways - but the mathematics is not beyond any student with TEE Maths.

Here another difficult concept is introduced, that of *type.* Ada's predefined function *abs* (which produces the mathematical absolute value) takes integer operands but the predefined function *sqrt* (for square root) takes real number operands. *procedure Task_Three* (in Code Sample 4) shows one solution to this conundrum where the absolute (integer) values are *coerced* into being represented as real numbers by the use of the reserved word *Float.* (Real numbers cannot be represented in (binary, ie integer) computer storage and are approximated by what, in Ada, are called *Floating Point Numbers.*) Traditionally, this concept would be presented in abstract fashion in a lecture situation - here the reality of the problem is dealt with in a concrete situation, the program simply will not compile unless the matter is dealt with. The author submits that this presentation is far more readily understandable to the novice.

Finally, Task Four puts together all that has been learned so far - requiring the use of both linear and circular boundary definition. In solving the problem the programmer must :

- Select pixels within the outer circle for defined colouring;
- Ignore pixels within the inner circle;
- Ignore pixels within the first quadrant of the circles.

**Figure 3:** Task Four Effect

Figure 3 shows the screen display resulting from running *procedure Task_Four.*

Parameters and types are two concepts with which students often wrestle for an entire semester. It is hard for people to come to grips with, and use, such concepts until they recognise the need for them. In *Starduster* students meet them in a situation which illustrates that need and the author suggests, therefore, that they would have much less difficulty in absorbing the concepts. *Starduster* also presents packages, procedures, coordinates and selection (and shortcut) statements in one tutorial - one or two of these would commonly be the subject of an entire tutorial - yet, because the more threatening aspects of coding are abstracted away, I believe them to be readily digestible. Furthermore, success or failure in the resolution of the problems set is confirmed by visual feedback rather than a line of numbers or characters - a situation familiar to today's students and more likely to reinforce comprehension of the underlying concepts.

As yet, only a few students have seen the program but their response has been uniformly enthusiastic. The author looks forward to being able to use *Starduster* in a teaching situation in the coming semester.

DARPA Overview (1996). http://www.asset.com/stars/darpa/Overview/home.html [16 December 1999].

Jimenez-Peris, R., Khuri, S., & Patino-Martinez, M. (1999). Adding Breadth to CS1 and CS2 Courses Through Visual and Interactive Programming Projects. *Proceedings of ACM-SIGCSE'99* (pp. 252-256). New York, NY (USA): ACM.

McFall, R., & Stegink, G. (1997). Introductory Computer Science for General Education: Laboratories, Textbooks and the Internet. *Proceedings of ACM/SIGCSE 97* (pp. 96-100). New York, NY (USA): ACM.

Papert, S. (1980). *Mindstorms: Children, Computers and Powerful Ideas.* New York, NY (USA): Basic Books.

Roberge, J. (1992). Creating Programming Projects with Visual Impact. *Proceedings of ACM/SIGCSE 92* (pp. 230-234). New York, NY (USA): ACM.

Turner, J. A., & Zachary, J. L. (1999). Using Course-long Programming Projects in CS2. *Proceedings of ACM-SIGCSE'99* (pp. 43-47). New York NY (USA): ACM.

Werth, L. H. (1999). Licensing Software Professionals: Where Are We? *Proceedings of ACM/SIGCSE'99* (pp. 27-30). New York NY (USA): ACM.

Please cite as: Duley, R. (2000). Starduster: A different vehicle for presenting difficult programming concepts. In A. Herrmann and M.M. Kulski (Eds), Flexible Futures in Tertiary Teaching. Proceedings of the 9th Annual Teaching Learning Forum, 2-4 February 2000. Perth: Curtin University of Technology.
http://lsn.curtin.edu.au/tlf/tlf2000/duley.html |

[ TL Forum 2000 Proceedings Contents ] [ TL Forums Index ]

HTML: Roger Atkinson, Teaching and Learning Centre, Murdoch University [rjatkinson@bigpond.com]

This URL: http://lsn.curtin.edu.au/tlf/tlf2000/duley.html

Last revision: 19 Feb 2002. © Curtin University of Technology

Previous URL 16 Dec 1999 to 19 Feb 2002 http://cleo.murdoch.edu.au/confs/tlf/tlf2000/duley.html