Volume 3, Number 3 - Spring 1995

© Logo Foundation

You may copy and distribute this document for educational purposes provided that you do not charge for such copies and that this copyright notice is reproduced in full.

These are the major articles that appeared in Logo Update, Volume 3, Number 3 - Spring 1995. Minor changes have been made to update information such as addresses. Conference announcements and other items of transient interest that appeared in the original newsletter have not been included here.

In this issue:

Building and Learning With Programmable Bricks by Randy Sargent, Mitchel Resnick, Fred Martin, and Brian Silverman

LEGO /Logo by Marian Rosen

Book Review by Carol Sperry



[TOP]

Building and Learning With Programmable Bricks

by Randy Sargent, Mitchel Resnick, Fred Martin, and Brian Silverman

In many educational computer projects, children control and manipulate worlds in the computer: for example, turtle graphics and animation projects done with Logo.
But instead of controlling and manipulating worlds in the computer, what if children could control and manipulate computers in the world? That is, what if children could spread computation throughout their own personal worlds? For example, a child might attach a tiny computer to a door, then program the computer to make lights turn on automatically whenever anyone enters the room. Or the child might program the computer to greet people as they enter the room ­p; or to sound an alarm if anyone enters the room at night.
In this article, we describe a new technology, called the Programmable Brick, that makes such activities possible, and we explore how this new technology might open new learning opportunities for children. The Programmable Brick is a tiny, portable computer embedded inside a LEGO brick, about the size of a deck of cards. The brick is capable of interacting with the physical world in a large variety of ways (including via sensors and infrared communication). Our hope is that the Programmable Brick will make possible a wide range of new activities for children, encouraging children to see themselves as designers and inventors. At the same time, we believe that these activities could fundamentally change how children think about computers and computational ideas.

