> The issue of different learning styles (Planner, Bricoleur) and how
> modern computing technology can accommodate the different needs of the
> Bricoleur (visual, iconic, manipulative - moving the furniture around in
> the room of their mind) is a central issue of curriculum reform.
I think, Bill, that you think I'm somehow opposed to this insight.
I'm not! I completely agree that a crucial thing about computers in
schools is that they can help us accommodate different learning styles.
Where we disagree is that you want to define "abstract" as Planner
and "concrete" as Bricoleur. I think that defining those words in
that way leaves out a lot of understanding that is different from,
although 100% compatible with, the understanding that you're promoting.
Planner and Bricoleur are personal learning/thinking styles. Abstract
and Concrete are aspects of knowledge of the world.
It's true, perhaps, that a planner may be relatively more comfortable
with abstraction, and a bricoleur relatively less comfortable with it,
although I don't really believe even that weaker form of your
dichotomy. What I think is that *great* planners and *great* bricoleurs
are comfortable with abstraction, whereas *mediocre* planners and
*mediocre* bricoleurs aren't.
The importance of this for education is that *young* planners and
bricoleurs are in much the same situation as mediocre ones; even if
they have great potential, people start out most comfortable with
a concrete perspective. (This is sort of the same thing Piaget
says, with concrete operational coming before formal operational.)
Furthermore, I agree completely that *later* doesn't mean *better*;
the goal should be to be able to think in all those perspectives,
not to *replace* concrete with abstract.
As a concrete :-) but loose metaphor, some people are left-handed
and some are right-handed, but you can't tie your shoes or cut your
steak unless you can use both hands at least a little bit. (Well,
it's true that people with an arm missing can learn to get by with
just one -- but surely the goal of our educational philosophy
shouldn't be to cut off whichever is a student's weaker arm!)
> Should
> we design and teach courses so that the intended final endpoint or
> outcome is student mastery of abstract thinking for *all* students? Can
> some students be successful without abstraction in subject domains like
> maths and computer science?
There are two opposite but equally bad possible mistakes. You are
pointing out the mistake of excluding kids from math because they
have trouble (at least at their current age) with abstraction, and
I agree that that is a serious and very common mistake. The opposite
mistake, though, is to exclude kids from abstraction!
So, yes! I think we *should* aim at the goal that all students
eventually learn to think abstractly, just as I think that we should
aim at the goal that all students, even the narrowly focused
engineering students I see all the time at Berkeley who take Economics
as their required non-engineering breadth course because Econ is
basically applied math and god forbid they should have to read a poem
or write an essay, be able to handle literature and imagery.
It's okay to recognize that, in the end, not all students will turn out
equally proficient in all areas, and that you can have a perfectly good
life without that. But it's *not* okay to decide *at the start* that
some particular kid can't learn some particular way of thinking.
That's called "tracking" and it's just as bad if you call the tracks
"abstract" and "concrete" as if you call them "academic" and "general"!
Just imagine for a moment what would happen if it turned out that
white kids are better at abstraction and black kids better at concrete
understanding, and some teacher wanted to leave it that way.
> A related but less fundamental question is what are successful methods
> to teach abstraction anyway?
Here we are in complete agreement. You don't walk into a room of
five-year-olds and start talking about the commutative law.
> A friend uses Smalltalk to prototype (until recently) and I think the
> flexibility is what appeals to him. My original comments were, once
> again, lifted from the EP paper. I think it is a substantial point
> because there is an attempt in EP (and more recent writings by Papert)
> to make the word "object" a focus word from a number of learning domains
> (psychology, programming, learning theory). I see it as fairly central
> to our current discussion.
I hate this recent trend among AI people. In Mitch's book about StarLogo
he tries to claim Object Relations psychology for the decentralist school,
as opposed to centralist Ego psychology. This is a really gross
misunderstanding of both approaches to psychology. "Ego" does not mean
"conscious" or "planned"; Object Relations is an outgrowth, not a
rejection, of Ego psychology. And to equate the "object" of OOP with
the "object" of Object Relations is little more than a pun.
OOP as a technique is perfectly compatible with a whole range of
philosophies and personal styles. In essence OOP is an implementation
of the idea of modularity, the very idea that you associate a few
paragraphs down with the dreaded Planners! Managers of large teams
of programmers like OOP because it's a way to *enforce* modularity,
so that one person's work interacts with another person's work
only through a formally specified interface. But of course that
isn't what appeals to your Smalltalk friend.
> If we have a substantial group of people (mainly women) whose preferred
> thinking mode is bricolage and not planning then put bluntly there are
> two choices:-
> a) tell them they have to learn how to abstract and become more logical
> for their own good, eg. if they want to learn computer programming.
> b) find alternatives to abstraction and logic that work well
Here is the core of our disagreement. I want choice (c), which is
to dialectically respect *both* the learner's individual style
*and* the universal nature of full knowledge -- which includes both
abstract and concrete ways of understanding.
> In EP, Turkle and Papert, suggest that the growing popularity of icons
> in computer interfaces might be part of a larger shift towards an
> acceptance of concrete ways of thinking.
Icon-based interfaces are a mixed blessing. It's very true that they
have brought computer technology to a vastly expanded group of people,
and that's good, and important. At the same time, I keep running into
things that are easy to do on my Unix workstation that just can't be
done at all on my Mac. Simple things, like "delete all the files in
this folder whose name ends with .o" or "upload all the files I've
modified today." (Perhaps you can find specific Mac programs that
handle these specific tasks, but my point is that in a conventional
programming language it's easy to express these tasks without the
language designer having thought of them specifically.)
The correct direction for software development, I think, is Mike
Eisenberg's work on combining iconic and text styles. His program
SchemePaint is a painting program that you can control with a mouse,
just like any commercial painting program, but anything you can do
by clicking a button can also be done by writing a program, and indeed
you can write programs to enable new buttons that he didn't think of.
One of his examples that I like is a picture of a bee in a honeycomb;
the bee is drawn by hand with the mouse, and the honeycomb is the
result of a Logo-turtle-graphics-like program.
And indeed MicroWorlds is an example of just this sort of hybrid.
What makes MicroWorlds great is that you can push turtles around
with your mouse *and* you can write Logo programs to define new
kinds of behavior. MicroWorlds is a great example of both respecting
where the learner begins and also encouraging the learner to expand
his/her repertoire of ways of thinking!
> Computing technology is not
> the natural ally of the capitalist class at all. They limit and restrict
> its development continually because of their obsession to control it.
Oh, pfui. Computers are a technology. They can be used in different
ways. *Most* computers are used in the service of capitalism. For
example, did you know that every time you visit a Web site, some
computer somewhere is building up a dossier about your interests so
that they can send you just the right advertisements? And all that
great iconic technology you like was developed by the US Department of
Defense in order to help soldiers (who mostly aren't abstract thinkers!)
control weapons of mass destruction. That's where all the funding
came from, and it's where the ideas are most effectively used.
> In a more recent article (in the new international Maths Journal) Papert
> takes his "objects" analysis a step further. He elaborates the thingness
> principle, objects before operation. He then talks about "MicroChild
> (which I haven't seen) a version of MicroWorlds made by A.Sopranov in
> which Logo like instructions and even procedures are constructed by
> putting "blocks" together like making a Lego house.... with a little
> more development, ideas of function, composition of functions,
> definition of functions, transformations of functions can become
> perfectly natural to pre school children ... they would be accustomed to
> thinking of functions as thing-like: you put them somewhere, you move
> them from one place to another, you build with them, you give them
> names." (101)
Just like Seymour not to credit Radia Perlman, who developed these
ideas almost 30 years ago. She was interested in using Logo with
very young children, too young to read or use a computer keyboard.
So she first built a "button box" with iconic representations for
Forward, Back, Left, Right, and so on. You could plug extension
boxes into the main one. First came a number box, so instead of
pushing the Forward button three times you could push 3 and then
push Forward. Then came a programming box, with buttons "start
remembering", "stop remembering", "do it", and "forget". With these
you could define a procedure -- so we are respecting the learning
styles and abilities of three-year-olds while at the same time
inviting them in the direction of abstraction! Her next step was
to build the "slot machine," which was a series of different-colored
large strips of plastic with slots into which you could put iconic
cards. Mostly the cards represented the usual turtle commands, like
the earlier buttons, but there were cards whose "icons" were solid
colors, matching the colors of the strips. A red card meant, "run
the procedure in the red strip."
> Papert and Turkle are saying that the process of abstraction is harmful
> (alienating) for people like Lisa and Robin at the Harvard introductory
> programming course. They are saying there are alternatives for those
> with a bricolage style. They are not trying to force those who prefer
> abstraction and logic to change their style but saying lets design
> courses to include other learning styles not just the dominant one.
What's alienating is requiring everyone to use the same learning style
or to follow the same curriculum path. But no matter how you learn to
program, what you're learning is abstraction! To write a procedure is to
generalize from one specific picture (supposing it's a turtle procedure)
to the ability to reproduce a bunch of pictures according to a formal
description. Whether you develop that procedure by the methods of
top-down structured programming, or by the methods of tinkering, you
are doing abstraction in either case!
> If
> kids do spagetti code or "inefficient" code then more often than not
> I'll let it go.
Here again I think you are confusing Abstraction (a good thing) with
Bad Teaching (a bad thing). To insist that a beginner's programs must
follow a particular approved style is just stupid. Believe me, young
Planners don't like that kind of teaching either. You are seeing
programming teachers who don't really know how to program themselves,
but who read in a book about Structured Programming, and who reduce
that idea to a fetish that they can understand -- your program has
to have such-and-such a shape.
> I don't think that
> I'm ever trying to teach abstraction by using abstraction (by your
> definition). What I'm doing is either:-
> a) teaching rules, eg. MTM=P, because I'm not aware of concrete ways to
> get them across
> b) trying to construct rich down to earth, concrete, constructionist
> learning environments, eg. like Idit's fraction environment
> (and I have seen kids spontaneously come up with abstract ideas when
> immersed in these environments)
Again, this isn't the distinction between Abstract and Concrete; it's
the distinction between bad and good teaching. When some kid in Idit's
study writes a program that illustrates some particular use of fractions
by, let's say, showing a pie chart, the *teaching method* is of course
concrete, but the goal isn't that the kid should learn about that
fraction and no others! The goal is that the kid should *abstract from*
this and other examples, and come to understand fractions in general.
> Idit Harel in her Fractions study cites previous research that "found
> that children did not understand the meaning or purpose of a super
> procedure and rarely used superprocedures or subprocedures in their
> programs unless they were very explicitly instructed to do so." Harel
> found that "Debbie" did eventually use super and sub procedures without
> pressure due to the much larger amount of programming time in her study
> compared with previous studies. ie. when the procedures became too long
> Debbie decided on her own to modularise them.
In other words, Debbie came to an understanding of (an aspect of)
abstraction through a Bricolage learning style. That's great!
But this example supports my position, not yours. In order for it
to support your position, the story would have to be that Debbie
never did learn what a subprocedure means, and that she and Idit
are proud of that failure.
> If Idit Harel's learning environment is a good example of how to teach
> abstraction then my conclusion would be this. We teach abstraction by
> designing constructionist, concrete learning environments.
Yes, exactly. This is what I (and I think Tony, although I don't want
to speak for him) have been trying to say all along.
> Abstraction without detail is dogma.
Certainly. Equally true, and equally a red herring, is that
detail without abstraction is idiocy.
> :But what if the kid wants to invent a new, similar game? I claim that
> :now the kid *needs* *abstraction*! [...]
> The problem I have with this is that it seems to suggest that only
> abstract thinkers are creative and that concrete thinkers (bricoleurs)
> are not.
Perhaps I didn't express myself clearly here. I certainly don't
think that abstraction is the only route to creativity! On the
contrary. But I do think that abstraction is, except perhaps for
some hypothetical instinctive genius, the only route to getting
from the creative idea to a good, well tuned, playable game.
There are *rules* about what makes a game playable. I'm not an
expert, but for example one rule is that the game must start at
a very easy level and work up to a very hard level. This rule is
an abstraction from experience with specific games. (I'm thinking
about video games -- I'm not sure what the rules are for other
kinds.)
And of course I'm not saying that Bricoleurs can't make good games.
Indeed, bricoleurs are likely to be better game designers than planners.
But *most* people -- whether bricoleurs or planners -- don't design
great games. The great game designers -- whether bricoleurs or
planners -- are the ones who've abstracted some ideas about game
design from the particular games they've played.
---------------------------------------------------------------
Please post messages to the Logo forum to logo-l@gsn.org. Mail
questions about the list administration to logofdn@gsn.org. To
unsubscribe send unsubscribe logo-l to majordomo@gsn.org.