Logo: A cause for concern

Logo: A cause for concern

Compur. Educ. Vol. 12. No. I. pp. 107-112. rights reserved 1988 Printed in Great Britain. Ail Copyright c 0360-1315’88 $3.00 + 0.00 1988 Pergamon...

591KB Sizes 0 Downloads 124 Views

Compur. Educ. Vol. 12. No. I. pp. 107-112. rights reserved

1988

Printed in Great Britain. Ail

Copyright

c

0360-1315’88 $3.00 + 0.00 1988 Pergamon Journals Ltd

LOGO: A CAUSE FOR CONCERN JOHN LAYMAN’ and WENDY HALLS ‘La Sainte Union College of Higher Education. The Avenue, Southampton SO9 SHB. U.K. 2Department of Electronics and Computer Science, University of Southampton, Southampton SO9 SNH. U.K. the past few years, the use of Logo in U.K. classrooms has increased very rapidly across all age ranges. It is used extensively as a tool for the development of problem-solving skills. the introduction of info~ation processing techniques and the exploration of geometrical concepts. As a natural consequence of this wide use of Logo, it is becoming the first programming language met by many young learners. Much has been written about the power and appeal of Logo in its educational context. but there has been little consideration of the consequences of such extensive use of Logo as a programming language. It is also being used increasingly in conlrol environments. This has many positive aspects but here too there are problems to be considered. This paper considers the programming environment of Logo and the programming style that it produces. The issues considered raise questions about the way that we teach Logo to children and the extent to which we use it in both pre-service and in-service training of teachers. Whilst recognising the power of Logo, we must also take account of its defects. Some possible strategies are presented.

Abstract-Over

INTRODUCTION

Walk into any school in the U.K. today and you are more than likely to find that some version of Logo is available for use on the school’s microcomputers. Only two years ago this would have been a very unlikely situation. Indeed, only four years ago, to have found a microcomputer being used in a classroom would have been unusual, particularly in a primary school. When the Department of Industry launched its scheme in 198 l/82 to put a microcomputer in every schoo?, the only programming language available cheaply and readily on most microcomputers was BASIC. This gave rise to the so-called QWERTY phenomenon of BASIC, as described by Papert [l], which makes an analogy between the all-pervasive use of BASIC in schools and the QWERTY keyboard layout of a typewriter (for which there is no justification except that this was the way the keyboard was first set out). Many of the most eminent educationalists and computer scientists wrote at length criticising this state of affairs, notably Papert(l], Bork[2] and Dijkstra[3]. The arguments against the use of BASIC as a programming language became well-known but until the end of 1984 there was no viable alternative for schools except perhaps COMAL, which lost favour following the introduction of BBC BASIC with Acorn’s BBC microcomputer. The publication of Papert’s Mindstorms [I] in the U.K. in 1980 and the subsequent flow of info~ation from the U.S.A. about the powerful new list processing language, Logo, served to raise high hopes about the potential of Logo as a programming language in schools. When it was first developed, the only versions of Logo available ran on mainframes using a great deal of memory. Implementations for a variety of 8-bit micros, notably the Apple and Atari, tried to offer a usable version of Logo within 64K. However, at that time, the BBC microcomputer was the most common micro in U.K. schools and the development of Logo for this machine moved more slowly. Three versions became available at the end of 1984 almost simultaneously (one from the Open University marketed by BBC Enteprises, one written by LCSI/SOLI in Paris marketed by Logotron and one from Acorn) and such was the level of expectation that had been raised about the language that the rate at which schools bought the language chips was quite remarkable. Logo has many enthusiastic supporters and much has been written about its use as a problem-solving environment in many different areas of the curriculum (see for example Hoyles et al. [4] and Goodyear [5]). However, there has been little consideration of the consequences of such extensive use of Logo as a programming language. For many years, BASIC has been criticised for the bad programming habits it fosters in those who meet it as their first programming language, but it is equally important to critically assess the programming style that Logo produces. 107

JOHN LAYMAN and WENDY HALL

108

This paper considers the programming environment of Logo on the BBC microcomputer, still the most common microcomputer in the U.K., particularly in primary and middle schools. The authors are most familiar with Logotron Logo but most of the points made are general points and therefore not specific to any particular implementation. We are aware that versions of Logo now becoming available for the new 16-bit machines are more powerful and have enhanced features which may solve some of the problems put forward in this paper. But how many schools will have access to such versions of the language in the near future? More importantly, however, the points made in this paper are fundamental to the language itself and as such will always be with us. THE

