LC2b Analyses ^

The Equilibration of Cognitive Structures:

“There is a more important question than the truth of the theory propounded by Piaget, that of its necessity: if by some unfortunate chance, this theory turns out to be false, what would be the next development ?… I even think I could anticipate the answer: it would be the establishment of a new theory which would likewise be an equilibration theory. ”
Seymour Papert, 1976

(This is a free translation of Papert’s comments at a colloquium on the 80th birthday of Jean Piaget.)

Stage Changes vs. Local Learning
Major, rapid changes in problem solving behavior do occur. These robust, well documented phenomena have been referred to as stage changes by Piaget and the Genevan School of psychologists@foot{The phenomena have been largely discovered and documented by Piaget and his collaborators over many years.}. Surely such changes must be addressed by any theory of human learning. Piaget has proposed (Note 1) that such stages occur from the closure of logical operations over all domains of experience, in consequence of which the mind is able to go on to a more advanced stage.

In contrast, I have argued that learning is primarily a local process, in at least two senses. Much of the knowledge constructed by any person is task domain specific. Second, although significant integration effects surely are an important kind of learning, it appears they can be described as the linking of domain-specific cognitive structures into clusters. It is possible to limn such structures and to trace events of structural organization through the fine grain analysis of detailed case studies as in Chapters 2 and 4. Given such a fundamentally atomistic description of mind, one should inquire how large scale uniformities, such as stages manifest, could ever come into existence and how transitions between them could occur.

Is Programming An Experience Which Can Generate Formal Thinking Skills ?
Probing the issue of stage changes, both theoretically and empirically, is a primary theme of this chapter. The means I have taken to explore this issue empirically is an intervention, an attempt to develop structures of a child’s mind which would permit her to perform in a fashion typical of children twice her age through introducing her to skills of programming. The epistemological status of programming experience — as the potential generator of a cognitive ideal for formal thought — permits this material to address directly the issue of the development of the formal stage of thought as described by Piaget. The material of this Chapter exemplifies how formal thought may be seen as a change in the balance between dominant and long-exisiting sub-dominant cognitive structures.

Programming as a rare experience for children at the time of this study
My introducing Miriam to computers and to programming was an “intervention” in her life, a natural experiment whose outcome I committed myself to observe and record. I know a lot about programming and enjoy it, as I enjoy using computers to make learning environments for children. It seemed perfectly natural to me that my children should be among the first to use the things I made. Moreover, since I was a member of a computer sub-culture committed to the study of learning, Miriam’s entry into that environment seemed an opportunity to examine the path of natural learning under cultural pressions which I well knew. Further, at the time we began this project, computers were rarer than they are today, and it was possible for me to know precisely the limits and occasions of Miriam’s computer use. The corpus of material on which the analysis is based is essentially complete with respect to its topic of programming experience.

The Quest
This work is in a tradition committed to understanding the human mind through observing and analyzing the growth of knowledge in minds over time; in this sense, it is in the Piagetian tradition.

A central theme for Piaget — perhaps even a word such as “quest” is appropriate — was to discover if, when, and how “necessary” truth relates to the contingencies of experience. In contrast, my quest, one I have shared with Papert, has a different central commitment: to understand the power of ideas. The quest generates these questions:

– what might an idea be ?
– how do ideas function ?
– how do ideas come to exist and change ?
– how do ideas relate to one another ?
– what could it mean for an idea to be powerful ?
This quest, as Piaget’s, implicates the study of how knowledge grows in individual minds and how that developmental path is affected by the nature of the idea, by the context (both physical and social), and by the previous development of the mind.

Genetic Psychology and AI: Different Representations of Mind
For Piaget, the structure of mind was best represented by his algebraic descriptions. For me, the structure of mind is quite a different thing, the “frozen” control structure of the functioning embodiment of knowledge. I take as given the fragmentary quality of experience and the disparateness of microviews reflecting that experience. My attempt is to explain the development of knowledge witnessed in behavior as the interconnection of disparate microviews at moments of insight. This endeavor was influenced early by the “society theory of mind” (Note 1), at first a joint program undertaken by Minsky and Papert in the mid seventies and now a work by Minsky nearing completion. The difference in representation is crucial. Minsky and Papert claimed that the information sciences offer a repertoire of intellectual tools which will render problems of mind more tractable (Note 2).

While the AI community has invested much effort in the construction of computerized mental models, my focus has been more on the fecundity of computational ideas in their application to concrete problems of cognitive development. The ideas of control structure, concrete descriptions, and learning through debugging are central in my work as they are not in Piaget’s, but I use these ideas as means to an end — which remains Piagetian in essence — to understand the structure and genesis of knowledge.

Stages versus Cognitive Ideals
Papert’s clearest example of a powerful idea, if I understand him right, serves to distinguish his work and mine from Piaget’s formulations, specifically in respect of what a “stage” is. In Piaget’s work, a stage is a period of time during which a mind deals in a characteristic fashion with problems encountered in all domains; when the mind completes the application of powerful operations to all domains, then it becomes possible for it, in effect, to impose a theory-in-practice on the world. Consequently, the mind can then begin to reflect on this concrete theory and deal with all of experience in a more formal and abstract way.

My description of a stage, developed through conversations with Papert, recognizes its existence as a robust phenomenon but eliminates its significance as a theoretical construct for psychology. A stage is no more than the achievement of a common level of performance across those clusters of cognitive structures which are potentially able to be influenced by a specific cognitive ideal. In Papert’s example, when a pre-operational child conserves number and recognizes — for the very first time — that it is possible to know with deductive certainty, the knowledge of number is a concrete exemplar by comparison with which all other problem solving is ad hoc and unsure. If the child is then personally impelled to seek “conservations” of something in her other domains of experience, the knowledge of number for her is both a powerful idea and also an ideal. The speed or delay with which she can invent new conservations (the Piagetian issue of decalage) is an artifact of her overcoming accidental checks to the spread of an epistemologically powerful idea.

A Narrow but Important Claim
Can one trace the spread of such a powerful idea in a child’s mind ? An existence proof of sorts is needed. This has not yet been done for the conservation of number, but it could be done with the method of The Intimate Study. Whether or not such studies are “scientific” depends on one’s theory of doing science. The appropriate criterion at this stage is not replication of results but the disentangling of sequences and relations in observations where the ratio of signal to noise is very low, the paring down of experience — considered in all its complexity and detail — to a crisp model which can disambiguate the causal and circumstantial precedents of major phenomena.

An alternative to tracing the diffusion of number conservation in the mind is to ask if there exist comparable phenomena; what could be another such powerful idea ? From such an inquiry arises Papert’s conjecture that the Piagetian formal stage follows the concrete stage because the experiences which might generate its ideal are not a part of everyday culture, everywhere in the world, as are those which lead to number conservation. Papert has speculated that the experience of computer programming, in the immediate future, may come to serve just such a role. It would be a strong result if someone remote from the formal stage developed through programming experience characteristics of thought related to those typical of formal thinkers. This study has produced such a result. In addition, beyond this narrow but important claim, the study exemplifies how the equilibration of cognitive structures is a profound and obscure fact about which experimenters ought to reflect.

PROGRAMMING AS AN EXPERIMENTAL DOMAIN
The programmable computer is something new under the sun. A computer differs significantly from a book in that it can embody the functioning of intelligence without the need for a living reader or interpreter. Three aspects of computer experience could well lead our children to develop minds different from those we developed at comparable ages. First, concrete experiences with programming variables may lead children to conceive of objects in a more formal way, as specific instantiations of possible objects more than as given things (Note 1). Second, the experience of using programmed repetition and the nesting of programmed repetition may lead children to think more systematically . Finally, the experience of teaching a computer new procedures may lead children to formulate more explicit theories of their own learning, consequently enhancing their reflexivity of thought. Such changes would amount to a significant increase in the analytical ability of very young children.

Practical as well as theoretical factors advance the value of studying how people learn about programming. Writing and debugging procedures are concrete activities in which a subject’s formulation of a problem and changes in analytical ability are clearly revealed. The flexibility of programming permits enough variation to show differences in individual thinking while offering tasks sufficiently constrained that they can be related to preselected issues. The computer presence permits a milieu where children can and will engage in long projects which intermingle significant direction and their own setting of objectives. These practical features create an experimental learning environment which can be more natural than a typical psychological laboratory.

Preview of Results
Although my choice to study Miriam’s learning of programming is theoretically well justified, it is justified also by the results as well. This chapter provides a detailed and lucid example of what it is like for a person to learn something that is essentially new; it provides also an example of what equilibration could actually be like in practice if achieved by competition among different microviews of knowledge; finally, it throws some light on the interaction between factors of cultural influence and personal activity in learning.

I will first present the basic experience of Miriam’s learning about debugging, then turn to its extensions in her life (seen both through anecdotal material and through specific experiments), and finally, to what conclusions we may infer from the material.

PRE-PROGRAMMING COMPUTER EXPERIENCES
Miriam was introduced to computers at the age of four years. The environment I created for her was one of Logo subsystems EEL and ZOOM. EEL was the precursor of the DRAW program described in Chapter One, a shape assembly system (Note 1).

ZOOM was a single key command interface. In both EEL and ZOOM, as one made a drawing, the interface saved the steps of that process and at a later command generated a symbolic procedure to recreate the drawing; I called such an approach for novices “concrete programming” (Note 2).

In neither of these interfaces did Miriam compose symbolic procedures before executing them. As The Intimate Study began, I introduced Miriam to text composition and editing through another procedure generator (Note 3).

Writing Her First Procedure: Details
Miriam was not introduced to procedure writing in until Logo Session 20 (age 6;1;30). I had waited for the right opportunity, one of a special sort, one wherein something she had done and judged her own creation could be extended to a result of which she could be proud. I waited for such an opportunity with confidence. My experiences with other children showed that this environment was rich and epistemologically stable; rich in the sense that a child could recreate on the computer images of objects which were personally meaningful; by epistemologically stable I mean that the combination of a child’s own direction and my knowledge would lead to a situation such as the one that is described below.

Miriam had previously used a procedure generator, TIMES, to create simple iterative procedures. TIMES generated procedures with a kernel, that is, a repeated portion, of her chosen commands and a control structure based on her response to a stop-rule generation query. (See Lawler, 1979, for more detail.) The typical kernel of the procedure was [FORWARD DISTANCE-QUANTITY RIGHT ANGLE-QUANTITY].

When I began the computer portion of Logo Session 20 with the request that we “do something new,” Miriam proposed a kernel with the component [FORWARD 1000]. When I criticized “That’s not new. That’s just a big number,” Miriam suggested a different set of operations FORWARD and LEFT. After keying [FORWARD 20 LEFT], she changed her mind , deciding to use BACK and LEFT. Erasing LEFT she keyed BACK in its place. She judged this an error, but I advised here to keep the back operation with an operand 10, and then to execute some small right turn. I did not know exactly what would come of this move, but I did know that such a kernel would generate arcs with spiney edges. Since Miriam had no specific objective, she was willing to follow my suggestion; she concluded the procedure generation by specifying that an input variable should control the number of iterations of the procedure and named her procedure D123. When she tried to execute D123, Miriam had to work through the problems.

