Teach your kids programming. (Logo, Basic) Edward H. Carlson.

Teach Your Kids Programming

Learning a programming language yourself is one thing. Helping your child learn programming is another. Although we are about seven years into the computer revolution, there is as yet little information to guide and assist parents in teaching programming to their children. This article discusses which concepts and facts are appropriate to be learned, points out some differences in the ways adults and children learn, and outlines methods that work in home teaching of programming. At the end is a list of programs and manuals that are helpful to children learning programming.

This article was born out of my recent experiences in helping organize and teach the "Computers and You' summer camp at Michigan State University (using Pets), writing Basic manuals for children in the age range 10 to 14 years, and more recently, working with Logo.

There has been a spate of courses recently to teach "computer literacy.' I advocate going beyond literacy to actual competence in programming. The reasons are several, and the best exposition of them is given by Seymour Papert in his book Mindstorms: Children, Computers and Powerful Ideas. Much of what follows in this article is influenced by Papert's ideas and those of his mentor Piaget. I urge my adult interested in computing and children read Mindstorms.

Procedures are the thing. Papert points out that up to now our culture has been relatively lean in opportunities for children to learn and practice with procedures. Perhaps the greatest change that computers will bring our society is the reversal of this state of affairs.

Procedures in programming are named, broken down into steps, modified, arranged in hierarchical calling sequences, found to be in error (often!), and debugged. They perform a wide variety of functions: games, graphics displays, robot control, sound, speech and music. By contrast, the procedures learned in traditional schooling are typified by long division in arithmetic. They are often learned by rote, and cannot easily be manipulated or experimented with by the student.

The impact made by computing is enhanced by a process called "syntonic learning' by Papert. It involves the transfer or modeling of ideas from some familiar domain of activity to a more abstract domain. The mechanical turtle was invented to give young children a concrete object to manipulate with their programs. Graphics turtles on the screen serve the same purpose.

Another impact that computers can have on children does not involve programming at all. It is the freedom from drudgery that word processors give children learning to write compositions. Since much of the labor of text revision is removed, children can be more critical of the content and mode of presentation of their thoughts.

Choosing a programming language for your child to learn involves several factors: the age of the child, which computer is available, cost of software, and social questions such as what local schools, the child's friends and so forth are doing.

Logo has been designed to be an easy entry language for children. Its turtle graphics, simple syntax, and emphasis on procedure calling are all valuable features. However, its lisp-like "tree' structure is quite different from the Basic, Fortran, and assembly language grouping.

Because it is still by far the most widely used language for microcomputers, I will concentrate on the teaching of Basic to children. However, much of what I say has broader implications for children and learning.

The Children

One should adjust teaching methods and goals to the development age of the child. Here are some guidelines:

Toddler, through second grade. You cannot depend on reading or arithmetic skills. The children may start with "one finger' turtle graphics (Logo or the Nibble program) and advance to procedures and true programming as seems appropriate.

Grades 3 through 6. These students have adequate reading and arithmetic skills, but verbal teaching and hands-on trials are the most important modes for learning. The abstract reasoning ability of children in this age group is relatively undeveloped. The book by Larsen (described later) is at the right level.

Grades 7 through 9. At about age 12, children have finished a growth spurt in abstract reasoning. From here on, learning adult level programming is feasible. However, the methods that children bring to learning are different from those of adults, and adult level manuals are rarely suitable for them.

Grades 10 through 12. Adult texts and teaching methods may be used. Students still have a relatively small kit of models of the world with which to generate programming ideas.

These guidelines are approximate, and individual children vary considerably. However, even very bright children under the age of 12 may be slow in mastering the more abstract parts of programming, and it is unwise to push them beyond their current interests and abilities.

Differences Between Children and Adults

The little people have their own way of getting along in the world. Following are some differences that one notices between children and adults. Of course, everyone, adult and child alike, really falls somewhere between the extremes described here.

The child: holistic, practical, easily swamped by details.

The adult: understands by mastering the details, mastering relationships between details, and arriving at a theoretical model of the situation.

The child: relatively inexperienced, few models of the world.

The adult: has many models and looks for similarities to past experiences.

The child: slow at typing and prone to giving up when boring portions of the task need doing.

The adult: Better typing skills, and tolerant of boring tasks.

Naturally, being adults ourselves, we feel that our duty lies in helping the child to become like us. However, you and your child will be more successful if you allow him to approach programming in his own style.

What Exactly Is Programming?

There are some interesting misconceptions about programming. Most people think it is similar to mathematics. In fact, it often turns out that way only because the adults most interested in programming typically are skilled in math. But the child is not usually skilled in math. He may be skilled in arithmetic, but there are children's activities that come much closer to programming than does arithmetic.