LEGO/Logo
The Programmable Brick project extends our previous work with LEGO/Logo (Resnick, Ocko, & Papert, 1988; Resnick, 1993). LEGO/Logo links the popular LEGO construction kit with the Logo programming language. In using LEGO/Logo, children start by building machines out of LEGO pieces, using not only the traditional LEGO building bricks but newer pieces like gears, motors, and sensors. Then they connect their machines to a computer and write programs, using a version of Logo, to control the machines. For example, a child might build a LEGO house with lights, and program the lights to turn on and off at particular times. Then, the child might build a garage, and program the garage door to open whenever a car approached.
In the early years of Logo, its most popular use involved a "floor turtle," a simple mechanical robot connected to the computer by a long "umbilical cord." With the proliferation of personal computers in the late 1970's, the Logo community shifted its focus to "screen turtles." Screen turtles are much faster and more accurate than floor turtles, and thus allow children to create and investigate more complex geometric effects.
In some ways, LEGO/Logo might seem like a throwback to the past, since it brings the turtle off the screen and back into the world. But LEGO/Logo differs from the early Logo floor turtles in several important ways. First of all, LEGO/Logo users are not given ready-made mechanical objects; they build their own machines before programming them. Second, children are not restricted to turtles. Elementary-school students have used LEGO/Logo to build and program a wide assortment of creative machines, including a programmable pop-up toaster, a "chocolate-carob factory" (inspired by the Willy Wonka children's stories), and a machine that sorts LEGO bricks according to their lengths.
LEGO/Logo has some limitations. For one thing, LEGO/Logo machines must be connected to a desktop computer with wires. Wires are a practical nuisance, particularly when children use LEGO/Logo to create mobile "creatures." They get tangled with other objects in the environment, they get twisted in knots as the creature rotates, and they restrict the overall range of the creature. Wires are also a conceptual nuisance. It is difficult to think of a LEGO/Logo machine as an autonomous creature as long as it is attached by an umbilical cord to a computer.
Members of our research group have tried to solve these problems in several ways. We experimented with various technologies for wireless communication to get around the problem of wires. But none of these approaches satisfied us. So we decided to make a more serious modification: we began to build electronics inside the LEGO bricks. We have taken several approaches. The "Braitenberg Brick" system, developed primarily by Fred Martin with inspiration from the book Vehicles (Braitenberg, 1984), is based on a set of low-level "logic bricks" (such as and-gates, flip-flops, and timers). Students can create different behaviors by wiring these bricks together in different ways (Granott, 1990; Hogg, Martin, & Resnick, 1991).
The Braitenberg Bricks have dedicated functions. The flip-flop brick, for instance, has a very specialized function: It holds one bit of state, and it changes that state whenever it receives a sharp transition in its input. But why should we be restricted to dedicated bricks? Why not put a full computer into a LEGO brick? That is what we have done in the Programmable Brick project.

Designing the Programmable Brick
In designing the Programmable Brick, we had several overarching goals. Each goal involved some type of "multiplicity":

Multiple Activities
We wanted the Programmable Brick to support a wide variety of different activities so that it could connect to the interests and experiences of a wide variety of people. While some people might use the Brick to create their own scientific instruments, others might use it to create their own musical instruments.



Multiple Input and Output Modalities
Because we wanted the Programmable Brick to connect to many things in the world, the Brick needed many different types of output devices (such as motors, lights, beepers, infrared transmitters) and input devices (such as touch sensors, sound sensors, light sensors, temperature sensors, infrared receivers.) Indeed, the number of possible applications of the Brick expands greatly with each new input or output device, since each new device can be used in combination with all of the others.

Multiple Processes
Children working on LEGO/Logo projects often want to control two or more things at the same time. For example, they might want to make a Ferris wheel and merry-go-round turn in synchrony, while a song plays in the background and an electric eye automatically counts the rotations of the rides. With standard programming languages, it is very difficult to achieve this effect: The user must explicitly interleave the multiple threads of control. In the Programmable Brick, we wanted to support parallel processing, so that users could easily write programs to control multiple outputs and check multiple sensors all at the same time.

Multiple Bricks
We wanted Programmable Bricks not only to act on their own but to interact with one another. In that way, children could program Bricks to share sensor data with each other, or they could create "colonies" of interacting creatures. These types of activities would enable children to explore the scientific ideas of emergence and self-organization (Resnick, 1994).
Based on these goals, we developed the Programmable Brick shown above. About the size of a deck of cards, the Programmable Brick is based on the Motorola 6811 processor with 256K of non-volatile RAM memory, and it has a wide variety of input-output possibilities. The brick can control four motors or lights at a time, and it can receive inputs from eight sensors. A speaker and microphone are built into the Brick for sampling and emitting sounds. Around the sides of the Brick are six infrared transmitters and receivers, so that the it can communicate with other Programmable Bricks (and other electronic devices). On top is a two-line liquid-crystal display, plus a knob and two buttons for interacting directly with the Brick.
To program the Programmable Brick, you first write programs on a standard personal computer, then download the programs via a cable to the Brick. You can now disconnect the cable and take the Brick with you. The programs remain stored on the Brick. When you want to execute a program on the Brick, you can scroll through a menu of programs on the two-line liquid crystal display screen (using the knob to scroll), then press a button to run the selected program.
Brick Logo, the version of Logo developed by Brian Silverman for the Programmable Brick, has some special features not found in previous versions of LEGO/Logo. Users may write multiple "condition-action" rules that connect sensor stimuli to behavioral reactions. For example, short pieces of Logo code can tell a robot to back up and turn left when the right-hand touch sensor is pressed, and back up and turn right when the left-hand touch sensor is pressed. While these responses are active, one can add rules telling the robot how to respond to a light sensor. With these condition-action rules, it's easy for learners to develop complex behaviors for their robots, while broadening their thinking about the meaning of sensors and programming.

Experiences with the Brick
An Active Environment
One of the earliest projects with the Programmable Brick involved two kids named Andrew and Dennis, aged 11 and 12. They were intrigued with the idea of making an "active environment" making the environment "come alive" and react to people. After some consideration, they decided to make a device to flip on a room's light switch when people entered the room, and flip it off when people left.
Andrew and Dennis decided to try a "bend" sensor to sense the opening of the door. (The bend sensor is a plastic whisker, several inches long, that gives a measure of how much it is bent.) They first tried to mount the sensor to the wall approximately where the doorstop was, but then decided that people would need to open the door very wide before the sensor detected anything. Then, they tried mounting the sensor at the door hinge in such a way that the sensor was bent in proportion to how wide the door was opened.
Before programming, Andrew and Dennis tested the value of the bend sensor at different positions of the door, to find out if they had mounted the sensor well and if the sensor would really give them the information they wanted. Then, they built a LEGO mechanism to flip the light switch on the wall of the room. The mechanism connected a motor, through a gear train, to a lever that pushed against the light switch. They designed their mechanism in such a way that spinning the motor one way would turn the light on, while the reverse direction would turn the light off.
At this point, Andrew and Dennis started focusing on the algorithm for flipping the light switch when the door opened. They realized there was a problem: The door sensor indicated when the door was opened, but it did not tell whether people were entering or exiting the room. They wanted some sort of sensor to tell whether someone was entering the room (in which case their machine should turn on the light) or leaving the room (in which case the machine should turn off the light).
After a little thinking, Andrew and Dennis came up with a clever solution: They attached a LEGO bar to the door handle on one side of the door, and connected a LEGO touch sensor to this bar so that the sensor was activated when someone grasped the door handle. In this way, the Programmable Brick could tell if people were leaving (in which case the door would be opened and the touch sensor in the handle pressed), or if people were entering (the door would open without a signal from the touch switch).
Once the second sensor was in place and tested, they wrote their program:

to light
if (sensor-a < 105)
and touch-b
[turn-off-light]
if (sensor-a < 105)
and not touch-b
[turn-on-light]
end

Run motor forward for 3 seconds:
to turn-off-light
motor-a, this-way
onfor 30
end

Run motor backward for 3 seconds:
to turn-on-light
motor-a, that-way
onfor 30
end

Once Andrew and Dennis got the project working , they ran in and out of the room repeatedly, breaking into big smiles each time the lights switched on and off.

Artificial Creatures
We conducted a four-day workshop at the Boston Museum of Science in which students used Programmable Bricks to create "artificial creatures." The five participants, ages 12 to 16, had three hours of workshop time per day, for a total of 12 hours. Although students had varying amounts of previous experience with LEGO and programming, all were able to make a working programmable "creature" by the end of the workshop.
One focus of this workshop was the use of multiple processes for multiple behaviors. With the Programmable Brick, different simple programs (such as "follow light" or "follow wall") can be run as separate processes. Users can turn these individual programs on and off using the Brick's screen, knob, and buttons. The Brick's software also includes primitives that allow students to turn on and off the different processes under program control. Thus, processes have the ability to start or stop other processes.
Three participants who had not programmed before wrote fairly simple programs for their creatures. One made a creature that followed a line (a piece of tape laid down on the floor). Another made a creature that simply backed up when it hit an obstacle. The third made a creature that backed away from bright light, and had lots of fun playing with his creature using a flashlight.
Mark, who had programmed before, started his project with a single, simple behavior. The creature tried to navigate a path between several rooms using timing only (no sensor feedback): go forward for 20 seconds, turn left, go forward for 15 seconds, turn left, go forward for 20 seconds. This path was intended to make the creature leave the classroom, go down the hall, make a left into a different classroom, and turn left again to try to get out the other classroom's back door. But this simple behavior didn't have much of a chance of working. The second classroom was full of tables and chairs, and the creature invariably hit one or two and got stuck. Sometimes the timing of the path was a little off, or the creature drifted off its planned path, and ran into a wall unexpectedly. For this creature, running into a wall, chair, or table typically meant getting stuck and progressing no further.
To try to deal with this problem, Mark added a second behavior: When the creature ran into an obstacle, it attempted to pilot around the obstacle and end up with roughly the same heading as it had in the first place. The behavior looked like this:

to avoid-obstacles
if touch-a
[spin-right
wait 10
go-forward
wait 10
spin-left
wait 10
go-forward]
end

The added behavior did not completely solve the navigation problem the creature did not navigate its course reliably. However, it typically got much further with this new behavior than without it.

Personal Programming
Brian Silverman and his son Eric mounted a Programmable Brick on Brian's bicycle along with a magnetic sensor that recorded each revolution of the front wheel. This information, along with the Brick's built-in timer, allowed them to keep track of the bike's speed at each point in Brian's daily commute to and from work. The graph below shows one day's commute with the evening trip plotted in reverse on the same graph as the morning trip. Brian slowed down for railroad tracks both coming and going. But an area of high speed in one direction and low speed the other way indicates a hill. Occasionally the speed drops to 0 at a red light.


Out into the World
During the summer of 1994 a one-week Programmable Brick workshop was held for teachers in the "Rhode Island School of the Future." a project led by Janice Kowalczyk. This workshop, led by Fred Martin with Wanda Gleason acting as assistant, was the first occasion on which a group of teachers had used the Programmable Brick technology outside of the MIT laboratory. The twenty participants developed small LEGO robots, controlled by Programmable Bricks, to solve "follow the line" and "get out of the box" challenges.
In the fall we brought the Brick into classrooms. Some of us were uncomfortable with the idea of requiring all students to participate in a competition, as had been done in the summer workshop, because it would impose a kind of performance pressure that might not be desirable. We developed the concept of a "Robotic Park" exhibit in which kids would create robotic LEGO "animals" that could either be noncompetitive show pieces or participate in a simple, fairly standardized performance event.
Work in Mariann Hayward's fourth grade class and John Bilotta's fifth and sixth grade class began in November of 1994. Students worked in teams of three to four and chose animals that they studied and adapted them to be implemented as programmed LEGO constructions. In Mariann's class, students are building a robotic crab, turtle, and alligator; and in John's class, students are building LEGO fish and a dinosaur along with some other LEGO projects that aren't "animals." In all cases, students are developing behaviors in their LEGO constructions that mimic the activity of the actual animals or artifacts. The LEGO crab has a pair of pincers that start snapping when the crab runs into something; the LEGO turtle's head retracts when its nose is bumped; and the LEGO dinosaur is attracted to flashes of light (like the dinosaur in Jurassic Park).
Work in Lee Rabbitt's high school class began in February of 1995. Since they knew there would be only a short time to prepare for the Robotic Park event, students elected to focus specifically on the capabilities needed to solve the performance challenge: obstacle avoidance and light-seeking. After early attempts in which the students wanted to build machines to climb over the obstacles rather than getting around them, students settled on car-like vehicles (adapted from LEGO's wheelchair design in the Control Lab kits) and the use of touch and light sensors. Being teenagers, most of them were quite happy redefining the activity to be building cars rather than animals, and are engaging in the programming aspect of the activity as readily as they did the building.
All of these Programmable Brick activities reap the educational value of "traditional" LEGO/Logo and then some. When working on the LEGO building, students learn about structures, mechanisms, and the process of designing how to be inventors, share ideas, and adapt ideas from existing plans. When working on programming, students learn how to conceptualize and formally express an algorithm to make a mechanical object accomplish some task. Throughout the project, students work cooperatively to solve problems, collaborating and sharing ideas.
As this article goes to press, we are in the final stages of preparation for the Robotic Park exhibition which will be held on April 29, 1995 at the Peace Dale Elementary School. There will be a series of talks and workshops for teachers in the morning, with the exhibition of the children's work in the afternoon. A follow-up workshop for teachers will be held during the summer of 1995.