Bob: It says D123 “needs more inputs”… It’s looking for you to tell it something. It wants to do something but it needs more information. Do you know what it needs to know?
Miriam: How much… (Keying) D, 1, 2, 3, space, 30. (As the procedure executed 30 iterations of the kernel, the turtle moved from the home position at center screen to the upper right hand corner of the screen and stopped.)… Out of bounds. (This is her speculation based on the turtle’s closeness to the screen edge.)
Bob: No. It didn’t go out of bounds. It stopped near the edge…. You’ve got a question mark, and it doesn’t say, “Out of bounds.”
Miriam: Goody!
Bob: 30 took it right up to the corner. (Realizing that a RIGHT 90 plus another execution of [D123 30] would return the turtle to the home position)… Want to see a good trick?
Miriam: (Negative noises)
Bob: No? It could really be neat.

Miriam was sufficiently uninterested that her only concern was determining the flavors available in the soda machine. At this point, I could well imagine the shapes made with D123 in Figures 3.1.1 through 3.1.4.

Getting Involved: a claim to ownership
At this point, I could well imagine the shapes made with D123 in Figures 3.1.1 through 3.1.4. and I knew Miriam’s delight in drawing flowers. We continued:

Bob: Would you like to make a flower petal ?… I will tell you how to do it. Do a right turn 90.
Miriam: (Keying RT 90) New line.
Bob: Now type D, 1, 2, 3, space, 30.
Miriam: (Keying as directed, Miriam begins to whine when the petal is not of the sort she considers prototypical) No. I sort of meant two flower petals in a circle.
Bob: Now wait a minute. Type D, 1, 2, 3, 30 again….Now right turn 90 and D, 1, 2, 3, 30.
Miriam: (Keys as directed, then breaks into a broad smile as the two-petal flower of Figure 3.1.3 appears.)… How about a stem?
Bob: Shall we get two more petals, so there’s one big flower in the whole picture?
Miriam: Yeah. It’s going to be mine.

CECDFig 3.1

This expression of a claim to ownership is a clear indication that Miriam had adopted as her own the objective of making a flower from D123. The procedure will be hers, because it will be made from a subprocedure she created with an input value she selected. She can see how her procedure makes parts that assemble to a recognizable entity (a petal) and how the peta1s will make a flower. The flower is hers, even though its first imagining was mine and the knowledge to effect it was mine. This was the point of opportunity.

Gradually Taking Charge
As in much of our work that she found engaging, while I provided the initial impetus and direction, Miriam gradually took charge. Thus in the following segment of dialogue where I began directing Miriam at the keyboard, on her complaint that she was doing all the typing, we changed jobs and she assumed a more dominant role.

Bob: O.K. The first thing we did: D, 1, 2, 3, space, 30. What was the second thing we did?
Miriam: R, T, 90.
Bob: (Keying) 2 for the second thing. R, T, 90. What was the third thing we did?
Miriam: D, 1, 2, 3, space, right — no. Space, 30.
Bob: How much of the picture did that make?
Miriam: One of the petals.
Bob: So that’s the end then, right?…and we type END.
Miriam: Now we type PETAL. P, E, T, A, L….
Bob: New line. What do you think of that?
Miriam: That’s all it does?
Bob: One petal. If we’re going to make a flower, what do we do ?
Miriam: Type: PETAL, PETAL, PETAL, PETAL.
Bob: (Beginning a new procedure) Space TO space FLOWER. What’s the first thing we do? (Keys [1, space] and waits) You just said it: PETAL. What’s the second thing we do? (Keys [2, space]) Same thing we did last time. P, E, T, A, L. What’s the third thing? (Keying)
Miriam: Same thing.
Bob: The fourth thing? (Keying)
Miriam: Same thing.
Bob: The fifth thing?
Miriam: It’s not the same. 100. Back a hundred 90.
Bob: 190. And what else did you do?
Miriam: Nothing.
Bob: Are we finished now when we make our flower that way?
Miriam: Yes.

After I saved her procedure on peripheral storage, Miriam printed twenty copies of her FLOWER (figure 3.1.4.), which the next day she distributed to her kindergarten class for coloring. She was obviously proud of work she felt was her own.

Writing Her First Procedure: Reflections on contingency and learning

One’s grand flights, one’s Sunday baths,
One’s tootings at the weddings of the soul
Occur as they occur….
W. Stevens (The Sense of the Sleight-of-Hand Man)

My delight in this work is clear; but should I be smug ? What could be more accidental than the details by which this flower came into being ? I had no idea that the kernal [FD 20 BK 10 RT 3] would lead this way. Surely Miriam did not select 30 as an input variable because 30 times 3 degrees would be an effective right angle. Was it not was another accident that [RT 90 D123 30] not merely returned the turtle to the home position but did so in an orientation permitting simple repetition of the sequence [D123 30 RT 90 D123 30] to draw four non-overlapping petals ?

My sense of the contingent aspects of this session is different, rather more that these accidents provide a measure of the flexibility required for the easy operation and happy outcomes of developments almost inevitable in computer microcultures. Programming is the specific skill which transforms computer technology from a provided toy into a tool, and more, into a medium wherein one can exercise his imagination in the progressive construction of amazingly complex but comprehensible artifacts. At the MIT Logo project we expected those children participating, who were typically ten years old, to write procedures and to understand what they were doing. If they hang around Logo microcultures long enough, children WILL learn to write procedures. I believe this is true for young children also. In this specific case, Miriam directed me in writing a procedure, but it is clear that she understood well the successive agglomeration of one petal to the next and that the final step was different. This outcome was happy in the sense Miriam understood the FLOWER procedure (this does not imply she understood the subprocedure, D123). But it was happy in another sense also. She did not resist this learning at all. PETAL was a minimal extension of her procedure D123. Everyone knows that petals make flowers, so FLOWER was her own as well.

The Ownership of Knowledge
If I seem to dwell overmuch on the ownership of knowledge, there is good reason. Think of learning as intellectual incorporation. If knowledge is not made your own, whose is it?

On the margin of my mind, I find the flotsam of a ship-wrecked Virgil, “Terque quaterque beati”; these words mean nothing to me and serve only as an ever present mockery of my classical studies. Does not such learning, recalled but not incorporated, go contrary to that coherence for which most vigorous minds struggle? Or is fragmentary comprehension an inescapable aspect of the human condition ?

Subordinated Procedures as Black Boxes; Debugging as an Archetype of Human Reflection
Miriam never, either before or after writing the FLOWER procedure, executed D123 with any other input value than 30. The procedure seems to have been subsumed by its use as a subprocedure (it was not executely separately again), but I infer it maintained an identity in Miriam’s mind from her later suggesting the name “E123” where a new procedure name was required. What we witness is the FUNCTIONAL ISOLATION (not logical closure) of knowledge about this procedure by its subsumption. That is, though personally created, it became a “black box” in the mind, something usable but not understood in detail (Miriam did NOT understand D123, the subprocedure which made PETALS for her FLOWER).

The failure to achieve objectives because of unanticipated interactions among such “black boxes” creates the need for debugging programs (Note 1). This often, but not always, requires analysis and a deeper understranding of a program and its parts. This situation can be taken as the archtype of such concrete experiences as impel and make valuable the reflective ability of the human mind.

PRECURSORS OF DEBUGGING:
PRETTY FLOWER, the product results from the processes of its parts
Miriam’s typical hand-drawn flower consisted of small circular petals surrounding a larger circle; it was quite unlike the flower created by her first procedure. Because making a flower of circles would involve Miriam in a classic turtle geometry bug, I proposed the project of making a different flower design. During the execution of her “Pretty Flower” project, Miriam achieved a particular insight which showed her that one could understand and even explain emergent features of designs based on knowledge of what the subprocedures did. Knowing that the product results from the processes of its parts is an idea prerequisite to debugging, and understanding how a complex figure is created by the functions of the procedure steps is evidence that one does own that idea.

Miriam was initially apathetic, but when I generated a circle-making subprocedure C with a kernel [FD :DISTANCE RT 15], her interest picked up. She selected the input “12” as making a suitable flower heart [C 12], and “4” for making petals [C 4]. I composed a “BUMP” procedure [BK 12 RT 15 BK 12 RT 15] for moving the turtle along the arc of the circular flower heart to that place where the next small circular petal should be placed. During the first session we drew a flower with our C and BUMP procedures but wrote no superprocedure to do so. (See “Shooting her first bug” below.)

CECDFig 3.2

Instead of Debugging
In the next session (Logo Session 49) using the same procedure, C, for the flower heart and petals, Miriam immediately encountered an “inside petal” bug. (The turtle must turn 180 degrees to draw a petal outside the heart’s circumference. See Figure 3.2.2.) Miriam’s reaction to this bug shows the character of her pre-analytic debugging.

Bob: How do we make a petal?
Miriam: I said C, space, 4. (She keys)
Bob: We got a bug there (the “inside-petal” bug of Figure 3.2.2) …. Do you know how to get rid of it?
Miriam: Press stop.
Bob: (Presses “stop” key twice) Didn’t work…. Let’s clear the screen and try again. Take a look at it closely now. You see the bug is that the petal is inside the heart of the flower.
Miriam: Yeah. I forgot….(Speaks to herself) B, K, and…. (Keys CS) C, space, 12…. C, now, outside…. (to herself) B, K, space…. (Keys also 12)
Bob: That’s part of the BUMP procedure.
Miriam: (Keys RT, pauses…. Keys space 15, and continues B, K, space, 12)
Bob: (When she completes the BUMP kernel) That’s pretty good, Miriam. You remembered that very well. Let’s see if it fixes the bug you have.
Miriam: (Keys C, space, 4, and new line)
Bob: We still have it halfway in…. Shall I show you what the problem is?
Miriam: Yeah.

The proposed second fix is vaguely associated with the circumstances of the bug, but the precise connection of bug description, analysis, and fix is nowhere present. The first fix, “press stop,” an appropriate response for some POLY procedure overruns, is even more inappropriate than the second fix in this circumstance. I conclude that both proposals are a kind of context-specific floundering. I fixed the bug; Miriam later gave no evidence of learning from this how to do so.

With the inside petal bug behind us, we completed the pretty flower by keying [C 4 BUMP] over and over. I proposed generating a 12-fold iteration of those Logo commands as a PETALS procedure. Miriam did not object. We were both surprised at the result. (See Figure 3.2.3)