One of these is playing with building blocks. Just as a bag full of blocks has many copies of a relatively small number of standard sizes and shapes, a Basic program uses a small set of standardized commands. Yet in each case, an intricate and original structure can be built. Creativity rarely shows up at the individual unit level (a new use of the triangle block). It shows more often in combinations using a few units (certain ways of building walls or tower bases) and most often at the large scale (a unique and imaginative castle built from the blocks).

Writing is a familiar school activity that forms a model for programming. Writing a one page theme on "What I Like About Springtime' involves organizing your thoughts on several scales, from the topic as a whole down to paragraph and sentence levels. Finally, spelling, grammar and punctuation must be correct. The analogy to writing a Basic program is very close.

And what about arithmetic? To the extent that it is drill on arithmetic facts and memorization of procedures such as the addition of fractions, it is not very similar to programming. Of course, programs usually use some arithmetic: for example to place dots on the screen in building a picture. And story problems in arithmetic (which children usually find very hard) require skills in problem solving that are also required in writing programs.

Teach These Concepts

Children have the most trouble learning concepts. (They pick up the syntax and commands at a reasonable rate.) A good manual presents the teacher with a list of concepts that should be mastered, arranged in the order in which the material is presented. Here is such a list, followed by comments, and tuned up for Microsoft Basic.

1. What you see on the screen is not what is in memory.

2. Memory. Think of it as a shelf of boxes. Each box has a label on the front and the value of the variable inside.

3. The boxes are of three kinds, lines (of the program), string variables, numerical variables.

4. A program is a list of commands performed in order.

5. The immediate mode and the run mode.

6. Variable naming, single letter names first.

7. Flow of control.

GOTO . . .

timing loop

FOR . . . NEXT

IF . . . THEN all on one line

IF . . . THEN branching to another line

8. Screen graphics. Cartesian coordinates.

9. Subroutines and "mind size bites.'

10. Task organization: initialization; instructions and prompts; main loop: calls subroutines; finish and graceful exit of program.

11. Format of a Basic program.

12. Debugging is a natural part of programming, and should be done in an organized way.

Comments On The Concepts

The box metaphor applied to memory is very powerful and should be referred to at every opportunity. For younger children, a set of similar cartons (e.g. the bottoms of cardboard quart milk cartons) can be used to illustrate the process with a few short sample programs. Each carton has a label on the front, and the contents are program lines (during the program writing phase) or variable values (during the running of the program). Write the name of the variable (or the line number) on the label, then put a scrap of paper with the value of the variable (or the Basic line) in the box.

Children enjoy seeing the "real boxes' in the computer. Show them the memory chips in the computer, stressing that each contains thousands of boxes. Better, get an EPROM with its transparent window revealing the chip and a powerful magnifying glass, and show them the rows of boxes. Of course, even under magnification, imagination is required to resolve the gates (boxes) in their rows.

The immediate mode has several other names: edit mode, calculator mode, etc. This is where it is better to avoid over explanation. The child's natural holistic and practical approach will succeed in keeping the immediate mode and the run mode separate. You need only keep an eye on things and straighten out any confusion.

Variable names are best kept to a single letter. Doing so means less typing, and in short programs there is little need for longer names. The Microsoft naming conventions that only the first two letters count and that embedded reserved words must be avoided create quite a potent source of error and confusion when using longer names.

For the most part, the order in which Basic commands are taught is not too critical. A good manual will introduce commands in such an order that interesting (but short) programs can be written right away. However the "flow of control' commands are very abstract and must be introduced slowly and with care. The order shown above works well.

GOTO . . . is an easy introduction to the notion that the orderly flow of control down the program listing can be interrupted. The timing loop is next presented as a unit, without explaining its structure:

30 FOR T = 1 to 1000:NEST

Tell the little squirmers that the computer is "it' in a game of tag, and is counting to 1000 before going on with the program. This timing loop is good for slowing programs down enough to see what is happening.

Next, tell them that the computer can do other things while counting, and introduce the full FOR . . . NEXT loop--slowly.

The conditional, IF . . . THEN, is a very hard concept. Use two metaphors, one visual, the other verbal, to explain it. Examples are given in Figures 3 and 4. First teach IF . . . THEN in which only a single command (not a GOTO)) follows the THEN. Let this digest for a few lessons, then show the use of IF . . . THEN to make larger loops (by using GOTO . . . after the THEN).

Teaching Advanced Concepts

We have come to a natural break in the topics covered. The lessons up to this point have concerned individual commands and simple combinations of them. The programs have been short (up to about 10 lines), yet they can do interesting things both in graphics and in verbal play.

