Design Considerations for
Larger Lego-Logo Programs
and their Use in Beginner's
Programming Learning
Gerald Futschek
Institute for Software Technology,
Vienna University of Technology
A-1040 Vienna, Austria,
tel: +43(1)58801-4098,
fax: +43(1)5041580,
email: futschek@ifs.tuwien.ac.at
Abstract
Design considerations are necessary for programming larger programs. Very often we find that tiny example programs cannot easily be expanded to larger programs. In particular the programs for computer controlled models, such as Lego-Logo programs, are additionally confronted with the complex programming concepts real-time and parallelism. We propose that the process of learning programming should reflect the needs of programming larger programs from the very beginning. We offer some design considerations for slightly larger Lego-Logo programs and list some concepts that are useful to learn from the very beginning. Some of these concepts may be efficiently learned by trial and error, but at least the teacher's example programs should reflect in an appropriate way the important principles of programming larger programs.
Keywords
Program design, Lego-Logo, computer-controlled models, learning programming, programming style
1 Introduction
Design considerations that are useful for larger programs are often neglected in programming environments for kids. The concentration of the learner is usually totally directed to understanding the basic concepts of the specific micro world and its elements. Logo's turtle geometry [4] and the Lego-Logo system are famous micro worlds for beginners that allow a very easy and efficient start in the world of programming. Initially all the programs look easy and simple. But very often it is difficult to expand small programs to slightly larger program systems. To write larger Logo programs we must apply some principles developed in the field of software engineering [e.g., 5, 6]. The successful writing of larger programs requires some planning of the program's structure and a disciplined use of the Logo language.
The Lego-Logo micro world in particular consists of a very interesting and fascinating combination of special sensor bricks, motors and lamps that can be used with all the regular Lego stuff to build computer-controlled models that actually work. These models can be used in very motivating learning projects [1, 7]. The programming language Logo is extended to the needs of programming computer-controlled machines. In fact the Lego-Logo environment can be used similar to the turtle as a tool for learning the first steps in programming [2, 3].
Based on our experience in writing larger Lego-Logo programs we will discuss the principles that are useful in larger program design. This paper will propose various tips and measures that will ease the transition from small to larger programs, focusing on the Lego-Logo environment in particular.
2 Elementary learning steps using Lego-Logo
2.1 Programming concepts of Lego-Logo compared with turtle geometry
Lego-Logo |
Turtle Geometry |
| endless loop to observe an endless stream of events | terminating programs |
| execution and waiting time is an important aspect | time is not as relevant |
| control of many objects (motors, lamps, monitor, etc.) | usually control of only one turtle |
| simultaneous input from many sensors or keys | input only from keyboard if necessary |
| parallel programs | sequential programs |
Table 1 Programming concepts of Lego-Logo versus Turtle Geometry
Learning programming in a Lego-Logo environment is quite different from learning programming with turtle geometry. Programming of computer-controlled models also entails concepts such as real time, processes and parallelism at a very early stage of the learning process. The concepts of learning by exploring, learning by doing, learning by problem solving or learning by developing are quite similar in Lego-Logo and turtle geometry. The main differences in program design of Lego-Logo and Turtle Geometry programs are described in Table 1.
The different programming concepts of Lego-Logo have to be introduced step by step, with each step motivating the introduction of the next one.
2.2 The four basic learning steps of computer-controlled models
The different programming concepts may be introduced in four steps using appropriate examples and models (e.g. see [2,3]). Each step consists usually of several intermediate steps.
Step 1: Basic commands of computer-controlled models
Use of a single motor, use of different speeds: ON, OFF, SETPOWER speed
Use of different motors and lamps: TALKTO "motorb
Procedures and repeated operations:TO, REPEAT
Learning goals: The students learn the basic commands of the Lego-Logo system. They learn to repeat certain parts of the program and to define procedures. They learn how to make their own problem-dependent commands. The students learn from experimenting with these simple commands that they need certain time-dependent commands, e.g., for automatically stopping a running machine after a specific time.
Step 2: Use of time
The Lego-Logo system offers two simple and powerful commands for implementing duration-dependent commands:
ONFOR time
turns on a motor for the given time period
WAIT time
waits the given time period
Note that the system just waits during the execution of these commands.
Learning goals: The students learn how to implement actions of a specific duration. They learn a lot about measuring time and certain aspects of real-time programming. But they should also learn from experimenting with these commands that time is not sufficient to stop a motor-driven vehicle at a specific position. The students see the need for sensors.
Step 3: Use of one sensor
Here we have to master the problem of inspecting the sensor repeatedly. A single inspection of the sensor is not sufficient. In Lego-Logo we have a choice of three possibilities to solve this problem: WAITUNTIL, recursion and starting of a parallel process.
WAITUNTIL [light < 50] lamp_on
TO automatic_lamp
IF light < 50 [lamp_on STOP]
automatic_lamp
END
FOREVER [IF light < 50 [lamp_on]]
The WAITUNTIL command just waits until the condition is fulfilled. The recursion makes the endless inspection process transparent. The FOREVER command starts a parallel process that turns on the light whenever it is too dark. Having solved this simple problem we are encouraged to proceed with the next task: switching off the light whenever daylight is too bright. Note that this task is easily performed with simple extensions of recursion or FOREVER and is hard to implement when using WAITUNTIL.
Learning goals: Programming of an (endless) event loop, IF statement, recursion, starting of a parallel process. The next question arises: How can we implement several sensors that are inspected simultaneously?
Step 4: Use of multiple sensors
To use at least two sensors at the same time requires a program that inspects the different sensors in parallel. This parallelism may be simulated by one endless recursion that simulates the parallelism by sequentially executing a sequence of sensor inspections using IFs. A better solution is the use of a sequence of FOREVER commands that triggers the different parallel processes:
FOREVER ["inspection of sensor1 and consequent action1"]
FOREVER ["inspection of sensor2 and consequent action2"]
...
Every sensor corresponds to at least one endless parallel process that is triggered with the FOREVER command.
Even these four simple learning steps show that some concepts that are useful in very simple tasks cannot be used in slightly larger tasks. WAITUNTIL is commonly used in many examples for beginners although it is very hard to proceed to slightly more complex problems when utilizing this command.
In [2] we describe a complete scenario for beginners that can also be used for learning the necessary programming concepts.
2.3 Example of a beginner's Lego-Logo program
The following example shows the problems in the program's structure when proceeding from a small to a slightly larger program. In order to obtain a working program for a thermostat a student may arrive at a stage where he is able to write the wonderful recursive program:
TO thermostat
;holds the temperature between min and max
if temp1 > max [heater, off]
if temp1 < min [heater, on]
thermostat
END
In a very similar manner, he can introduce another recursive program that switches on the lamp when it is too dark and switches off the lamp when it is bright enough:
TO lamp
;automatic lamp
if sunshine [lampa, off]
if dark [lampa, on]
lamp
END
Now the student can run either the lamp program or the thermostat program. The best way to support an automated household is a combination of these two programs. If these programs are used in a context where more than one sensor is employed, we have real problems implementing a working program that inspects both sensors simultaneously.
A possible solution is to have a single endless loop which inspects all sensor inputs and reacts if necessary. This loop is usually called an event loop:
TO eventloop
;asks all sensor states in an endless recursive loop
if temp1 > max [heater, off]
if temp1 < min [heater, on]
if sunshine [lampa, off]
if dark [lampa, on]
eventloop
END
Here we have no clear structure of the program. The heater program is mixed up with the one for the automatic lamp. The different actions in this program have to have very short execution times otherwise the program is too slow to follow event changes.
A better solution uses the wonderful FOREVER command. This command starts a process which is repeated forever.
TO household
;starts the thermostat and the automatic lamp
FOREVER [thermostat]
FOREVER [lamp]
END
TO thermostat
;conditions and actions of the thermostat
if temp1 > max [heater, off]
if temp1 < min [heater, on]
END
TO lamp
;conditions and actions of the automatic lamp
if sunshine [lampa, off]
if dark [lampa, on]
END
Learning by experience includes learning from mistakes. It is quite a good didactic approach to give the students enough time to have their own experiences. But I also think that all the examples presented by the teacher must be perfectly prepared and work as good models for the student's programs. Therefore the teacher's example programs should be well structured and should offer a good basis for building upon.
The basic programs presented to novice programmers are usually very short (2 to 5 lines per procedure) and usually easy to comprehend. At the very beginning there seems to be no need for further structuring, planning or even self restrictions. Every new command and every new possibility of the system is so exciting that the students would not think about disciplined, structured programming and documenting. There is no motivation to obey software engineering principles at the very beginning, because the reasons for doing so are not apparent to the novice students. But the teacher knows the forthcoming steps of programming learning that lead to larger and more complex programs. It is the teacher's job to introduce a "good" programming style that allows an easy transition to larger programs.
3 Design experiences for larger Lego-Logo projects
The programming techniques of larger programs differ from the techniques for writing tiny toy programs. The discipline of Software Engineering deals with all the techniques for handling large software projects. In this study we do not want to deal with problems of really large programs. We just want to deal with problems of slightly larger programs. These programs are still deemed to be simple and small programs in terms of software engineering. But in writing slightly larger (Lego-) Logo programs we have to obey some of the software engineering principles that are used for large programs.
The author gained experience in writing larger Lego-Logo programs while writing the computer program for a Lego-Logo installation that is presented in the Ars Electronica Museum in Linz, Upper Austria. This installation, called "coin machine", shows the visitor some principles of computer-controlled models. The visitors to the exhibition are asked to solve a given exercise using this coin machine. After solving the problem the visitor may select a colored coin from the coin machine and take it home with. The user interface of the coin machine consists of several sensors for user input and a screen for system output. We used several light-sensitive sensors to control the colors of the coins and the position of the train that transports the selected coin to the drop-out box. In total we used all 8 sensor ports and all 8 ports for motors and lamps. Some of the 8 motor ports are used twice (two motors working synchronously). The Lego-Logo system was used to its very limits.
The main problems that had to be mastered were the structuring of the program, parallelism and debugging the program's defects. In larger Lego-Logo programs the size of each procedure and function is still very small but the high number of procedures and the high degree of interaction between the procedures make the system complex and difficult to understand. The main software engineering goals that must be achieved by larger programs are the quality criteria maintainability, portability, user friendliness and efficiency.
3.1 Programming guidelines
The quality factors understandability, readability, ease of modification, ease of expansion, ease of detecting and locating defects contribute to a high degree to the quality criterion of maintainability. Logo programs tend to be easily to program but hard to understand for other people or after several days. Every modification of the program and every debugging process requires that the program text be read and understood. A good and consistent programming style and good documentation greatly enhances the readability of larger Logo programs. The programming guidelines are a list of measures that support the readability of programs. They contain rules for commenting, indenting, naming, using commands, etc.
| commenting | Use a comment that describes the intended semantics after every TO and after every introduction of a new variable |
| indenting | 2-character indent for all nested commands |
| parentheses | left and right parentheses in same line or in same column |
| parameters | all parameters in same line or all parameters starting in the same column |
| naming | object-oriented naming: object.action |
| use of commands | no recursion, all parallel processes are started in processes.run, processes are started with FOREVER, processes of very short duration may be started with LAUNCH |
Table 2 Example of programming guidelines for Lego-Logo programs
3.2 Planning the program structure
In the project mentioned, we started the Logo programming in an explorative way adding new program parts only to working and tested procedures. At the beginning we tried not to use any global variables to ensure a minimum of side effects and unintended interaction between the programs procedures. But it turned out that this concept does not work in our application. We had to implement a sort of time-out. Whenever the user stops to interact with the system the system has to return to a specific starting situation after a given period of time. The programming task was to stop most of the active processes and to return to the standard process. But the Lego-Logo environment we used only has commands for stopping all processes or stopping one's own process, but no command to stop another process.
Because the time-out problem seemed to us more complicated we postponed dealing with it until the programming of all the other processes was nearly finished. It turned out that we had to introduce global variables to solve the time-out problem. This involved changing the whole structure of the program. Intensive use of explorative prototyping would have provided this major change in the program structure.
The use of certain program design principles may help to organize the program in a consistent way. The following list of design principles are useful tips for organizing the program structure.
Only a disciplined use of the possibilities of the Lego-Logo system allows the construction of a program that is easily modified and debugged.
4 Design principles just from the beginning
The experience gained in developing larger programs leads to the following list of recommendations for the teacher that should be used especially when teaching beginners.
The teacher should
4.1 Introduce the right concepts from the very beginning
Don't hesitate to introduce the FOREVER command. This command is easier to understand than a recursive event loop, and it works better. It might be a good idea to introduce an endless recursive program to show the endless aspect of a process. But FOREVER yields greater success in larger tasks. A further advantage of using FOREVER is that you can use WAIT, WAITUNTIL and ONFOR commands without interfering with the parallel processes.
Introduce the possibility of making comments in Logo programs at a very early stage of the learning process. Comments are parts of the program text that give the reader of the program some help in understanding the program. It is very easy to introduce comments while showing a complicated part of an example program.
The concepts introduced at a very early stage of the learning process are easier to memorize than the concepts introduced later.
4.2 Animate the students to adopt a good programming style
A good programming style is to some extent a question of taste. Certain principles seem to have no use in smaller programs, but they are quite useful in larger programs. One of these principles is consequent indenting of the program text. Another principle is that writing many short procedures instead of a few long procedures may increase the flexibility of the program.
The importance of these principles can be understood only with experience. But the teacher should mention these principles at the very beginning of learning programming.
4.3 The teacher's programs have to be good example programs
Learning by example is one of the most important learning principles. The students can make the best use of this principle when the teacher gives a good example by writing well-structured, well-formatted and well-documented example programs.
5 Conclusion
Introducing the wrong concepts at the very beginning of the programming learning process can be a major barrier for programming larger programs at a later stage of learning. The teacher himself should have some experience in programming larger programs. This will enable him to introduce suitable programming concepts at the very beginning that allow a natural progression from simple and small programs to larger and more complicated programs.
References