Bob: P, F. (He keys)… Hey! It’s in a different place.
Miriam: But it’s the heart!
Bob: It still has a heart. How did the heart get there?
Miriam: It goes around, in still a circle, and the middle of it.
Bob: How did the middle get there?
Miriam: See. It went around in a circle to make the little circles.

Delighted Surprise at an Emergent Feature
The BUMP procedure traced the twelve arcs of [C 12] as it was used to navigate from the location of one petal to the next. Thus, the circle of the flower’s heart emerged from the process of adding the petals and was not needed for more than the original guidance in constructing the procedure. Miriam was surprised and delighted, but not mystified. The phenomenon continued to attract her and led (in Logo Session 52, 6;4;11) to this more lucid explanation:

Miriam: (As the procedure begins to execute) Know how it gets that circle in there ?… See. Like it attaches the little circles, and has to make a little line to the next one, and that means it makes a circle in there (gestures to the heart of the flower).
Bob: That’s absolutely correct…. It’s the BUMP procedure that goes over from the bottom of one petal to the next ?
Miriam: Yeah.

Miriam spontaneously explained the emergence of the flower heart to me three times. The event marked an insight that clearly was important to her. Her understanding of the emergent effect was possible because she was familiar with the parts the superprocedure ran to create whole. This citation does not exemplify debugging, but it shows analytical development in that the explanation the phenomenon requires is available only through attending to the relations between the steps of the procedure and the resulting figure. The computer environment can foster an analytic mode of thought both because problems arise requiring debugging and because one encounters emergent effects whose explanation “lies only one level of detail down,” i.e. is directly accessible in the encoded steps of the procedure whose execution creates the effect. Such emergent effects become accessible to a person’s understanding if she is familiar with all the elements from which the design emerges, if, in the best case, she has created and used those elements herself.

Although Miriam concluded the project with a procedure, PF, of which she was justifiably proud (she later used it as a decoration on letters she wrote to friends), the debugging cited to this point is non-technical at best.

Shooting Her First Bug: Detail
The outstanding incident in composing Miriam’s PF procedure was the shooting of her “first bug.” The description of the components of debugging seen in this incident will serve us later as a standard for measuring Miriam’s gradual acquisition of the skill of debugging her computer procedures.

After three days of work creating a flower drawing procedure, Miriam made a final test and found a bug. She had drawn, with the turtle executing commands in immediate mode (Note 1), a stem of good proportion, 85 steps long, but had failed to encode in the procedure a [FD 50] command she had executed. Thus her flower appeared with a short stem, 35 steps. Here’s how Miriam shot her first bug:

Bob: Looks pretty good to me.
Miriam: No.
Bob: Oh-oh. We got a bug, huh?
Miriam: Yeah.
Bob: What do we do about it?… What’s our bug?
Miriam:
Miriam: The stem is too short.
Bob: The stem is too short. How long is our stem?… It’s a 35…. I know the trouble. We left out the 50. Remember?
Miriam: Oh yeah.
Bob: You did the 50, but we didn’t write it in.
Miriam: Rats!
Bob: Can you fix it?
Miriam: How?
Bob: You remember what happened when you keyed the line 2 and the blank? And the old one went away and the new one got there?
Miriam: Yeah?
Bob: Key a new line 5.
Miriam: (Keys) 5, space. (Keys the new line character, replacing the FD 35 command with a blank line)
Bob: Would that fix it?… That just made the FORWARD 35 go away. Now your stem will be no-long at all. It will be zero long…. I guess you’d better have a new line 5 that tells the turtle to go forward the right distance.
Miriam: (Keying) 5 ?
Bob: Yeah. Space. And how far should he go?… You had a 35 but you left out the 50. So it should be —
Miriam: (Interrupting) Hold it…. 85… C, S, new line. P, F.
Bob: O.K. Let’s see what’s happening now…. Is that perfect?
Miriam: Yep.
Bob: Beautiful, Miriam. You shot your first bug.

Shooting Her First Bug: Reflections
Reflecting on this dialog, we see the debugging process as analyzable into six steps:

STEPS KEY TO PRECEDING DIALOG
1. bug acceptance Miriam: No.
2. bug description Miriam: The stem is too short.
3. bug analysis Bob: We left out the 50.
4. conceiving the fix Bob: replacement editing
5. implementing the fix Bob: 5 FD 50
6. testing the fix Miriam: keys CS, PF

We notice that in this incident, although Miriam is credited with shooting the bug, steps three to five were dominated by my knowledge and guidance. Because of Miriam’s interest in and success at analyzing this failure (at least in part), subsequently I offered her a didactic introduction to debugging.

Inasmuch as Miriam was immersed in a computer microculture, we must inquire about the extent to which her knowledge of debugging came from general influences of the culture and to what extent it came from particular events of instruction. More importantly, we should also ask what was the character of each component. Before we trace her learning through the detail of these instruction sessions, I should relate incidents which show what sorts of debugging knowledge she absorbed from the microculture of my family and her Logo acquaintances and convey its character.

THE SOCIAL CONTEXT OF PROGRAMMING:
A Personally Important Learning Experience
As a member of the Logo project at the MIT A.I. lab, I was part of a computer culture which welcomed children as members. It is natural then to ask how much the ambience of that microculture contributed to Miriam’s learning about debugging. In my judgment, that contribution was limited in kind but substantial in import.

The focus of our microculture was definitely on solving problems. The activities we engaged in and the terminology we used involved three major aspects: the discovery of interesting problems, the localization of failures, and the giving of advice. Call the first “neat phenomena” and think of the skipping forward and rolling backward of a backspun ping-pong ball. The second we called debugging. The third we referred to as “giving hints” and “knowing good tricks.” The following vignette exhibits “giving hints” as socially provided insights:

“…One of Miriam’s proudest achievements since her sixth birthday has been learning to ride her bicycle successfully without training wheels. She borrowed Robby’s crescent wrench and removed the wheels herself. For several days thereafter, her procedure was as follows: sit on the seat and try to push off; try to get both feet on the pedals before the bike falls over; at the first indication of instability, turn the wheel in the direction of the fall and stuck both feet out to catch oneself.

The procedure is not bad; it’s nearly perfect, in fact. The only flaw was that the bike would fall over after going about three feet. Luckily for Miriam, at this point she received some good advice from our neighbor Jim: “if you start off fast, you won’t fall over.” When Miriam told of this hint, I agreed that Jim’s advice was absolutely correct and added that for problems that look hard or mysterious, if you get one good hint you may find they are not hard at all. Miriam joined Jim’s good advice with a lot of practice. The advice provided the breakthrough she needed, and with the practice she has refined her skill so that now she rides ably.

This evening Miriam met Jim again in the courtyard, showed him her latest achievements with the hula hoop and then went on to tell him she could ride her bike, that she was really good at it, and his “one good hint” had taught her how to do it….”
Vignette 11, 6;1;14

A Stance Towards Communicating Ideas
Not only had Miriam learned about cycling, but she also adopted from me, because of this personally important example, a stance toward communicating ideas.

The terminology surfaced later when Miriam expressed dissatisfaction with a swimming instructor: “That lesson was terrible. She wants you to get your face wet all the time. I’ll never learn to swim from her. She can’t give any good hints. All she knows is get your face wet. What rotten hints !”

This very simple, children’s learning theory focuses not on “basic skills” but on the insights necessary for understanding neat phenomena.

Extensive Studies and Intrusive Sharing: a problem for Method
Even if a microculture is not didactic in its intentions, to the extent that “neat phenomena” are what people want to share with others, the microculture is in fact very intrusive. For instance: Among the tests Miriam performed at the beginning of The Intimate Study was one involving the backspinning of a ping pong ball (Note 1). Since that time, whenever Miriam held a ping pong ball, she would try backspinning it. I bought a hula hoop for a follow up experiment to explore how easily she could generalize backspinning to a superficially different object. I let Miriam play with the hula hoop in the meanwhile. First the Logo project secretary, then a graduate student, then another child independently and spontaneously tried to show Miriam how to backspin the hoop before I could perform my experiment. After the experiment, Miriam played in the hall while I packed up our paraphernalia for the trip home. Marvin Minsky came by and inquired, “Miriam, have you seen this good trick yet?”

In the course of a few days, while the materials were at hand and she was sensitized to the phenomenon, Miriam encountered four separate situations of potential informal instruction. Can one control such informal exposure? I think not, especially in a rich environment and an active culture, because a lively intelligence, sensitized to an engaging phenomenon, will notice its manifestations with only the slightest exposure. Since controlling exposure is not possible the problem becomes methodological: how to be in the right place at the time when insight occurs; how to recognize a significant development and document its occurrence in detail sufficient to support subsequent analysis and interpretation.

I believe the design of this project, as an intensive, protracted, naturalistic study of a bright child in a supportive environment during a recognized period of rapid development focusses on a rich domain of developmental data. The breadth of this study with respect to the child’s life in the home, at play with friends, and under tutelage (at MIT), being both intrusive (thereby perturbing the structures of her mind) and extensive (opening to observation situations not usually attended to) offers a better hope of following the fine structure of developing ideas than does any method restricted to sampling ideas in more limited contexts.

Debugging as an Element of a Learning Theory for use by Children
I turn now to debugging as an important element in this children’s learning theory. The purpose of debugging is to correct procedures that do not work. The function of describing the “bug” is to localize the failure so that the bug can be fixed, excused, or avoided.

The use of debugging is by no means confined to computer procedures, and can be productively extended to every day activities. Consider the following example:

“…Over the past few weeks Robby has shown an interest in playing frisbee. Miriam has tried to play with us, but has been so inept that the game always became a squabble. We three played in the courtyard in a 20-foot triangle. Miriam was supposed to throw to Robby, but even when she did her best, she came nowhere near him. Robby tried to evict Miriam from the game, but could not because the frisbee was hers. I asked if maybe we could fix the bug? Miriam agreed. I described the bug as a “holding-on” bug. We slowly executed her throwing motion, and I noted the point in her swing at which she should let go of the frisbee. On her second throw, and thereafter, Miriam was able to aim the frisbee in Robby’s direction….”
Vignette 70, age:6;4;14

The second frisbee bug, frequently manifest, was one Robby described as a “too-low” bug for which Miriam developed her own fix. This simple example shows how the microculture’s focus on the identification, labeling, and analysis of failures can penetrate to a child’s everyday concerns. More complex examples exist — such as the attempt we three made at folding paper boats following step-by-step instructions from “Curious George Rides a Bike.” There Miriam defined the “no tuck in” bug, the “I don’t know what to do next” bug, and the “last step pull apart” bug.

Neither of these examples shows any explicit analysis by the child following description of the bug. Indeed, the children needed help, and that was precisely the kind of help this microculture provided. Both do show the kinds of incidents which can sensitize someone to an issue, and they exemplify the way a microculture focuses on aspects of a situation. It is not unreasonable to believe that this sort of focusing increases the salience of characters prominent in these situation-aspects and thus constitutes the way in which a microculture gives shape to, i.e. informs or structures, the perspectives of individual minds.