Now the student will attempt larger projects and learn more commands and the fine points about how to handle strings and screen graphics. But it is important to continue teaching the larger aspects of the art of programming. These include task organization and debugging techniques.

The hierarchical organization of a program is made easier by programming from a template. When starting a new program, a standard format is loaded, then filled in. Such a format is given in Listing 1.

Techniques Of Teaching

The following are some rules and procedures that are valuable for teaching children regardless of age.

Preparing Yourself

Buy a good manual written for children the age of your child. If it is written for your brand of computer, great. If it isn't, go through it and change the text to match your computer.

An alternative, if you are proficient in Basic yourself, is to spend a few minutes examining the list of commands, statements, and functions in your version of Basic, dividing them into two classes: early and late. Put the early ones in some order that seems reasonable for teaching. The order is really not critical after the first few commands, but should follow some rational scheme of teaching strings, graphics, and arithmetic commands. The first few commands in the list should be PRINT, RUN, LIST, NEW, REM, INPUT, and GOTO. Group them in sets of three to five. Each set will be one lesson.

Don't start by teaching arithmetic on the computer. It is deadly dull, even for children who find arithmetic easy. Wait until some program requires a little calculation, then start putting it in.

There is a natural tendency to just "teach the commands.' They are so visible. But you must take pains also to teach the concepts, the control structures, and the data types. So identify the concepts to be taught, and then teach them actively, not just letting them trickle down by osmosis.

Look at the list of concepts I gave above. Fold them into the lessons at a slow rate. For children under 12, taper off on the speed with which concepts after GOTO are presented, and "water down' the concepts to boot.

You don't have to be dogmatic about the concepts. Just introduce them informally, matter-of-factly, and at a measured rate.

Interacting With Your Child

How formal should the lessons be? For you, the teacher, the list of topics is complete and well ordered. The extent to which the child does formal lessons with assignments to learn and exercises to do is another matter. Suit the format to the situation in your home.

Your child will need a great deal of over-the-shoulder help for the first hour or so. After that, keep in contact, presenting new ideas and checking the progress of your student against your list of topics. This can be done very informally, but don't assume that the child has covered the ground completely. Check him out!

The learning process should be child driven. Whether you prefer to "let the child play around and discover things' or want to provide more visible guidance, there will be no success unless the child enjoys creating and learning. That means that the subjects of the programs and the techniques used must be one that the child has chosen, either by himself or from a list of suggestions provided by you.

All of your success will depend on keeping programming fun. Several techniques that help in this involve some homework on your part.

First, you can show him programs that you have started and invite the child to complete, alter, or extend them. This alleviates much of the drudgery and focuses attention on new material.

Second, use graphics early and often. Younger children may want to spend a lot of time just drawing when first shown how. This is fine. It develops confidence and keyboard skills, and allows you to introduce line editing to the extent supported by your computer. Wean the student from pure graphics by helping him develop moving graphics. This surely will lead to full fledged programming.

Likewise, strings can be great fun, allowing word play, silliness and mock insults, and introducing a social aspect to computing. Print them at odd spots on the screen, with delays, inverted or flashing letters, or sliding along under the direction of a loop. Include whatever other bells and whistles your computer supports, such as sound.

Periodically, sit at the computer with your child and run through your checklist of commands and concepts to see where the holes in his mastery lie. Then gently guide the child to start filling them in, whether they be just details of syntax or command usage, or whether they be overall organizational concepts.

A conscientious implementation of this program will require a great deal of time and effort. Just remember that the purpose of a good Basic manual is to do much of the work for you. It is not that the author knows Basic better than you do, but that he has done the preliminary organization of material and chosen examples and assignments that the child may appreciate. This still leaves you with the responsibility to help and support the student, and to check that the material is being mastered without large gaps.

So let's go on and examine some of the workbooks and programs that are available for helping children learn programming.

Table: Listing 1. Standard Format For Basic Programs.

Photo: Figure 1. The NEW command. Visual and verbal metaphors are a strong crutch to remembering the meaning of the Basic commands and to understanding concepts. ( Datamost)

Photo: Figure 2. The shelf of boxes metaphor for memory is often mentioned in textbooks. However, it should not only be mentioned, but used completely and consistently for long enough to make it habitual for the student. ( Datamost)

Photo: Figure 3. Young students find the IF . . . THEN construction a difficult concept to grasp. there are two metaphors. The verbal one guided the designers of the Basic language in their choice of words. ( Datamost)

Photo: Figure 4. The fork in the road metaphor for the IF . . . THEN construction. This visual metaphor sees the program listing as a map and is especially important in complicated programs. You should draw lines for flow of control on listings, e.g. from GOTO statements to where they "goto,' to help the student visualize the road map. ( Datamost)