What's Next?
At the present time there exist 50 Programmable Bricks which are being used in the projects and activities we have described in this article. The pattern of diffusion has been similar to that of the original LEGO/Logo technology a decade ago and of Logo itself before that. It begins with a period of development in the lab at MIT and then in a few closely supported projects in schools and other settings. We expect that the Programmable Brick will eventually become available to the educational community at large.


Acknowledgments

Seymour Papert, Steve Ocko, and Allan Toft have provided encouragement, inspiration, and ideas for the Programmable Brick project. Andrew Blumberg, Fei Hai Chua, Chris Gatta, Hanna Jang, Owen Johnson, Victor Tsou, and Elaine Yang contributed to the development effort. The LEGO Group and the National Science Foundation (Grants 9153719-MDR, 8751190-MDR, and RED-9358519) have provided financial support.


References

Braitenberg, V. Vehicles, MIT Press, Cambridge, MA, 1984

Epistemology and Learning Group Programmable Brick Handbook, MIT Media Lab, Cambridge, MA, 1995

Granott, N. "Puzzled Minds and Weird Creatures: Spontaneous Inquiry and Phases in Knowledge Construction" in I. Harel and S. Papert (Eds.), Constructionism, Ablex, Norwood, NJ, 1991

Hogg, D., Martin, F., & Resnick, M. Braitenberg Creatures, Epistemology and Learning Memo #13, MIT Media Lab, Cambridge, MA, 1991