No Badness In Bugs
Miriam’s labeling the “no tuck in” and “last pull apart” bugs exhibits her acceptance of a debugging terminology and focus, but more is required to show its congeniality. One night at dinner Miriam struggled with a pork chop. Both lost — it skidded off her plate and onto the floor. “Miriam!” her mother and I exclaimed. “You know what, Dad?” We waited. “My pork chop’s got a jump on the floor bug,” Miriam concluded, and we burst out laughing. This joke is clear evidence that Miriam was immersed in and very much at home in a microculture where procedural description and terminology were prominent.

Despite such jargon permeating the microculture of our family and the Logo project, there is no evidence that Miriam absorbed anything more than a superficial use of the term “bug” as a neutral label for a specific problem. Was there here an idea she could apply in problem solving? Was there here an idea that could ramify into other cognitive structures? The answer is “no” — but we need to pass through considerably more analysis for that conclusion to be acceptable.

DEBUGGING INSTRUCTION
Miriam’s satisfaction at receiving credit for “shooting” her first bug presented an opportunity to pursue the theme of debugging. The first selection of the following excerpts shows the extent to which analysis, as a method of problem solving, is retrograde to the choices of circumstantial thought. The subsequent selections indicate what Miriam did in preference to analyzing the problem and permit reasoned speculation about the possible sources of guidance she accepted in her thinking.

What did we do? I asked Miriam to fix three malfunctioning procedures, ones that I told her were characteristic of faulty procedures made by other children in the lab. The drawings in the initial “bug”-ridden state are shown in the Figures 3.3.1-6.

CECDFig 3.3

LOLLIPOP (3.3.1) and PTREE (3.3.3) exhibit interface bugs. The typical INTERFACE BUG is the omission of a needed operation between two separable parts of a procedure; execution of an inappropriate operation between part-creating operations is also an interface bug.

A FIX is the operational sequence needed to make a bug disappear. The simplest fix for the LOLLIPOP procedure is a [LEFT 90] inserted between the FORWARD command and the invocation of the C (circle) procedure.

HOUSE (Figure 3.3.2) exhibits a SETUP BUG, that is, one which results from incomplete specification of the initial conditions from which a procedure will execute. The easiest fix for the HOUSE procedure is a [RIGHT 90] inserted before invocation of the BOX subprocedure.

The interface bug of PTREE requires two commands for its fixing, [RIGHT 90] and [BACK 50], inserted between the FORWARD drawing the trunk and the TRI (triangle) of the tree’s habit.

Miriam worked at these three debugging problems during two consecutive sessions (Logo Sessions 52 and 53), the first of which followed her direction, while the second was more didactic. I introduced the theme of debugging to Miriam by a reference to her fixing the bug in the PF (pretty flower) procedure by encoding a command she had left out.

Rejecting the Problem
Although enthusiastic initially, as soon as the first bug became manifest Miriam quickly turned quite negative:

Bob: We’ll start off with one that’s supposed to be a — [invokes the procedure. see Figure 3.3.1]
Miriam: (Interrupting) Lollipop…. Rats! I hate that lollipop.
Bob: You do ?… Well, can you fix it and make it a good one?
Miriam: No.
Bob: Let me — (Prints the procedure on the terminal)….
Miriam: (Covers her eyes) No.
Bob: What’s wrong with it?… What’s the bug?
Miriam: I’ll get rid of that lollipop. Do clearscreen, show turtle — Then I’ll go forward l00. Then, but the circle’s got to (twisting motion with her hand), got to go in the right place.
Bob: Can you make a good lollipop, the way it should be?… You want to do that?
Miriam: Yeah, but… can I do it the way I want ?

Her request meant that she wanted to make “her own” lollipop instead of fixing the flawed procedure. Why did Miriam reject the problem? It is clear that she understood the bug in the sense of being able to describe how this lollipop was different from what a lollipop should be. Miriam accepted the task of drawing a good lollipop but rejected the analytical problem. I believe she did not know what to do or even how to begin analyzing the failure.

Epistemological Stability
Miriam immediately undertook writing her own procedure, PLP (pretty lollipop), revealing her plan as she began coding: “Forward a hundred, then do my C (circle) procedure.”

Miriam: P, L, P (keying the name to test the new procedure), new line. (The same buggy lollipop appears. Miriam laughs.)
Bob: You’ve got a bug there. That’s the same bug the other guy had.
Miriam: (Laughing) I know.
Bob: What are we going to do?
Miriam: Can’t fix it.
Bob: You can’t fix it?
Miriam: No.

This “good luck” of mine that Miriam recreated, as her own, the bug just rejected witnesses the epistemological stability of turtle geometry. Bugs encountered are common and persistent until understood.

Miriam described the failure. Did she analyze the problem? No. She appeared at first to reject it (because she did not know what to do), but this rejection was only temporary. Her “No” above was immediately contravened.

Miriam: No. Hey! We’ll put the circle in and then put the stem in…. I’ll show you….[keys clearscreen] … I will do like C, space, 12. Right?
(The shape appears on the screen when she keys new line)… B, K, space, 1, oh-oh. (Keying. When Miriam hits new line, the bug again is manifest. She looks shocked.)
Rats! (A smile of frustration) Look what happened…. It did the same thing again.

The essence of Miriam’s fix was a pure reordering of the two component steps. Has the bug been analyzed? I think not. Trying to give her a hint, I asked Miriam to pay particular attention to where the center of the circle was, in relation to the stick and the turtle at the end of the procedure. As she watched the turtle draw the circle and complete the lollipop, she said incorrectly that the center of the circle was above the turtle. Miriam’s failure to appreciate how the center of the circle drawn related to the turtle’s initial position makes more firm the conviction that the procedures were not being analyzed in the specific sense of examining the functions of each step and their interactions. I interpret these preceding session transcription excerpts to imply that although Miriam could take direction from my analysis and employ it, she could not herself analyze even this very simple procedure.

Inferences
We could describe Miriam as following a “reordering” heuristic, but what would that mean ? Labeling does not specify where the advice came from. One might imagine that Miriam’s mind contained a separate microview of debugging knowledge (somehow or other accessible to other problem solving microviews) in the fashion of Sussman’s HACKER system (1975). I would prefer to avoid such a claim because it raises the impossible question of how such a structure of general applicability would communicate with all those other structures which might possibly benefit from its advice. An alternative is that such general problem-solving guidance is accessible in the same way as other “invocable” knowledge, through the genetic path. This is possible because general guidance can be seen not as GENERALIZED knowledge but as UNDIFFERENTIATED knowledge (Note 1). If such a view is acceptable, general guidance does not come from some segregated debugging facility but bubbles up to current problems from the most primitive ancestors of all knowledge (Note 2).

Two Rejections
After our break, I took a more directive role.

Bob: Let’s print out pretty lollipop and do it. (He keys, and the shape of PLP, identical to Figure 3.3.1, reappears.) Now what’s wrong?
Miriam: It’s stupid.
Bob: Can you describe to me what’s wrong? It’s not enough to say that it’s stupid.
Miriam: Unh-uh… I guess the lollipop is being broken.
Bob: That’s re-interpreting what’s happened, Miriam. Let’s fix it.
Miriam: Rats.

We witness here two different ways of rejecting the problem: first, by putting it down, a matter of valuation; second, by excusing appearances. Accepting such an excuse as adequate, undercuts the “need” for analysis. The cheerful abandoning of one objective for another when the knowledge-tools are not available for problem solving is a clear example of the kind of cognitive performance which is suitably described as bricolage.

Doing Something Different (1)
I attempted to lead Miriam into a stepwise analysis of the procedure:

Bob: (Printing the text of PLP) We will EDIT, that is, change, pretty lollipop. Is there anything wrong with the clearscreen [step 1]? No. We know what that does and what it is for —
Miriam: But….(Raising up her hand, a gesture indicating she has a new idea). I think I can do it, Daddy…. You know that EEL (the shape manipulation program used earlier) ? We could use that slash or dash and like, turn it. And we could use a circle.
Bob: Can you change this procedure to make the lollipop go to the right place?
Miriam: It really is a good lollipop. Know why?
Bob: Why?
Miriam: Some one bent the stick.

The suggestion to use EEL is a clear example of competitive microview intrusion. Miriam did not complete the analysis of PLP. Stymied, she advanced a completely different and inappropriate proposal for solving the immediate task of making a good lollipop drawing. With that alternative blocked, excusing appearances dominated analyzing the failure. It must be granted Miriam did not analyze the failure of PLP at this time. The strongest claim one could make is that she did not BECAUSE she could not. Such a claim can not be proven, for Miriam might have PREFERRED to do something different.

Doing Something Different (2)
A weaker claim, supported I believe by evidence in the following protocol excerpts, is that she did not analyze PLP AND she COULD NOT HAVE DONE SO AT THIS TIME.

As Miriam took over the keyboard, working on PLP, she exhibited a second form of “doing something different.” Her inclination was to add a fifth line. When I pointed out she could change lines, she rejected my attempt to offer a hint and elected to change line 4 [C 12].

Bob: What are you going to do?
Miriam: I’m going to, ah…say 13 (i.e. type C 13;instead she keys C 31.)
Bob: What’s that going to do? I don’t get it.
Miriam: It’s something different.
Bob: It’s something different, but will it fix the bug?
Miriam: No. I want to see what it does….

Miriam’s wish to “do something different” soon expanded and she asked to abandon lollipop for some other task. We did so.

Discussion
What do we make of this detail observation? Two things, a case and a characterization. The case I wish to make is that Miriam did not understand the debugging of procedures at all. By this I mean specifically that although she could describe a bug as a failure with respect to an objective, she did not analyze bugs; she did not translate such descriptions into the potent operations of the miniworld of turtle geometry. If we think of the six steps of debugging set out earlier, the gap in Miriam’s knowledge was that no step of bug analysis intervened between bug description (in terms of divergence from an objective) and conceiving of the fix to be implemented and tested. The fixes did not take guidance from an analysis of the bugs.

We can characterize Miriam’s behavior in these debugging exercises by specifying two factors. First, when she rejected a problem, the rejection was either a devaluation of the problem (“It’s stupid”), a re-interpretation of the failure (“It really is a good lollipop…. Someone bent the stick”), or the election of some alternative problem (e.g. HOUSE or PTREE instead of LOLLIPOP) in the blind hope it might prove more tractable. The second factor is the sources of guidance which the problems accepted. The source or sources must be inferred from the fixes proposed. Consider Miriam’s attempt to deal with the lollipop bug in terms of the procedures of the EEL interface. This is another example of guidance deriving from the essentially competitive interaction of microviews. Since this issue is treated extensively in Chapter 2, here we will focus on that guidance which is succinctly formulated as a general statement of advice.

