By Seymour Papert
In the last issue we were grappling with the theoretical problem of defining what kind of Logo is advanced Logo. Soon after writing my contribution I found myself in a meeting of Logo teachers who were grappling with a related but very practical problem. They felt that many of their students were not advancing in programming skills. For example even after several years of doing Logo, students still composed long and intricate strings of Logo instructions and resisted all suggestions of organizing their work as subprocedures. The teachers saw the situation as a “bug” in their own work and had tried, so far with limited success, a number of strategies to remedy it. Some of them, working on the assumption that the students did not understand the idea of subprocedure, had developed teaching units to explain some principles of structured programming. Others tried to influence the students by showing concretely how their code could be written differently. The teaching materials they developed were excellent and I am sure that these teachers would have exercised great skill in engaging students in discussion about the relative merits of different styles of programming. Why then did their strategies not succeed?
In the course of the discussion I came to appreciate more sharply than I had before the force of another factor that enters into this kind of situation. One might call it “the Piaget insight” which I formulated in the following way back in the days when I worked in Geneva. One of the major contributions Piaget made to the investigation of children’s thinking is understanding that it is not right to label as “wrong” children’s declarations that there are more red beads than blue beads or more water in the tall glass. If you truly succeed in putting yourself in their intellectual framework (no easy task!) you will understand that “the children are correctly answering the questions they are really answering… only their questions are not the same as yours even if both use the same words.” This does not mean that children, like the rest of us, aren’t sometimes just plain wrong. But the whole point of Piaget’s empathic and interactive way of conducting these conversations is to distinguish between errors or slips or “mere misunderstandings” and what the children really believe.
The Piaget insight applies to programming. For example, in the early days of our work at the Hennigan School a remarkable fifth grader, Nicky Brown (now an MIT undergraduate), put me right when I tried to advise him to break up a program into subprocedures. He systematically refuted all my arguments. No, it would not help him understand his program more clearly: he demonstrated by his ease of debugging and modifying his work that his own way of understanding it worked perfectly well. Well yes, subprocedures might help others take over parts of his work, but this wasn’t his main goal and besides he didn’t really think that they were interested anyway. Finally it was clear from his discussion that he just didn’t like the kind of structuring of his project that would be produced by the subprocedurization I suggested.
Remembering Nicky Brown – and many other talented young programmers – was a sharp reminder that there is something wrong with describing the problem raised by these teachers as if their students lacked “programming skill.” They may have lacked one particular programming skill, but what their style of programming required was another kind of skill – and when one looks at how fluently many students debug their “spaghetti code,” one is impressed by the level of that skill.
This diatribe against imposing structured programming on these children is not intended to avoid the issue that it would be immensely valuable for them to learn new programming ideas. Quite the contrary, it led me to a crisper formulation of an alternative strategy to achieve this not by trying to force new ways to write the children’s old programs but by introducing them to new programming domains in which other ideas would come up more naturally.
My new insight consisted of looking more closely at the development of the practice of Logo in the schools from which these teachers came – and when it was finally formulated I see that it applies on a much larger scale perhaps to the way that Logo programming in schools has developed across the board. One of the most positive educational benefits that came with the introduction of Logo into the schools I was looking at was a shift towards project-based learning. An excellent progressive step. But every progress risks bringing a certain kind of conservatism in its wake. In this case the conservatism took the form of establishing a certain model of “project” and this model of project carried with it a match to a certain style of programming, in fact precisely the style from which the teachers were now trying to wean their students.
The style of project in question developed a wide presence with the introduction of LogoWriter. Schematically described, it consists of using Logo to make a presentation of the results of research conducted by students. In the best cases Logo serves as more than just presenting ideas that are already formulated; the struggle to represent material is part of thinking about it. Some examples of this kind of work have become well known in the Logo community. Early examples included a project on the life cycle of the fly developed by Marian Rosen’s computer summer camp group, and projects by students in Joanne Ronkin’s class at Hennigan on such topics as the human skeleton. From Costa Rica came a bold students’ project on human reproduction and many on historical and ecological themes. There was no doubt in the minds of the teachers at the meeting I am reporting here that such projects were educationally valuable and a good use of Logo. What emerged only slowly during the meeting was an awareness that the projects favor a certain style: they are essentially narrative projects and favor a “narrative” style of programming that looks in the end more like a page full of text than like a structured piece of mathematics. Indeed I would go further and say that there has been a co-evolution of this kind of project and this style of programming.
The best way to diversify the style of Logo programming is to diversify the kinds of projects for which Logo is used. A clear example is provided by Lego-Logo. Programming a Lego turtle to follow a light requires programming based on repetitive runs of conditionals. But there is room for infinite diversity without hardware beyond the computer. Writing a video game in the style of Pacman or Mario requires efficient testing for new conditions and thinking carefully about a user interface that will permit rapid response. Simulations involving probability lead into issues of representation. All of these put so much of a real premium on small self-contained tool-like procedures that there is no need to persuade students to use them. They are what comes naturally in these contexts.
*The following is based on an interaction with a group of teachers who will surely recognize themselves in it. I decided not to identify them because the limited space available here forces me into an oversimplified presentation that casts me in the role of “the expert” coming with “answers” to problems that other people (“just teachers”) couldn’t solve. I hate this role. In reality the discussions were far richer and more creatively interactive. A fuller narrative would cast me as a catalyst rather than as an expert.
Reference:
Papert, S. (1994). Advancing Logo. Logo Update, 2(3), 1-3.