Martin, F., Circuits to Control: Learning Engineering by Designing Lego Robots, PhD Thesis, MIT, 1994

Resnick, M., Ocko, S., and Papert, S. "LEGO, Logo, and Design" in Children's Environments Quarterly, 5 (4) pp 14-18, 1988

Resnick, M. "Behavior Construction Kits" in Communications of the ACM, 36 (7) pp 64-71, 1993

Resnick, M. Turtles, Termites, and Traffic Jams, MIT Press, Cambridge, MA, 1994

Sargent, R., The LEGO Programmable Brick: Ubiquitous Computing for Kids, Masters Thesis, MIT, 1995


Randy Sargent recently completed his Masters Thesis at MIT
Mitchel Resnick is Professor of Media Arts & Sciences
Fred Martin is a Post Doctoral Researcher
Brian Silverman is a Visiting Scientist and is also Director of Research at Logo Computer Systems, Inc.

The authors may be contacted at:
MIT Media Lab
20 Ames Street, E15-315
Cambridge, MA 02139
rsargent@media.mit.edu
mres@media.mit.edu
fredm@media.mit.edu
bss@media.mit.edu

This article is adapted from a chapter which will appear in the forthcoming book Constructionism in Practice, edited by Yasmin Kafai and Mitchel Resnick, to be published later this year by Lawrence Erlbaum Associates.