DEVELOPMENT

OF

LOGO

The history of Logo is well described by Ross in his book Logo Programming[6]. We briefly summarise it here. Logo was designed at Bolt Beranek and Newman Inc. in Cambridge, Massachusetts, in the late 1960’s by a team which included Seymour Papert. It was inspired by the artificial intelligence language LISP and was designed as part of an experiment to test the idea that children can learn through programming. The first research project was closely linked to mathematics and sought to test the idea that programming might be a useful environment in which to talk about problem-solving. Logo was subsequently refined at the Artificial Intelligence Laboratory of M.I.T. and at the Department of Artificial Intelligence of the University of Edinburgh, Scotland. The emphasis of the Logo project was oriented towards young children of about ten or eleven with the expectation that programming in Logo would help them develop mathematical, logical and problem-solving skills. To this end the language was designed to appear as natural as possible to the child, to be friendly, easy to use and jargon-free and to provide a motivating environment. At first, Logo had no provision for computer graphics, largely due to hardware considerations. However, fairly early on, graphics was incorporated into the language in the form of turtle graphics. This has probably contributed more to the success of Logo than anything else. In fact, many people now mistakenly assume that turtle graphics is Logo and some products, which only contained turtle graphics commands, were misleadingly marketed under the name of Logo. Having said this, however, the addition of turtle graphics provides a very appealing and motivating graphics environment which offers enormous scope for experimentation. It is integral to the language and requires no prior knowledge of sophisticated mathematical concepts such as Cartesian coordinates. Logo, like BASIC, is a language that has evolved. The original reason for its design was for research purposes and there is no agreed Logo standard as there is for, say, Pascal. This leaves Logo open to the same criticism as BASIC in that whilst newer versions are continuously being developed, with more or less variation in the original syntax depending on the implementation, there are numerous poor versions being used in schools which do little more than mimic the original M.I.T. Logo. LOGO

AS

A PROBLEM-SOLVING

ENVIRONMENT

The point has already been made that Logo was originally designed as a research tool for developing problem-solving environments. It does not necessarily follow that such a language would be suitable for problem-solving in classrooms. In the classroom situation there may typically be one machine, one teacher and 30 children, with both teacher and pupils being exposed concurrently to the same discovery learning process. The contrast with a typical research environment, one child and one Logo expert per machine, is marked. Many of the most frequently cited and formative projects supporting the use of Logo as a problem-solving environment were based on this experimental design[l,7]. Even where the problem-solving has been translated to the classroom, the results are often either anecdotal or obtuse. Allied to this is the fact that researchers in this area will have a greater depth of experience in the language than is usually available to practising classroom teachers. This has obvious implications for teacher training and remains an infrequently considered issue. Perhaps of more concern, is the fact that despite many years of research in this area, there is as yet no firm evidence that there is any transference of skills from programming in Logo to

Logo: a cause for concern

109

problem-solving in other domains. Indeed, research evidence that does exist, implies that little confidence can be maintained in the transfer hypothesis[8]. LOGO

IN

CONTROL

A natural extension for a programming environment like Logo that has a central philosophy concerned with exploration and experimentation is the implementation of additional procedures which facilitate communication with the outside world. The most common Logo control device that can be treated in this way is the turtle. However, a large range of other switches and sensors can now also be controlled from Logo. For example, the Control Logo toolkit allows Logotron Logo to be extended in this way but at the expense of user workspace. This is because the toolkit is defined as user procedures and not as true primitives. The advantage of work in this area is that it allows the learner to be in a position of controlling the machine and its environment., in the sense that it involves investigative work based on first hand experience in an area that was previously inaccessible in the primary classroom. namely microelectronics. Unfortunately, this type of work can be heavily dependent on the teacher providing a suitable library of procedures and this is particularly true at the set-up stage. For example, in Logotron Logo for the BBC, the default set-up conditions are printer port as output and user port as input. For any control box requiring set-up conditions other than these, the user has to reconfigure the output ports. Logotron’s default set-up conditions do not, for example, allow true analogue input such as from a temperature sensor. The following procedure will reconfigure the ports to give user port as output and analogue port as input. TO SETUP .SETOUTPORT 65 122 SETOUTVAL DEC “FE62 .SETOUTPORT 65 120 SETOUTVAL DEC “FE60 END This is hardly self-explanatory, unlikely to evolve from discovery learning, and few primary teachers will have the requisite background to understand the principles on which it is This example also highlights one of the possibly confusing aspects of Logo, namely the punctuation to determine the definition of a Logo object. This feature of Logo, introduced understanding, can cause more confusion than it alleviates and is discussed in greater depth next section. PITFALLS