The Early Roots of General Heuristics
I want to propose a way of thinking about very general problem solving guidance that is different from generalization of past solutions. Such very general guidance is exhibited by the reordering fix (draw the circle before the line) and the random fix (do something, anything, different). If we pursue interpretations where structure results from genesis, function from structure, and genesis from function, it is a puzzle how this generalized advice could be generated, and further, how it could be made available to a microview with a problem. These considerations lead me to propose that such advice is not generalized by a process of abstraction. Rather, it is undifferentiated in the sense of pertaining to the most fundamental microviews of knowledge about physical reality.

Let me be specific with this example. I have seen Miriam’s infant sister with a large ring in one hand and a small ball in the other, trying to cram both into an open box. Frustrated when trying several times to insert the large ring first, she succeeded by reordering, i.e. she inserted the small ball in the box and tolerated a conclusion with the large ring sitting on top of the box. There is no need to believe the baby owned elaborate descriptions of the objects or reasoned beforehand that the acceptable solution would be achieved. If this reordering fix is a good trick known even to a one year old, it should remain available as supportive guidance, invocable through the genetic path unless countermanded by experience in descendent microviews. The second advisement (“do something, anything, different”) can similarly be attributed to those knowledges of reality constructed in infancy.

TAKING INSTRUCTION Introduction of an Ur-concept
Miriam put me on the defensive with an incipient complaint: “Is this shooting a bug again?” I took the blame for her pique at the previous day’s session by admitting I had asked her to solve hard problems without explaining adequately what she should do. Thus we plunged into a more didactic mode. For example, I stated explicitly that whenever you began debugging, “the first thing you want to do is print out the procedure.” To this Miriam replied with a bored “Yah.”

Miriam agreed I should show her how to fix the buggy lollipop — then immediately proposed her “reorder” fix again. When I would not let her reject the problem by starting over, she expressed antipathy (“Grumble-foo”) and proposed another “random” fix, changing [FD 100] to [BK 100], which — when added to the reorder fix – made the original bug once more manifest (See Figure 3.3.5) At this impasse, I proceeded to fix the bug as a demonstration giving the failure its type name, interface bug:

Bob: This kind of bug is where something should happen between going foward and making the candy part for the top of the lollipop. Let me show you what to do. [She agrees.]
This is a kind of bug where at 3 we should do a left turn 90.
Miriam: Daddy ?… Why won’t the lollipop be pointing, ahm, ah that way? (Gesturing toward our left) That would be silly. Know why ?… ‘Cause then the lollipop would be crooked. (See Figure 3.3.6 for my reconstruction of her conjecture.)

Despite Miriam’s resistance, I altered LOLLIPOP, inserting a LEFT 90 command in step 3. Execution gave Miriam ocular proof that the fix was correct. When I asked her to describe the difference between the perfected procedure and the original, Miriam said, “They didn’t put it in, um, the left 90.”
For the first time, at this juncture, Miriam saw an example of debugging applied to a problem she herself had accepted and long failed to solve. It appears that this incident marked the establishment of a debugging ur-concept.

A First Extension of the Ur-concept
We turned to debugging the HOUSE procedure (See Figure 3.3.2 on card CDCE 3.27) and Miriam took over, directing me to list the procedure:

Bob: What’s wrong with that house?
Miriam: It’s sideways…. They forgot something, too.
Bob: What did they forget?
Miriam: Ah, there should be something different. Right ?…at number 3.

Could it be any clearer that Miriam is imposing the organization of the previous solution on this new problem? I prevented her following this tack by distinguishing the HOUSE bug as a setup bug, different from the previous interface bug, and continued into a second debugging demonstration.

Bob: Let me show you a simple way to fix this bug…. Then we’ll come back and you can tell me how to fix number three. The problem — you can look at this problem as saying the house is turned on its side… If the turtle were pointed in a different direction, then the house might get straightened out. How should we make the turtle turn?
Miriam: I don’t know. Like R, T, …? R, T, space. (Miriam keys 90; Bob keys HOUSE and Miriam keys newline; the house appears correctly oriented.)
Bob: What do you think?
Miriam: I did it!

Miriam took a lot of credit for fixing this bug. In the remaining exercise, debugging PTREE, I let her have more opportunity to earn such credit.

One Step Forward
I asked Miriam to draw a picture of what PTREE should look like before we turned to the computer:

Bob: You type in PTREE now. Is PTREE gonna look like this? (Holding up her drawing)
Miriam: (Keys PTREE) Unh-uh. (See Figure 3.4.1.)
Bob: No. So there’s a bug there.
Miriam: How do I do it? Oh. I get it. I get it. I get it…. You type RT 90. (Laughing)
Bob: You think that will help? It might. O.K. Let’s edit. (Miriam rises to keyboard)
Oh, I’m sorry. You want to type RT 90 before we edit the procedure?
Miriam: Yeah. (Eager interest. Keys RT 90.)
Bob: You think that’s gonna fix it?
Miriam: Yeah. (Does keying to execute PTREE. See Figure 3.4.2.)
Bob: What happened? [Same result as original because clearscreen sets the turtle’s heading to zero]
Miriam: We forgot to edit.

Notice especially that Miriam’s two observations, the RIGHT 90 fix and the “we forgot to edit,” both come out of the problem’s immediate context, in contrast with the reordering fix so prominent with LOLLIPOP. RIGHT 90 was the previous successful fix; its failure here is excused by the fix’s not being integrated with the procedure through editing.

CECDFig 3.4

The Source Of Guidance
If there had been any uncertainty about what provided the guidance for Miriam’s RIGHT 90 fix, that question was answered definitely as Miriam continued with her next proposal:

Miriam: I think I’ll do something… Ed the first one.
Bob: You’re going to change line number 1 ? The first step of the procedur ? (Miriam agrees.) … What do you want to do, Miriam? What do you want to accomplish?
Miriam: I want to try to do it like the house.
Bob: You think this might be a SETUP bug ? (Miriam shakes her head “yes”.)… What other kind of bug could it be ?
Miriam: I dunno. (Keying) CS, space, ST, then RT 90…. New line ?… ( Keys PTREE. See Figure 3.4.3. Turns to me laughing)
Bob: Well, that was a good try. It didn’t work, but it was a good try.
Miriam: Right. I got the tree thing up [the triangle is oriented with a horizontal base].
Bob: Well, hey, that’s pretty good….
Miriam: I give up. I can’t do it.

The RIGHT 90 fix to line 1 appears to have been the only one in Miriam’s repertoire at this moment. The guidance is as concrete as can be. It is possible to see in Miriam’s quick admission of failure a non-obvious advance. That is, having a specific but vague idea of the form of a solution, she no longer tried the “general” and remote forms of guidance witnessed in the previous Logo Session.

Another Step
I redirected her and recalled the LOLLIPOP bug fix.

Bob: This kind of bug is not a setup bug. This kind of bug is an interface bug, like the one you had with LOLLIPOP. Is that a good hint ?
(Miriam agrees.)…
I’m going to take out the RIGHT 90 and we’ll rerun PTREE so it’s back the way it started out…. Now, when I say it’s an interface bug, that means there’s something left out —
Miriam: (Interrupting) Oh. I get it.
Bob: …between the forward and the TRI.
Miriam: (Keys 3, space, and turns to me) I don’t know what to do…. Hold it…. (With hands over the keyboard letter R, looks at me)
Bob: You’re going to do another right turn?… (Miriam keys RT)…and a space, please. (Miriam keys space, 90.) Want to give it a test?
Miriam: (Keys PTREE. See Figure 3.4.4) Too bad.

Miriam’s lucky conjunction of the “line 3” fix of LOLLIPOP with the RIGHT 90 fix of HOUSE (the immediately preceding problem) got her halfway to the two-operation fix required for PTREE — but she did not recognize the outcome as showing progress.

Bug Re-description
I tried to help Miriam see that the last fix was a major step toward a solution. Notice here how the re-description of the bug at this point changes directly into first, an objective for action [at (1)] and then into a specification for a fix (2).

Bob: You know it’s an interface bug and you’ve nearly fixed it. It’s almost fixed. (Pointing to TRIANGLE) You’ve got the tree now in the right position, so you can describe the bug differently. How would you describe the bug now?
Miriam: I don’t know.
Bob: Well, where should the tree be ? Where should the trunk be?… Is that a hint?
Miriam: Unh-uh.
Bob: Look at your picture. Here [on picture] you have the trunk right in the middle of the tree, but up there [on screen] is the trunk on the middle of the tree?
(1) Miriam: Move the top over.
Bob: Good idea. How are you going to do it?
(2a)Miriam: Ah, I don’t know…. Back up the turtle.
Bob: O.K. That’s a good idea. Let’s print out PTREE and you decide where to back up the turtle.
Miriam: (Keys 3)
Bob: Step 3… Are you going to keep your RIGHT 90 in there?
(2b)Miriam: Yeah…. B, K, space, 80.
Bob: What about your right turn 90?
Miriam: I’ll make it [line] 4, then make the TRI 5…. (Completes keying PTREE and new line; a bug is manifest; she then turns to Bob with an uncertain smile of amused frustration — see Figure 3.4.5)
Bob: That’s not bad.
Miriam: I moved the stem only.

Miriam’s rudimentary analysis was vulnerable because a two-step fix was needed, and she failed to consider the interaction of steps.

Completing PTREE
The moment was a critical juncture in Miriam’s debugging of this simple problem. She had begun to analyze the problem in terms that she could see as sensible. The mal-ordering of steps was a complication which pushed her back into floundering.

Sensing that her commitment to solve the problem was declining, I gave her the solution to preserve the sense that this microdomain of experience was truly comprehensible and within her cognitive reach. From this point on, the remaining developments were refinements. It is worth noting, nonetheless, that the drawing of Figure 3.4.6 shows the outcome of a final erroneous fix. Miriam had decided that [BK 80] (line 4) was too much, and in trying to modify that command she encoded [BK 40] as line 3, thus wiping out the right turn. When I listed the procedure and pointed to it, she analyzed this erroneous fix: “I left out the wrong thing.”

Exercises Summary Conclusions about Debugging
If we rise now out of the detail observations, we can see several conclusions stand out. First, the sense in which analysis is retrograde to circumstantial thought is clear. Starting anew is preferred to analyzing another’s failures; even more, it is preferred to analyzing one’s own failures (thus egocentricity as an affective element is not implicated).

Second, the knowledge that Miriam is shown developing about debugging is as concrete as any thought can be, down to the specific operations and step number insertions of solutions put upon unanalyzed problems.

Third, we have seen that it is possible and necessary to distinguish between guidance that derives from immediate and remote cognitive ancestors. Further, this more remote guidance may have the quality of “general” advice because it is fundamental, i.e. implicated in the microviews of infancy and thus able to “bubble up” through the genetic path.