[TOP]

LEGO/Logo

by Marian Rosen

At Conway School, each fifth grader gets a four week LEGO/Logo unit taught by the classroom teacher and myself. The site is the classroom with five computers and "The Cart" stuffed with sorted LEGO pieces, idea cards from many different Technic series kits, video tapes of past projects, string, rulers, tape, scales, etc. "Simple Machines" is part of the fifth grade science curriculum. However, a lot more than simple machines gets taught. The crucial idea that underlies LEGO, Logo, and simple machines is that very complex objects can be made by combining simple things.
The number of students who have worked with gears, pulleys, and motors is much smaller than the number who have built things with bricks, plates, and studs. Yet, most of the kids understand how LEGO works. They know that the pieces can be combined and recombined into hundreds of different patterns. They know that some patterns are stronger, some prettier, some more creative, some more functional. They build complex machines made up of the simple machines they have studied.
Pairs of kids pick their level of comfort when using LEGO. Some choose to build exactly what is on an idea card, some start with a card and then modify it, some build totally from their imaginations. For example, during our last session, we had a drill copied from a card, an exercise machine based on a conveyor belt, and an original car wash complete with rotating wheel washers, overhead to and fro rag rack, and drying fans. Others accept a challenge such as building a machine that will lift or drag more than 30 pounds, or one that can balance on a single wire stretched across the room.
The programming part of LEGO/Logo makes the machines more interesting than they would be if they were run just by battery packs. We control speeds making blenders that can mix, mash, and puree (Cheerios and water smell awful!), or vehicles that accelerate and decelerate. We control the direction of the motors, making washing machines that both agitate and spin; cars that move in four directions; and cranes and toasters that go up and down. We use the sensors to make smart machines.
A car equipped with front and rear sensors bounces back and forth in a game played by two students armed with ping pong paddles.
A conveyor belt measures the length of pieces and then dumps them on a second conveyor belt that sorts longer pieces to the right and shorter ones to the left.
A conveyor belt is balanced on a 360 degree rotating machine which is balanced on top of a car. The car goes back and forth, the rotator spins to different headings, and the conveyor belt sorts pieces into six different piles.
A gondola moves along a wire stopping to lower and raise a magnet that picks up paper clips (representing stranded skiers) from the carpet (snow) below.
We use touch sensors to make a joy stick that has four settings and can be used to run many different machines.
Our fifth graders know Logo. They have used it in multiple ways since kindergarten. They know that a program is a complex object made up of sub-procedures which are made up of primitives. They know it, but they don't necessarily think it's very useful. Sometimes a kid asks the equivalent of "Do you want me to have procedures called right.leg and left.leg or can I just call them both legs?" This annoys me because it shows (1) they aren't clear on where to "chunk" their work, (2) don't think it's important, and (3) are doing it just to please me. Worst of all I suspect the kids are correct and that it doesn't make a whole lot of difference how they chunk their programs. But LEGO/Logo projects are different. They give kids good reasons for writing small procedures that are meaningful and are a wonderful model for learning this important skill.
When students first program their machines, they make spaghetti programs that turn the machine on, wait a while, reverse the direction, wait a while, accelerate, wait a while, decelerate, wait a while, etc. There's excitement, but if anything goes wrong, debugging is very difficult. Small programs such as car.on, car.off, rotate.left, rotate.right, open.jaws, close.jaws are much more easily debugged. Many of these short programs are identical except for which motor is being addressed or which direction the electricity flows. Students begin to understand something important about machines - that the motor itself can be programmed in only a few ways, but there can be dozens of different effects depending on how that motor is attached to an engine and moving parts.
LEGO/Logo is a good way to teach the importance of having a subprocedure that can be changed without altering the whole program. Before students get sensors they will write a program, often called waity, that is just a simple wait command. A convertible drives up to a conveyor belt (MacDonalds), does waity as some bricks (Big Macs) roll off the belt into the back seat, and then drives off. As they learn about sensors, students make waity more sophisticated. First it may contain just code that waits until a sensor is tripped. But later students place an order for a certain number of Big Macs, the smart conveyor belt counts them, and the car drives off only after the order has been filled correctly. Waity has evolved from a simple time holder to the most interesting part of the program, and it has done so without disturbing the procedures that cause the convertible to drive up and away again.
Joysticks or keyboard control programs using readchar run best if they rely on small procedures. In the first program for the rescue gondola, the machine had to start at exactly the right place, move carefully to one chosen spot, lower exactly the right length of string on the magnet, etc. It was hard. A little friction on the line, a tangle in the string, a carelessly placed paper clip were each enough to throw off the whole plan. Gradually the programming evolved so that there were four small procedures: gondola.forward, gondola.back, magnet.down, and magnet.up. What's more, each of these commands worked for only a short period of time. The gondola lurched along the string in increments, but that meant that paper clips could be placed anywhere. The magnet inched its way down and back up, but that meant that when we tilted the wire, the magnet could pick up paper clips that were different distances from the wire. Best of all, the students learned a little about the idea of feedback. Depending on how far they needed to move and how far they had gone they could decide on their next command. They learned the idea of controlling something by breaking a complex task into a series of short more easily controlled tasks.
Plastic studs and gears and axles make many machines. A score of primitives make many programs. A half dozen little programs empower students to move machines accurately. Using keyboards or joysticks made of touch sensors, the kids are part of a feedback loop they have created between the machine and the computer. To be successful at this kind of programming, students have to program their ideas in meaningful chunks. I used to think that Logo gave to LEGO, that the machines were made alive and smart by programming. Now I know that LEGO gives back to Logo, that it is a wonderful arena for modeling very important ideas about modular thinking and bite sized ideas.