IN

LOGO

school based. use of to aid in the

PROGRAMMING

In this section, we analyse some of the pitfalls of Logo programming that occur because of shortcomings in the language. These can make the language difficult to learn in any structured way (a point which is expanded on in the last section of this paper) and make programming in Logo a sometimes mind-bending art. As has already been pointed out, the meaning to be applied to a Logo object may be determined by its prefix punctuation. In many common versions of Logo (including Logotron) the Logo statement MAKE “SIZE :SIZE + 1 would be interpreted as “make the value of the variable named SIZE the (previous) value of SIZE incremented by one”. This apparently odd syntax adds a precision, not found in other languages, that differentiates between the name of a variable and its value. It can be helpful to first time programmers learning the language, although experience has shown that the concept of a “variable” is still a stumbling block to many. Not all versions of Logo have followed this convention. Some for instance have removed the colon prefix for denoting the value of a variable but this leads to difficulties in distinguishing between procedure names and variable names.

JOHN LAYMAN and WENDY HALL

110

The use of the prefix notation is not always consistent and can create unnecessary confusion. For example, “HOUSE can refer to either a procedure or a variable of the same name. One solution that has been adopted to overcome the problem of ambiguity in such operations as editing or saving, is to refer to variable names within square brackets. Hence, SAVE “HOUSE refers to a file called

HOUSE

and a variable

[“ROOM]

named

ROOM.

SAVE “HOUSE

“ROOM

SAVE “HOUSE

[ROOM]

Whereas.

and

both refer to a file called HOUSE and a procedure named ROOM. Adding to the confusion, the square bracket notation implies a list but in a Logo program, the list [“ROOM] refers to a list with one element “ROOM and not the variable named ROOM. To explore this further, consider the following example. SAVE “HOUSE Here, in

the procedures DOOR

WINDOW

MAKE

“HOUSE

[DOOR ROOF

WINDOW

ROOF]

will be saved in a file called

[DOOR

WINDOW

HOUSE.

whereas,

ROOF]

the variable named HOUSE points to a list with elements “DOOR WINDOW ROOF. Whilst this is all quite logical in context, it makes it difficult to structure the learning and the teaching of the language. Another area of difficulty with the quotation prefix is met where numbers are concerned, since it is quite possible in Logo to have a number as a variable name. A possible consequence of this could be the message 30 HAS NO VALUE which may lead to some confusion. In fact, Logo does not distinguish between variable types such as string and number (or lists). There is some debate in the literature as to whether variables should be untyped in list processing languages. The case for typing of variables is concerned with the efficiency, readability and security of programs. These factors should be areas of concern for Logo if it is to be advocated as a first programming language. Practices than can engender insecure, unreadable and inefficient styles have already been criticised in other languages such as BASIC. Are we going to continue the process with Logo? The same criticism could of course be made about the way Logo encourages (and sometimes forces) the use of global variables. There are further pitfalls for the user when interactively collecting keyboard inputs. The input has to be collected as a list and input validation necessarily requires list processing knowledge. Some smaller microcomputer implementations of Logo (including Logotron) do not have a nondeterministic (DO/WHILE) loop. This makes the validation of input more difficult, since it forces recursion, which in this instance is an inefficient process. There are many other instances where an iterative solution is much more efficient than a recursive one and an iterative loop is desirable. The only alternative solution where no non-deterministic iterative loop is available as a primitive in the language, is to define a recursive procedure to simulate a loop using the RUN command. Recursion is a natural and powerful developmental step in the geometrical world of the turtle but when applied to a list processing algorithm to implement, say, a simple SORT procedure, it becomes more difficult to comprehend. Wirth’s [9] dictum that recursion should be avoided where iterative solutions are more obvious, is also ignored by Logo, which sometimes forces recursion where it is inappropriate. It should be noted here that Logo’s parent language Lisp, does have an iterative loop structure for use in cases where it is most appropriate, as do many of the more powerful microcomputer implementations of Logo.

Logo: a cause for concern

III