Finally, the clear progress we witness in Miriam’s debugging knowledge from “shooting her first bug” to the complications of debugging the PTREE procedure involves a characterization of the problem (bugs occur because someone left something out) and having a non-empty repertoire of possibly effective actions based on previous, particular experience.

THE PERSON PROJECT Program Structure and Bugs
Near the end of The Intimate Study, our work became more project oriented. Breaking up a project into parts has a programming analog — using a superprocedure to control parts or subprocedures written separately. Because this “structured programming” is more vulnerable to effects from setup and interface bugs than is serial coding, I introduced Miriam to a simple procedure-stub generator to observe the effects of the previous instruction.

MAKEDO, the procedure-stub generator, was intended to be seen initially as analogous to MAKE, the Logo operation used to assign a value to a variable. MAKE declares the existence of a variable. Since it declares the existence of subprocedures, MAKEDO also has implications for control structure. When invoked, MAKEDO asked three questions: what are you going to make; what is the name of the first part; what is the name of the next part. The last question is repeated until the keyword END is entered. MAKEDO generates a superprocedure with the name of the thing you are going to make, whose content is a serial invocation of the procedure stubs named as the first and successive parts of that thing. For example, Miriam declared that she would make a person whose parts were head, body, arms, and legs. MAKEDO generated this superprocedure and four associated procedure stubs (one example shown):

       SUPERPROCEDURE     TYPICAL SUB-PROCEDURE          
       TO PERSON               TO LEGS
       10  HEAD                1  PRINT  [LEGS STUB]
       20  BODY                END
       30  ARMS
       40  LEGS
       END

MAKEDO was very primitive and was intended to serve only as the simplest of introductions to top-down design of procedure structures. Implicit in the generation of such a simple procedure as PERSON is the potential for interface bugs, whose manifestation and fixing we now trace. In what follows, my role was primarily one of consolidating ideas Miriam raised and worked out.

When we began to edit the HEAD stub, Miriam chose to use her C [circle] procedure as a basis. Notable was her avoidance of the “inside ear” bug. (This can be seen as a “preventive fix” to a well-known bug, known from her Pretty Flower project as the “inside petal” bug.) The specificity of her knowledge is clear in her anticipation of this bug’s possibly recurring at the second ear — from which we may infer that she did not understand how the bug derived from the sense of the turtle’s turning. When Miriam suggested drawing the eyes, nose, and mouth, I dissuaded her to avoid complicating navigation on the head circumference and advised proceeding to the next subprocedure, BODY. The stage was set for the next major bug manifestation.

Body-on-the-Ear Bug
I proposed that Miriam make a box body, but she preferred a circle of size larger than the head and encoded [C 16] as the body. With an impending interface bug, I dissuaded her from attempting to add arms before testing the conjunction of HEAD and BODY.

Bob: How ’bout we see how we’re doing now? Type PERSON and see what our PERSON is…. What happened? (See 3.5.1.)
Miriam: (Smiling) Made a mistake.
Bob: You got a bug. Ooog.
Miriam: Ooog. (Laughing)… Ooog.
Bob: Is that a big problem?
Miriam: I think we better do it, i.e. execute [PERSON] to show everything when we make the other parts. So we can see what to do.
Bob: What’s our bug like here? We got the head fine. But this is a very funny person, ’cause his body’s connected to his ear…. Let me ask you something. Can you understand why the body’s up here? At the ear?
Miriam: Yeah. ‘Cause I didn’t back him up (i.e., the turtle) down to the neck.
Bob: How can we do that?
Miriam: (Laughing) We should have said [BUMP BUMP BUMP]

Miriam did not describe the bug in general terms (e.g. the body is on the ear); she described the bug in terms of omitted operations which translate directly into a fix. This description witnesses her analytical understanding of the bug. That is, she relates the steps executed to their effect on the entire drawing.

CECD Fig 3.5

Curl-at-the-Neck Bug
The final phase of the PERSON project was an elaboration wherein Miriam added “hair” to the HEAD procedure. The specific elaboration was not a new theme. While originally drawing pretty flower, Miriam at one point saw the petals as curly hair and noted she could add face parts. She selected the HEAD procedure as the one to modify and executed it. Unable to figure out how to insert curls on the turtle’s first pass between the ears, Miriam chose to do so on a second pass by extending the HEAD procedure. BUMPing up past the right ear, she began commanding and coding curls, i.e. [C 4]. After she placed and encoded the first curl, I asked Miriam to test. When HEAD executed, a bug was manifest, a curl at the neck (See 3.5.3):

Miriam: Noooo! (Complaining, smiling)
Bob: What’s the matter?… Oh, I see. We’ve got a bug there. I think it’s a sort of, must be a SETUP bug.
Miriam: Yeah. We forgot to make the BUMPs that we bumped him up to the ear.

Notice that here also the bug description is presented in an analyzed form which translates directly into a prescription for a fix, not, for example, as “he’s got a curl on his chin.” Miriam added the remaining curls with no problems.

Going Flying
After the HEAD was modified with its complement of curls, testing made manifest Miriam’s last bug:

Bob: You cleared the screen. What are you typing, PERSON ?… There’s the ears…. Here comes the hair…. What are we getting?… (Bug manifestation; see Figure 3.5.4) Hey! Wait a minute.
Miriam: DUMMY! (Big smile and laughs)
Bob: What’s the problem?… That doesn’t look right.
Miriam: (Speech too fast and excited to be comprehensible) The turtle […] and we didn’t get him down to where he should be to make the neck!
Bob: What happened? We didn’t do what, sweety?
Miriam: Get him down to the neck.
Bob: Oh. Gee.
Miriam: I guess he’s flying.
Bob: I don’t think so. No. I think that’s a bona fide bug, Miriam. Let me get a look at that…. Holy smokes…. You think you can fix that?
Miriam: Yeah.

It is the same old interface bug, but great fun in a new guise.

Jokes, Multiple Perspectives, and Learning
It is the same old interface bug, but great fun in a new guise.
But beyond that, and what I find most striking, here, of all the debugging incidents, is the joint appearance of two views of the problem. First, Miriam describes the bug as an omission of ours, a debugging response she has achieved in the Logo Session just described. Still present but now secondary and presented as a joke is the kind of excuse that formerly comprised Miriam’s primary response to an uncomprehended problem. I consider this prima facie evidence for the reality of competition among active mental structures. It marks just the kind of change in dominance that differential development of competing active structures should be expected to bring about. When the final bug was fixed, we went on to test PERSON. Miriam said, “I hope it works,” and I asked, “Do you think it will or won’t?” Her reply: “I hope it will and I think it will….” This note of cautious conviction seems to offer the right tone on which to close a description of debugging experiences.

PRELIMINARY CONCLUSIONS The Beginning of Analysis
I originally had expected text-editing experiences and the establishment of TEXT microviews (Note 1) would prove ancestral to programming knowledges. This did not happen. Nor did Miriam’s extensive use of computer design generators lead her into any analytic debugging.

The main lines of cognitive structure creation and filiation are very clear in the preceding subsections and different from what was expected. Miriam’s experience with the TIMES procedure generator led her to construct a FLOWER microview in her mind. In turn this was ancestral to a PF (pretty flower) microview which was ancestral to a PERSON microview.

Most important is the development of the ANALYTIC view that Miriam constructed out of her debugging experiences. Two aspects of its development stand out. First, her debgging knowledge was applied with power in the PERSON project (recall, for example, how she avoided the potential “inside ear” bug with no prompting whatsoever). Second, the unnaturalness of analysis to Miriam’s mind could be clearly witnessed by what she did instead — rejecting the problem, excusing the result, and applying primitive heuristics. However, once Miriam formed an idea of what it might mean to analyze a failure, she was able to extend that idea and then apply it in the PERSON project to such an extent that even her descriptions of the failures were cast in operational terms.

The Unnaturalness of Analysis
The challenge now confronted is how to describe the application of the debugging knowledge of the ANALYTIC view to her programming PERSON. I can best approach that problem by examining the specific precursors of her use of analysis. Let me separate those precursors into critical incidents and sensitivities. The microcultural focus on procedural description and emergent forms sensitized Miriam both through terminology and through the valuation of certain phenomena. But a sensitivity is not the same as an insight.

Consider that critical insight where Miriam saw that the execution of the PETAL subprocedure created the heart of the flower as an emergent. Miriam was clearly sensitized to emergent phenomena — she had observed spiral arms (“those curly things”) emergent in POLYSPI designs and found them pretty — but during the core of The Intimate Study she never understood where they came from (see Chapter 5). The heart of Pretty Flower was an emergent of a procedure WHOSE STEPS SHE HAD ENCODED. She DID understand it and her thrice volunteered explanation of how the heart appeared testifies how important the incident was to her. I can formulate her insight thus: the steps of a procedure can explain the results of its execution. This may seem so obvious as to appear inane, but Miriam never showed she appreciated that truth previously. Her earlier considerable difficulty with reading procedures and understanding them argues she did not.

Notwithstanding this critical incident of the emerging flower heart, her introduction to debugging showed Miriam could not use that insight in debugging until she owned an ur-concept of what a bug might be: a “bug” is “something they left out,” specifically a LEFT 90 in step 3 (this was immediately supplanted by a RIGHT 90 in step 1). This ur-concept did not derive from her prior experience, was not a product of any specific conflict among internal structures, but was surely a case of her learning by example.

If we can accept this last observation as a fact, we should ask what is its significance. I consider it further evidence about the sense in which analysis is not natural for a mind such as Miriam’s. Logo Session 52 is eloquent testimony that Miriam’s analysis of procedures, a form of symbolic descriptions, was not a spontaneous invention; the PERSON project, however, witnesses that the idea of analysis in this form is natural in the sense of being easily extensible once it has been grasped. On the other hand, the extension of debugging comprehension required for use with PERSON may not have been great — debugging should apply easily to other programming projects. The more important question is whether or not the idea of analysis Miriam acquired through her programming experience was easily extensible and useful in other domains of her life.

THE RAMIFICATIONS OF DEBUGGING EXPERIENCE Jumping Rope: Taking Advice
To the extent that it is a precise (albeit limited) language for describing procedures and their interaction, the jargon of programming should be applicable and useful wherever the analysis of procedures, their interactions, and their failures is of concern.

Two incidents show how effective was the carry-over of procedural description into Miriam’s everyday life after the official end of The Intimate Study. This first shows how she could take advice, the second, that she could give it.

“…At Logo, too, Miriam’s current interests are primarily physical skills. She plays with the computer (Wumpus, and lately some new facilities I’ve shown her), but her first choices are the hula hoop or jump rope. An incident occurring last night gives evidence of what may be the outstanding consequence of her learning during The Intimate Study — what I refer to is her sensitivity to instruction and advice couched in procedure-oriented terms.

