Children and Programming

Abstract

Programming as a concept is providing something with a simple set of instructions to execute on its own, or with rules to follow. Operating a microwave may be considered programming. Driving a car, however, may not, since the car-system cannot work without constant user intervention. Given this broad scope, there is no reason why children should not be able to write a simple programme in a manner akin to the man in Searle's hypothetical 'Chinese Room'.

More simply, a child can surely give an instruction – anyone can. All she needs to do is to state her wish clearly enough for the second party to understand. When the wish becomes complex , all she needs to do is to break it down into smaller, simpler 'atomic instructions'.

Imagine a child like Saint-Expéury's Little Prince asking you to draw her a sheep: at first you draw a nice ship, but then she tells you that was not the sheep she wanted. You ask her what a sheep looks like, and she explains that a sheep has four legs, fluffy ears and wool. Naturally, if you have seen animals before you won't need to ask how many eyes a sheep has. Whether you noticed it or not, she has just programmed you to draw her a sheep. If she ever wants you to draw her a sheep again, all she'll need to do is to ask you to 'execute' the "draw me a sheep" programme she has previously 'written'.

The big problem is therefore: Can children say what they want clearly enough for a computer to understand?

Any solution to this problem shall have to be both syntactic and semantical. In other words, it shall have to address both what the child is saying and how she says it.
For the young novice programmer, the syntax should be as varied as possible – voice-operated and graphically driven as well as textual. Any textual symbols should both resemble that child's native language, and be tolerant of spelling mistakes and other linguistic errors children are prone to.

Handling semantics is more complicated by far. However several strategies may be employed by the second party in order to 'understand' the 'programmer' . One such strategy is context analysis (if you previously talked about animals, it is more likely that the child is interested in a drawing of a four-legged critter than in a sketch of a yacht).

Another semantic issue is code-evaluation: when assigning a task, applying a well-defined goal-list might enable the system to understand whether the child's programme-code does what it is supposed to. This might involve checking the output, checking the variables used, looking for certain command words in the code, or analyzing the child's workflow and searching for indications for whether or not the assignment was properly understood.

It may sound as if creating a programming tool for children is tedious and fussy, but the advantages of such a venture exceed its disadvantages. A child that can write a program can also plan a well organized set of instructions under extremely narrow constraints set by the computer. Such an ability also benefits a child's social development, since interpersonal communication works in a similar way – even though one expresses one's desires using language (not 'user actions') constrained by situation and by culture rather than by computer algorithms.

1 - In Minds, Brains, and Programs (1980), Searle posited a man inside a closed room with a rule-book. This man was provided with notes containing certain symbols and instructed that whenever he was given a note he was to look for the symbols in the rule-book and respond accordingly. Unbeknownst to the man, the room is located in China and the notes contain questions in Chinese. Even though he does not speak a word of Chinese, he is still able, using his rule-book, to respond correctly to each question. Based on this, Searle asks the following: suppose this person learns the book by heart. Can we say he speaks Chinese? On the one hand, he knows the answers to all possible questions. On the other hand, he doesn't understand the meaning of what he says.

Asking children to program doesn't require them to understand the meaning of their instructions or the theoretical background behind them. All it requires is that they understand that certain actions result in certain specified outputs, and that a certain set of simple actions, when executed, shall produce more complex results.
Back

© 2007. All rights reserved.