Whilst recognising that conceptualising problems using recursive structures may well be easier for those whose programming background is predominantly recursive in style, it must be borne in mind that we do not yet know how to teach recursive skills in any formalised manner. In a list processing language, the problem can be well illustrated by the challenge, for both teachers and learners, of writing an efficient recursive sort routine. An added difficulty is the lack of relational operators for comparison of non-numeric list elements. Some implementations of Logo on bigger machines provide a sort primitive but even where this is the case, if Logo is to be put forward as a suitable language for computer science work, the algorithmic aspect of the problem must still be addressed. One of the most unfortunate outcomes of the difficulties discussed above is that the readability of Logo programs jumps rapidly between the extremes of simple turtle graphics routines and complex list processing algorithms. This same concern for readability has often been used to criticise BASIC and we must take care that any language adopted to supercede the position of BASIC does not contain the same pitfalls. CONCLUSIONS

AND STRATEGIES

Current enthusiasm for the adoption of Logo in the classroom has placed it in the position of being the first programming language met by many learners. Research has shown that the conditioning of the first language is incisive in the development of good practice in computer science. Both educationalists and computer scientists have often cruelly criticised BASIC. Dijkstra[3] claims that “. . . it is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration”. This paper examines the credentials of Logo to replace and improve upon this infamous predecessor. The evidence suggests that some of the claims of Logo may be inflated and difficult to attain. This is in part due to the mismatch between research models and classroom realities and the as yet unfaced implications of Logo for teacher training. Teachers can not easily match the expertise of research workers through attending short courses in Logo. Providing the support for Logo learners in the classroom can therefore be extremely difficult. It is not helped by the fact that the introduction provided by Turtle graphics gives an unrepresentatively easy entry point to a very complex language. Discovery learning may well be a profitable venture in turtle graphics but is less effective in developing recursive algorithms and in handling the more complex list processing functions of the language. It can be positively frustrating when dealing with the difficulties of the syntax. Several strategies for dealing with some aspects of the problems outlined above may be advanced. If the wish is to mimic some of the findings of the research Logo environment in the classroom, then some teachers must be trained to a high level of competence; the level of experience that might be required would be akin to that found in the primary school peripatetic French teacher. Further, the problem of how to address Logo to adults or initial and in-service teacher training programs needs to be considered. Little evidence has been produced to suggest that this training is best tackled in the same ways that might be used with young learners. Radburn[lO] has likened the present Logo training initiatives to April snow-short lived but leaving a nasty mess. The question of agreeing a Logo standard ought to be tackled and attention paid to the debates that are taking place about the structure and syntax of other related computer languages. This should point to better integration in computer education that recognises the importance of the first language and the developmental pathway that is to be followed. One of the emerging problems for teachers working with Logo is how to best prepare and foster the skills required for recursion. Without this, a natural barrier to full utilisation of the language appears to be met. Only when we turn to the fullness of the research that has been undertaken on other operations such as addition and subtraction, do we realise that we know very little about the important Logo concept of recursion and how children might acquire the technique. Against this background, there has been a tendency to rationalise work with Logo into more manageable subsets. Some teachers, for example, concentrate solely on turtle geometries. This approach can be encouraged and extended into three further subsets of activity-the use of

112

JOHN LAYMANand WENDYHALL

problem-solving microworlds, list processing toolboxes and control technology---each requires a considerable amount of support material.

of which

REFERENCES 1. Papert S., Mindsforms. Harvester Press (1980). 2. Bork A., The fourth revolution-computers and learning. In Using Microcomputers in Schools (Edited by Terry C.). Croom Helm (I 984). 3, DiJkstra E. W., How do we tell the Truths that Hurt? SIGPLAN Nor. 17(5). 13-15 (1982). 4. Hoyies C. et al., Using Logo in the mathematics dassroom. In Ahances in CAL (Edited by Smith P. R.). Pergamon Press (1986). 5. Goodyear P., Logo: A Guide IO Learning Through Programming. Ellis Horwood (1984). 6. Ross P., Logo Programming. Addison-Wesley (1983). 7. Lawler R. W., Computer Experience and Cognirive Detlelopment. Wiley (1985). 8. de Corte E. and Verschaffel L., Effects of computer experience on children’s thinking skills. Paper presented at the lnrerna~ional Conference on “Children in an informarion Age”. Varna, Bulgaria (May 1985). 9. Wirth N., Aigorjfhms + Darn Srrucrures = Programs. Prentice-Ha11 (1976). IO. Radbum D., in Posing and Solving Problems with Logo (Tutor Guidefines). C.E.T.. London (1986).