A LEGO/Logo Project

This project is a 360 degree rotator with a pincher on top. Below is the program to control the rotator. Notice that rotate.right and rotate.left do not stop! The kids understood how to write a procedure with onfor that would move in small steps, but they didn't like it because it was jerky. It was more fun to let the rotator sweep to the left and right because the game was to close.jaws on a little LEGO person at exactly the right time, so that they nabbed it on the run and then dropped it off using open.jaws at exactly the right time to drop it in a bucket.

to control
lto [6 7]
if sensor? = [true false] [close.jaws]
if sensor? = [false true] [open.jaws]
if sensor? = [true true] [rotate.right]
if sensor? = [false fasle] [rotate.left]
if key? [ao stop]
control
end

to rotate.left
tto [b]
setpower 4 setodd on
end

to rotate.right
tto [b]
setpower 4 seteven on
end

to close.jaws
tto [a]
setpower 7 seteven
onfor 20
end

to open.jaws
tto [a]
setpower 7 setodd
onfor 20
end

Marian Rosen is Instructional Technology Coordinator at Conway Elementary School of the Ladue Public Schools. She is also the President of ISTE's SIG Logo. She may be reached at:
Conway Elementary School
9900 Conway Road
St. Louis, MO 63124
314-993-2878
mbrosen@oui.com
 [TOP]

