Classic Computer Magazine Archive COMPUTE! ISSUE 10 / MARCH 1981 / PAGE 14

Computers and Society

David D. Thornburg
Innovision
P. O. Box 1317, Los Altos, CA 94022

As R. Buckminster Fuller is fond of pointing out, synergy is the behavior of whole systems which is not predicted by the behavior of the parts taken separately. There have been two recent developments in the personal computer world which, taken together, have the promise of true synergism. These events are the publication of Seymour Papert's long-awaited book: Mindstorms - Children, Computers, and Powerful Ideas (Basic Books), and the introduction of the language PILOT for the Atari computers.

Since this year's theme is communications, it is only appropriate that we spend some time looking at the communication between the user and the computer. While the mechanical means through which this communication takes place are worthy of extensive discussion, I want to concentrate this month on the nature of the language through which we interact with computers, since this also is an area of intense importance.

One might argue that there is little reason for concern with computer languages at this point, since we all have access to fairly powerful versions of BASIC on our computers. We might all agree that BASIC is not terribly hard to learn, and that there are lots of very exciting BASIC programs, and even that BASIC has become the de facto standard computer language for personal computers.

But even with the tremendous penetration of BASIC in the marketplace, I have yet to find any serious computer user (regardless of age) who really likes it. At the primitive level of programming at which we all start, BASIC works pretty well. But as we get more sophisticated, most of us find ourselves writing code that we can't understand two weeks after we write it.

Of course, there are detractors of BASIC who feel that languages like PASCAL are the solution. I must confess that I find PASCAL lacking in that it doesn't encourage the user to sit down and start writing some small part of a program, to play with the bits and pieces, and to then bring everything together later on. This is one area in which BASIC excels. For those who feel that people should be organized when they write a program, PASCAL (and C and other "serious" languages) may very well be the best choice. But what about the new computer user who wants to build a highly interactive program, or the child who wants to explore concepts in geometry through the experience of programming rather than through playing a pre-defined "game" or sitting at a "canned" CAI lesson? These people need languages which are interactive, highly flexible, extraordinarily powerful, and are easy to get started with.

LOGO And PILOT Are Two Such Languages.

While LOGO (as this is being written) does not yet exist on commercial personal computers, it has been the subject of an extensive research program at MIT for more than a decade. Much of the research has been devoted less to the development of computer languages per se, than to the development of a computer assisted learning environment for children. The goals, aspirations and results of this work are the subject of Papert's Mindstorms. It is hard to imagine any person who is intensely concerned with the use of computers by children who would fail to be moved by the sweeping vision implicit in Papert's work. Writing from the perspective of a mathemetician who spent much time with Jean Paiget, Papert presents a variation on the Paigetian model of the "child as builder" in that he sees the need for children to have an abundance of materials with which to build things.

That the computer can be one such building tool is the cornerstone of the many computer literacy activities we see springing up around the world. But, for some educators, Computer Aided Instruction (CAI) has come to mean "computers programming children". There is much to be gained from reversing this process — and that is where the need arises for an exceptionally powerful (and easy to learn) computer language.

LOGO is a highly interactive language which contains a graphics environment containing something called a "Turtle". The Turtle is a non-Euclidian point (having both position and direction, rather than a position alone). The programmer can send messages to the Turtle which cause pictures to be drawn on the display screen. Those of you who are familiar with the Milton Bradley Big Trak are already familiar with this idea. To draw a square on the screen, for example, a child working in the Turtle micro world might type:

FORWARD 100
RIGHT 90
FORWARD 100
RIGHT 90
FORWARD 100
RIGHT 90
FORWARD 100
RIGHT 90

As each instruction is executed, the Turtle first moves forward by 100 units, and then turns right by 90 degrees, drawing its path on the screen as it moves. The desired square thus takes shape on the screen. A programmer wishing to use squares quite frequently might wish to extend the repetoire of commands the Turtle uses by defining a new procedure which the Turtle then "understands":

...children are asked to find the bug by "playing Turtle".

TO SQUARE
REPEAT 4
 FORWARD 100
 RIGHT 90
END

If squares of arbitrary size are required, one might write:

TO SQUARE :SIZE
REPEAT 4
 FORWARD :SIZE
 RIGHT 90
END

and then, anytime a square is desired, one would type, for example,

SQUARE 47

to draw a square with each side 47 units long.

The value of using the Turtle environment in an interactive way is expressed by Papert this way:

Working in Turtle microworlds is a model for what it is to get to know an idea the way you know a person. Students who work in these environments certainly do discover facts, make propositional generalizations, and learn skills. But the primary learning experience is not one of memorizing facts or of practicing skills. Rather, it is getting to know the Turtle, exploring what a Turtle can and cannot do. It is similar to the child's every day activities, such as making mudpies and testing the limits of parental authority — all of which have a component of "getting to know".

One of the more valuable experiences for children involved with computers is learning how to "debug" a program with errors in it. Traditionally, we are taught that errors are bad. Papert shows that, by accepting the inevitability of errors in programs, children can learn to analyze the results of the error and then learn to avoid the error in the future, and to "patch" it in the meantime.

In order to make the debugging process as meaningful as possible, children are asked to find the bug by "playing Turtle". The child then walks around the floor, executing each instruction in turn until the "faulty" instruction is found. But doesn't this method for finding errors lead the child to "thinking like the computer"? Papert sees this experience in a larger context. He says:

In my experience, the fact that I ask myself to "think like a computer" does not close off other epistemologies. It simply opens new ways for approaching thinking. The cultural assimilation of the computer presence will give rise to computer literacy. This phrase is often taken as meaning knowing how to program, or knowing about the varied uses made of computers. But true computer literacy is not just knowing how to make use of computers and computational ideas. It is knowing when it is appropriate to do so.

While Papert is quite heartened by the growth of the personal computer industry, since this growth will result in children having ever easier access to computers, he is frustrated by the limitations of these machines and by the extremely strong penetration of BASIC into the marketplace. He likens BASIC to the QWERTY layout on the keyboard — an artifact from a time when better ways didn't exist. But what of LOGO itself? This language will not be forever locked in the University laboratory. Versions for the TI 99/4 and the Apple computer will probably come into general availability soon.

Even if LOGO, with all its power, doesn't make its appearance in the marketplace soon, I feel that many of Papert's ideas can be implemented today on the small computers whose capabilities he dislikes, through the medium of the language PILOT.

As normally written, PILOT interpreters allow the user to create spectacular text manipulation programs (c.f., the article by Thornburg and Thornburg in the first issue of COMPUTE!). Recent embellishments have made PILOT a splendid language to use on computers with high quality graphics environments, such as the Atari 400 and 800. Those of us who use Atari computers can, with Atari PILOT, do many of the things Papert does with LOGO.

Those of you who are familiar with PILOT probably think of it as a language best suited for creating text-based learning materials. My view of the language is far more open than that, because it is so easy to teach to youngsters. It has long been my dream to see the superb text manipulative power of PILOT extended to give the user similar power to create pictures. The Atari PILOT is the answer to this dream since it contains a graphics package that is, in some ways, very similar to the Turtle graphics of LOGO.

For example, an Atari computer user running PILOT might draw a square this way:

GR: CLEAR
GR: DRAW 25
GR: TURN 90
GR: DRAW 25
GR: TURN 90
GR: DRAW 25
GR: TURN 90
GR: DRAW 25
GR: TURN 90

As each instruction is carried out, the square begins to take shape on the screen. If the user wants to draw lots of squares PILOT allows one to create a "module" as a deferred program. By typing AUTO at the command level, and then typing:

*SQUARE
  GR: 4(DRAW 25; TURN 90)
E:

A module (SQUARE) is created. On leaving the AUTO mode (the AUTO mode automatically places line numbers in front of each statement, thus keeping them from being executed immediately), the user can draw a square by typing:

U : * SQUARE

in which U: is the USE operator found in all versions of PILOT.

My reasons for giving this particular example are two-fold. First, it shows the similarity between the Turtle graphics of Atari PILOT and that of LOGO. Secondly, it shows that PILOT can be used in an interactive mode which combines deferred program segments (modules) with immediate execution of commands.

Can (or should) PILOT replace BASIC? I can only answer by saying that, on the Atari computers, it has for me. I find the language much easier to learn, much easier to use, and capable of doing anything I have ever wanted to do. One of its major features (especially important when working with children) is that a PILOT program can be read by someone other than its author. This is rarely the case for large BASIC programs.

Finally, while most users will want to use PILOT to write self contained programs, I am very happy with the fact that the Atari implementation of PILOT allows the user to interact with the language without having to write "finished" programs. As Papert has shown, the value of "playing around" with an interactive language can be great for all users, and especially for children.

Editor's Note: Atari PILOT is not expected to be available until late spring. Check with your dealer for more information. RCL