Miriam had convinced an older friend, Margaret, to turn a long rope for her jumping, the other end being tied to a doorknob. Miriam tried hard and long to jump into an already turning rope. She attended carefully to the rope and at the right time moved toward the center — but only a short distance in that direction. In consequence, she got her head inside the space, but the turning rope regularly caught her on the arm. Miriam had no good answer when I asked if she could recognize the specific problem. I asked if she could take some advice and said she should jump onto a line between Margaret and the doorknob. Miriam could not. I drew a chalk mark on that line. Miriam took the chalk and drew a box to jump into. Now she was ready.

Her first attempts failed because she jumped into her box without attending to the rope. Then she regressed to watching the rope and moving only a little. Finally, I said, “Miriam, you’ve got a bug in your SETUP procedure. You’re doing only one thing at a time. You have to do both things at once.” On her next try, Miriam jumped into the turning rope successfully. I did not see her thereafter exhibiting either of her two earlier bugs (too little movement or not watching the rope). This incident occupied about three minutes….”
(age 6;7;30)

Miriam clearly could understand and apply advice couched in such terms to domains of experience remote from the computer context in which they were introduced.

Jumping Rope: Giving Advice
The second incident shows that when Miriam was cast in the role of instructor, she could use this programming jargon to communicate advice about failing procedures. The “Physical Skills” experiment (age 6;5;25) was designed to turn the tables on the all-knowing experimenter (me). I never learned to jump rope as a child; Miriam’s skill was considerable. Since I needed exercise, it seemed a most natural, “real-life” experiment that we should see how well Miriam could debug my utterly inadequate flailings. I explained she was the day’s instructor, and we began. (Note: this experiment was recorded on videotape; Miriam’s analyses of my failures below are accurate.)

Bob: Miriam, why don’t you watch the way I do it and tell me what I need to know.
Miriam: You’re jumping too soon. (The “too soon” bug; She demonstrates.)… I watch it. When I see it touch the ground, I jump.
Bob: Let me try it now. (Starting) When I see it touch the ground I jump ? (The rope catches him around the ankles) No. I’m still not doing it right. What’s my problem?
Miriam: (Holding her hands at shoulder level) You hold it up when you’re jumping. (The “pull up” bug.)
Bob: (Tries again — high bounce) Hey! I got one foot over.
Miriam: (Laughs) Wanta see me?… (She jumps)….
Bob: Watch. Here we go again. (Starts jumping…. rope catches on the ankles.) Is it better to use one foot or two feet ?
Miriam: I started out like this. (Miriam jumps in “slow motion”: one foot on ground at a time.)
Bob: Like walking ?… (Tries it: it catches on right foot.) Sort of walking over ?
Miriam: Then I began doing it a little faster…. And next, when I wanted to do two feet — I keep my feet together.
Bob: (Tries: knees flex at horizontal and straighten as rope hits floor and is pulled in; as heels rise, rope hits ankles)
Miriam: You had that pull-up bug.
Bob: (He tries again with Miriam watching closely.) No.
Miriam: You’re jumping too low (The “too low” bug.) and too soon.
Bob: I’ve got a too soon bug.
Miriam: And a low bug.
Bob: And, ah…which should I fix first?
Miriam: The too low bug.
Bob: You watch now and tell me what I’m doing wrong here.(Bob jumps successfully five times, i.e. Bob simultaneously fixes the too low and the too soon bugs)

How naturally Miriam slipped into failure analysis (debugging my procedures)! She specified three distinct bugs, implicitly prescribing the fix by her bug descriptions. This incident provides clear evidence that she and I shared a potent language for communicating procedure-related knowledge.

Meta-cognitive Consequences
Beyond this influence, the effect of Miriam’s immersion in a computer microculture may well have had consequences of a meta-cognitive sort, through raising to salience as themes of discussion issues that are not so forward in other microcultures. For example, one day I succeeded in obtaining for a colleague the keys she had locked in her office; at supper that night (age 6;4;21), Miriam asked “Daddy, how did you ever think of going under the floor ? (The computer center had a raised floor.) Was it because you remembered how good a time we had before when the floor was up ?” This shows that Miriam was capable of reflecting not only on her own thought processes, but mine as well, and even more had formed her own hypothesis to explain my thought process in this instance. Beyond reflecting on the process of thinking, the children even fell, in a jocular way, into reflecting on the structure of mind, thus:

“…Over the past few weeks, in the context of repressing her desire for things she can’t have, Miriam has spoken of having an “eraser mind”. When asked to explain, she proposed the image for thoughts as ideas written on a tablet of paper and subject to erasure.

As supper drew to a close this evening, Miriam cited the existence of another mind (a “liver hating mind”). Remarking my surprise at the thought of her having an eraser mind and another kind as well, I asked if she had any further minds. The topic lay unheeded for a while and I withdrew from the table. The children picked up the theme as a game between themselves. Miriam: “I know another mind I have, a “remembering mind…,” and another, a “stay away from sharks mind.” Robby asked if she had a “talking mind.” “Of course,” responded Miriam, “it has a voice box in it.” (This was a reference to the Votrax voice box attached to the computer system.) Robby continued: “You must also have a learning mind, or all your other minds would be empty.” Miriam agreed and claimed that her learning mind was the biggest one of all. Expanding his theme, Robby said he had an “electric mind” whose function was to manufacture electricity, “for that’s what everything else runs on.” In response to Miriam’s objection that she had no wires inside, Robby pointed to a wall socket and explained that the electricity was carried through the bones to outlets, such as the ones on the wall, where it was made available for local distribution….”
Vignette 88, (age 6;4;31)

The purpose of all this detail is to raise an essential issue for the question of reflexive thought: what experiences could children have that would permit them to develop ancestral reflexive microviews ? The computer microculture is one where such experiences can occur. If a person reads a procedure of her own creation which embodies what she thinks, is it not natural to make the (not necessarily correct) inference that there must be something like that procedure inside her head ? It is this intimate conjunction of computer procedures as the products of human thought processes that advances computer-based microworlds as exemplars for human thought. Since computer procedures are incrementally perfectible through debugging, since debugging is a central concern and theme of computer cultures, engagement in such a microculture should invigorate reflexivity of thought if experience affects the mind at all.

These stories, with their specific detail, are meant to suggest how such changes in experience may become manifest in behavior. We do not expect six year olds to think as adolescents do, but we may expect different experiences with a reflexive component to alter the balance of structures dominating their behavior.

EQUILIBRATION AND STAGES
Problems can only be confronted when the are assimilated to the cognitive structures of the mind. Thus problems may be deformed inadvertently because the mind has NO adequate representation and can not deal with an aspect of the problem whose very existence it can not recognize. Further, they may be deformed in a representational sense to structures developed through analagous microviews of experience. Even in the case where the cognitive structures are not adequate to the problems confronted, the structure of the mind is typically richer and more complex than the specific tasks it confronts at any time. In what follows, we will see not merely microviews of knowledge which dominate problem solving behavior but also the existence of sub-dominant microviews which do not normally dominate behavior but which can with intervention do so. Having seen what Miriam learned about programming, I turn now to the issue of how that new knowledge entered in equilibrium with the dominant structures of her mind.

Stage Reconfiguration
The robust regularities of behavior discovered by Piaget and witnessed by years of extensive experimentation are emergents from the development and functioning of the computational processes of the mind. My central concern is to describe in detail functioning structures which could replicate the growth of knowledge as we are able to witness it in a human’s interaction with the world.

If the stages discovered by Piaget are less than logically necessary in their embodiments in human minds, it should be possible to change them. One might imagine analyzing the knowledges and skills which comprise the structures behind the stage-defining behavior and recombining them in some different configuration. The possibility of doing so I have named “the stage reconfiguration conjecture (Note 1).

Even if it is POSSIBLE to reconfigure the components from which stages emerge, doing so may not be EASY. The robustness of Piaget’s results in different cultural settings suggests how difficult effecting such a change might be. Even more, the logical possibility does not at all imply that an attempt to do so may be feasible in ANY particular case.

At a public lecture, Papert suggested that performance on the bead families task (Note 2) might show some effects from computer experience bearing on systematicity of thought. This “offhand” but serious public proposal was less a theory-falsifying prediction than a suggestion of what sorts of effects might be seen if the general viewpoint was more or less correct on the large scale. I added the Piagetian bead families task to the repertoire of experiments which Miriam underwent at the beginning and end of The Intimate Study, not to test the hypothesis but to explore and comprehend what might or might not be a major phenomenon in the future.

A Quasi-Standard Experiment Shape Families
Where Piaget offered his subject piles of colored beads and asked him to make all combinations of those beads, I gave Miriam piles of cardboard pieces cut in various shapes. Our experiment then used “shape families” to explore how a child goes about making combinations.

Initially, Miriam’s dominant way of conceiving of the task was similar to the examples Piaget describes as “crossed juxtapositions.” This confirms that Miriam’s dominant structures were similar to those for children about eight years (Note 1). After I asked her to figure out all the possible ways of putting two shapes together to make a family, Miriam made the arrangement of Figure 3.6.

CECDFig 3.6

Bob: Can you tell me what your procedure is? It looks like a very interesting one.
Miriam: I don’t know what it is. I’ll tell you when I’m done.
Bob: Will you be certain that you got all the couples you can possibly make?
Miriam: Yes.
Bob: How will you be certain? How will you know?
Miriam: I’ll just look. (Starts working on a third column.)

Intervening
When Miriam had completed the arrangement of Figure 3.6, I began intervening, relating her experiment to computer based activities. What is important to notice is how Miriam responded to these interventions and how capable she was of doing so.

Bob: Let me give you a hint. Can I?
Miriam: Yeah.
Bob: You did that very well. You found a whole bunch of them. But there might be some we missed…. Do you remember the idea of making shape families (note x) ?
Miriam: Yeah.
Bob: You take all the shapes that are pretty much the same, and you change just one part.
Miriam: Uh-huh.
Bob: Can you do something like that ? With these pieces of cardboard here ? Let’s pick one piece, say, the triangles. Can we be certain that we have every one that has a triangle in it ?
Miriam: Yeah… Take each one and put one down. (Places two shapes, a triangle and a house….Places triangle.)
Bob: And a triangle and a what?
Miriam: Circle. (Places it next.)… Triangle and diamond. (Placing them in column.)… Triangle and a bar (placing them.)… (After a pause) Ha ha!… Another. (Places triangle and square.)
Bob: You’ve got a triangle and each different piece. Would it be fair, do you think, would it be a good couple if you had two that were the same ?

Note X: This is an explicit reference to activities of a Logo Session wherein we generated collections of related POLYSPIRAL designs by changing one variable of three input to a procedure.

Miriam did not immediately apply this advice to the collection of triangle couples. Instead she volunteered to start a new collection.