Book Review

by Carol Sperry

I Won't Learn From You:
The Role of Assent in Learning
by Herbert Kohl, Milkweed Editions, Minneapolis, 1991

This book is a must have! In just thirty-nine pages, Herbert Kohl provides myriad examples of why children and adults make decisions to "not-learn," to stay outside any system that threatens their integrity. Culling examples from his own experiences, as well as drawing on his long history as an educator, Kohl shows how learning to "not-learn" can actually be a positive and healthy response to a controlling and often hostile society. This small but insightful tract should be on every teacher's bookshelf. It discusses, simply and reasonably, why learning is often resisted. It intersects mightily with an educational philosophy that many of us in the Logo community hold to be essential in dealing with the mysteries of learning.
Spurred on by a Spanish-speaking grandfather's refusal to learn English so his grandchildren would not forget who they were, Kohl remembers his own experiences as a young boy who chooses to "not-learn" Yiddish, though it would have given him entree to lively discussions in the intimate company of his father and paternal grandparents. It was years later that he realized his decision stemmed from a desire to ally himself with his mother, who could not speak Yiddish; he would not allow himself to be privy to conversations she could not understand. This non-obvious perspective helps us open our minds to a variety of situations that might influence refusal to learn.
Kohl then takes us through a panorama of resisters, including Barry, a first-grader who had been held back by his previous teacher "for being uncooperative, defiant, and 'not ready for the demands of second grade.'" His calculated tantrums had gained him status in the class, frightened his previous teacher and got her to leave him alone. Kohl found Barry to be sensitive and intelligent, the best fighter and athlete in the class and a funny storyteller - "confident and cocky but not rude." He felt he was certainly bright enough to read but had never gotten close enough to a book to do it. But now his reputation was at stake and he would hardly go willingly into the learning process. Kohl's analysis and solution to this problem reads like a mystery story -one that has a happy ending and keeps the child's integrity completely intact. I think this kind of story also gives permission to teachers to follow their own instincts, to be creative - not the stuff you'll find in text books.
We meet Rick, "an articulate, conscious not-learner," who rejected the "conventional values of middle-class life." Rick rebelled against testing, and though he was forced to attend school, he could not be forced to perform tasks that had to do with assessing his abilities. Talented in mathematics, Rick had to "not-learn" very seriously in order to fail algebra three times in high school.
As a graduate student in the sixties, Kohl taught a course at Teachers College in New York City and became friends with a student, Akmir, a member of the Nation of Islam. By relentlessly drawing attention to racist language and statements made in class, Akmir helped Kohl to consider and understand the many ways we think and speak that are racist. This resulted in a growing empathic response to difference and helped Kohl to understand and appreciate, at a later time, the efforts of a young woman who consistently questioned sexist language in class.
These and other stories are told with an ease that helps us feel we are there, meeting these complicated learners, engaging in their experiences, congratulating them on their persistence, and suffering through the difficulties and the occasional unhappy ending. We see here the obvious and not-so-obvious reasons for not-learning, and we can examine our own experiences for other instances. It might cause you to smile ruefully at what you chose to resist; I not-learned how to type, which in those days, I thought, was a one-way ticket to the secretary's pool, and which handicaps me to this day. It might also make you wince at memories of past students whose not-learning you misread. I won't tell you my own memories of those. The message of I Won't Learn From You can provide teachers with a powerful tool for reflecting on their practice and a reason for hesitating to label as failures some students who are actually choosing to not-learn.
I'll stop here so the review doesn't become longer than the reviewed. This piece is published as part of the Thistle Series of Essays for Milkweed Editions Press. Its length and cost make it accessible, and illustrate a publishing model worth emulating. Kohl says what he has to say and that's that. There is no "padding" to make it into a BOOK that would cost twice as much. I wish there were more such tracts.

Carol Sperry is at the Harvard Graduate School of Education. She may be contacted at:
41 Linnaean Street
Cambridge, MA 02138
carols@media.mit.edu