Teaching and Learning Forum 2000 [ Proceedings Contents ]

Starduster: A different vehicle for presenting difficult programming concepts

Rick Duley
Computer 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.

Teaching and Learning Forum 2000 Home Page

Introduction

Students entering tertiary courses in computing today have long standing exposure to fast, desktop computers and graphical interfaces. International curricular definition for Computer Science (CS), currently dating from 1991 (ACM-IEEE/CS Joint Curriculum Task Force, 1991) , was established in the days of mainframe computers and dumb, character terminals. It is increasingly obvious that the two no longer relate well when it comes to teaching programming. Trivial problems and black and white text interfaces fail to challenge many students and the resultant boredom can be compounded by the lack of immediate, visual feedback to which they are long accustomed.

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

Learning programming is always a process of 'getting over the hump' - there is so much to be learned before anything can be done - like having to learn to walk before one can walk! Bombarded on the one hand by difficult, abstract concepts, the student struggles on the other with rigorous, dry syntax and complex, pedantic semantics. One of the attractions of the Ada language, among others, is that the complexities of, in this case graphics, coding can be hidden in one part of the program (in Ada called a 'package') and the student left to deal solely with the problem in hand in another part of the program. This is the approach taken in Starduster.

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

Figure 1: Starduster Standard Filter

Four exercises in rising degrees of difficulty are now set starting with procedure Task_One shown in Code Sample 1. As shown, the code has the word null between the begin and the end which allows the procedure to compile (and even run) although it does nothing. Definition of the actual problem is shown in italics on the lines following the double hyphens (comment lines in Ada).

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:

  1. Parameters (X & Y - the window coordinates of the pixel to be lit; Hue - the random colour in which it would be lit) and;

  2. 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.
Code Sample 1: No filter and task 1

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.

Code Sample 2: Task One completed

(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

Figure 2: Task One Effect

Figure 2 shows the effect this simple filtering has on the display with the bottom left hand corner of the window highlighted in a single colour and the rest of the window randomly lit.

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.

Code Sample 3: Task Two completed

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.

Code Sample 4 : Tasks Three and Four completed

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 :

  1. Select pixels within the outer circle for defined colouring;
  2. Ignore pixels within the inner circle;
  3. Ignore pixels within the first quadrant of the circles.
Figure 3

Figure 3: Task Four Effect

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

Summary

Starduster is based on an exercise in an experimental course in a United States University (McFall & Stegink, 1997). A tutorial for novices, it utilises a procedural technique - in that the students are shown how to find a solution and then apply the knowledge gained from finding the first solution to solving more difficult problems. Because the complexities of the graphics programming are hidden (the only code the students have to deal with is that shown in the four code samples), any threatening aspect of that complexity is removed and, within that non-threatening environment there is freedom to concentrate on the actual problems themselves. There is limited emphasis on syntax, only the selection statement is used and that is very like normal spoken English, and the semantics are largely defined by the problem solutions. Within this 'comfort zone' situation, some difficult programming concepts may be met and dealt with by novices. Starduster presents a constructivist system of learning by doing rather than by reading or listening.

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.

References

ACM-IEEE/CS Joint Curriculum Task Force. (1991). Computing Curricula 1991: A Summary. Communications of the ACM, 34(6), pp. 69-84.

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