Miriam: I’ll start with the houses now. (Places house-house couple) Houses…. Circle…. House and rect — diamond. (Placing those; then Miriam reaches to top of prior column to place two triangles; places house and square in the houses column…. Pause, no action.)
Bob: Sounds like you’re gritting your teeth there. What’s going on?
Miriam: (Picks up triangle) It’s hard to think of what to do next. (Places house and triangle next to triangle and house)… (Noise) Mmmm. Just one more.
Bob: You’re trying to get it so you have the same number in each bunch? Is that it?
Miriam: (Perceptible but small head nod of agreement) Ha ha! I think I’ve got it…. Yep. I’ve got it. I’ve got it. I’ve got what’s missing…. ( makes singing noises and places house and bar in the houses column.)

The pattern in these two episodes is the common one of Miriam’s behavior. Once started in a specific direction, she takes over and makes the solution her own by extending it.

A Second Intervention
It is easy to suppose that Miriam would have been content to generate the permutations of these six shapes taken two at a time. A second major intervention cut off that path, channeling her behavior into a different way.

Bob: Let’s stop for a minute before you go on.
Miriam: I want to do the squares now.
Bob: I’m glad you want to do that. Can you hold on for a minute ?… (Touching two houses at bottom) Let’s say this is the house family (running finger up the column, tapping each pair) because every one of these has a house. (Miriam assents.) Let me ask you. Do you have a duplication bug ? … Do you know what I mean?
Miriam: No.
Bob: A duplication bug, Miriam, (reaching out to touch the triangle of the triangle-diamond couple) is when you’ve got one member in this family, that’s the same as a member in this family (touches circle of house-circle couple), like if you had (touching triangle and square of triangle-square couple) a triangle and a square…. And over here [in a third column] you had a square and a triangle, say, that would be a duplication bug. Can you check to see if you’ve got a duplication bug ?
Miriam: Ah hah!… I have one…. Found it.
Bob: Can you get rid of it?
Miriam: (Picks house-triangle from house family and throws it aside)

After Miriam exhibited her understanding of the “duplication bug”, I then pointed out to her that the second family had one less couple than the first. Would that I had bitten my tongue! Had it been Miriam’s observation that the second family had one less couple, the following extensions would have been more convincing. She went on —

Bob: Take a look at these two families again. Do they have the same numbers in ?
Miram: Unh-uh.
Bob: The house family has one less, because of the duplication bug.
Miriam: Now I’m gonna start with these squares. I can’t do two things. I can’t have one of these (touching house of house-diamond couple) or I can’t have a triangle. Each one will be a little less.

Miriam completed the family of four “square” couples, then went on to the “bar” or (rectangle) family by laying out three bars in a vertical column before filling in the variable element of each couple. When asked, for example, why she laid out three rectangles, Miriam replied, “You can’t have a triangle, house, or a square.” After setting out five “families” of couples made from six different designs, I posed the problem of completeness:

Bob: You got ’em all now?
Miriam: Yeah. I can only do one more pile.
Bob: What’s that?
Miriam: (Putting them in place) Two circles.

SubDominant Competitive Structures: Dominance by the Epistemological Quality of Particular Experiences
With the specific intrusions documented here, this six year old performed on the task as children normally do only at age age 12 or after. I do not claim that this shows a “stage reconfiguration.” I do claim, on the basis of this evidence, that Miriam had developed different microviews of knowledge to which she could deform presented problems as matters of accident and microcultural intrusion dictate.

These data show that Miriam owned sub-dominant structures at age six similar to those which normally dominate behavior at 12 or later. Other children may also have important experiences which provide specific foundations for analytic thought long before the resulting structures develop such vigor as to dominate their problem solving behavior. These results suggest that the epistemological quality of particular experiences determine the development of analytic capability, NOT age and NOT completing the closure of concrete operations.

The “shape families” experiment has established that one should conceive of task performance not just in terms of what the child does. One should inquire both directly and through interventions what she is capable of to explore the subdominant structures which may subsequently come to the fore. Only through consideration of subdominant structures will incremental explanations of saltations in behavior be possible.

Procedural Description, Articulation, and Reflexive Thought: The Fermi Spool Experiment
Because exploring sub-dominant structures requires intervention, an experimenter must have extensive knowledge of the subject’s experience and a common repertoire of experiences, ideas, and terms to permit revelation of what is in the subject’s mind. For Miriam and me, procedural descriptions, ideas of debugging, theorizing, and even thinking out loud about our own problem solving were central to our study. Such experiences enabled Miriam to articulate what would have been beyond observing otherwise and explain her ability to reflect articulately on thought processes, as witnessed in the example following from the “Fermi Spool” experiment, age 6;5;21.

CECD Fig3.FS

Two disks, a large pencil, and a piece af string are assembled rather like a spool of thread (See 3.7). When the subject pulls gently on the string, which way will the spool roll ?

Bob: (Showing the spool to Miriam) What have I got here ?
Miriam: It’s sort of like a little car…. See, this (points to string around axle) will come rolling off. (She translates both hands away in parallel from the axle’s location) Roll.
Bob: What is going to happen if I pull on this string?
Miriam: (Cupping her hand around the wheel) This will go rolling off (gesture away from the direction of pulling on the string). This (pointing to the string end) will come pulling off. This will pull. And this [the string] will give this the pressure (hands on the axle where the string goes around it) to go. (Hand gesture away from pulling direction of the string.)
Bob: Pressure? (Miriam looks uneasy when challenged on the word)….And something’s gonna make it roll ? That’s your best speculation, right?
Miriam: Yeah. [Miriam reaches out her hands] Can I try it?
Bob: I’m not sure that what you said is true.
Miriam: Neither am I.
Bob: I think this is a good test. Pull it very gently. Your prediction is that it’s gonna go this way. (Pointing gesture in sense opposite to the string end.)
Miriam: Hold it. It might come to me, though.
Bob: Oh ? What would make it come to you?
Miriam: If I pull this [the string end]. It might go rolling this way. (Rotational gesture at the wheel in a sense indicating motion toward the string end)
Bob: (Rotates the axle as she described it) It might roll this way ?
Miriam: Yes. Although that isn’t my best speculation. I speculate it’s gonna go towards you.

The Fermi Spool: Comments
Having been confused myself by this Fermi spool puzzle, I can appreciate Miriam’s uncertainty. I consider her clear articulation of alternate outcomes quite surprising for one so young. She does not, of course, express her sensitivity to two views of the problem in terms an adult might employ, thus: one way of seeing the problem focusses on rotation about the axle, a direct consequence of which would be rolling away from the string end; a second views the string as pulling a object which can pivot at the point where the wheel touches the ground, resulting in the spool’s rolling towards the end of the string. Miriam’s preferred speculation is clearly the former, but she recognizes, at least expresses, an alternate view. From this experiment, I conclude that not only are competing ways of viewing problems simultaneously active, but that also even such a young child as Miriam can give evidence about it. Whatever the causes, Miriam had become sufficiently articulate that she was able to reflect upon her thought.

Miriam on Her Own
A further question is whether Miriam’s sensitivity to procedural description is forward only when she is in the computer laboratory or with me, or whether she has adopted ways of thinking which she carries out to her life beyond my immediate influence. Two other bits of evidence support the latter case. At the beginning of The Intimate Study, Miriam’s solution of arithmetic problems indicated she was typically more concerned with getting the right answer than with perfecting procedures. Six months later, her first grade teacher told her mother that Miriam seemed to enjoy solving problems; her focus was not on getting the answer; she seemed to enjoy the process of working out problems, to take pleasure in the process more than in the result. Clearly, the pressure of my influence was potent in this change, but it is not unreasonable to believe that Miriam’s satisfying experience of programming and debugging inclined her to focus more on processes and less on results than before.

Self-control
A final incident bearing on procedural description also touches directly on the issue of reflexive thought, as well as pointing to ways that this experience may be profoundly important to Miriam in a personal way. Miriam’s work on this project has developed a perspective on self-control which may be quite valuable for her in an entirely separate area of her life — controlling her allergic asthma.

“…While we visited kin one evening, the children played tag. I found Miriam outside, sobbing, very much out of breath, and needing a dose of her wheeze-suppression medicine at that time. Inside, my brother sat down with Miriam, who was still wheezing heavily, in an out-of-the-way place. As he subsequently related their conversation to me, Dave told her of his severe childhood asthma, and how he had found that through conscious effort he could bring his breathing and his emotions under sufficient control to stop an impending asthma attack.

Later in the evening, I accosted Miriam outside. She was again breathing heavily, engaged once more in a game of chase with the boys. I pointed out how she was breathing so heavily I feared she would end up wheezing. She explained to me, “Daddy, I have a very good trick, to stop it when I have trouble breathing.” “How’s that?” I asked. “I just think about it [pointing to her head], and after five minutes, or maybe even 15, I won’t be breathing so hard.” I left Miriam playing tag.

My brother confirmed that this was substantially the advice he had given Miriam and volunteered the judgment that he had never met so young a child so well able to understand the idea of controlling her own processes….”
Vignette 107, (age 6;6;14)

My brother is not an educator nor a psychologist but an engineer, used to thinking in terms of procedures and control. If his judgment is correct, Miriam’s Logo experiences have helped her understand herself in the sense that she can establish a theory of herself as an object.

Although we may criticize a culture or subculture for leading people to think mechanistically about themselves, approximate, wrong theories can be a first step toward something better. Those children’s theories of mind that will grow out of computer cultures are worthy of respect because they can serve as precursors to mature computational theories of mind which look toward sufficient complexity that they do not demean the person.

CONCLUSIONS
It is clear that even the little Miriam learned about programming and debugging changed her ability to describe activities in analytic, procedural terms. Her engagement in The Intimate Study created between us a language which permitted me to intervene in her problem solving in such a way that she showed systematicity of behavior normally appearing spontaneously only in children twice her age. Such systematicity and articulate reflection of thought as Miriam exhibited are characteristic of the formal stage of thought as described by Inhelder and Piaget (1958) and Piaget (1947, 1972). Miriam’s reflection on her own thoughts and about cognitive questions was seen both within experiments and outside the laboratory. The invigorating of articulate, reflexive thought is not so much an artifact of the experiment as it is a consequence of her immersion in a computer microculture.

The intervention of The Intimate Study, teaching Miriam programming and debugging, has made a difference in her mind, albeit a subliminal one with respect to spontaneous expression in behavior. The detail of Miriam’s programming experience and its consequences point to a different way of thinking about stages. Considering her systematic, reflexive, articulate thought as already existing in subdominant cognitive structures (microviews and microview clusters) permits us to imagine the future emergence of formal thought in her mind as a non-mysterious change in the balance of competing, long existing structures. This vision of mind, different as it is from Piaget’s, is an equilibration theory and inescapably Piagetian.

Finally, the extent and depth of probing necessary to establish the existence and the functioning of subdominant cognitive structures — through which alone we can explain stages as saltations emerging in behavior — points to the essential difficulty of studying learning: there is very little learning, and much behavior; as an engineer would put it, the signal to noise ratio is very low.

Print Friendly, PDF & Email