I want to document but I need to learn first!
Alan Kay
Alan.Kay at squeakland.org
Tue Mar 11 13:19:40 UTC 2003
Jerry --
I think you should first separate out the Squeak system -- an
experimental version of Smalltalk that is quite beyond the scope of
this list, which is for parents and teachers -- from the Squeak
"Etoys" which is aimed at children and *is* discussed on this list.
So complaining about 2000 posts to SqueakDev on this list is just
confusing for most of the folks here -- it's like complaining that
LISP is big and comprehensive -- it's not an enduser system, etc.
I will confine myself to the tradeoffs with the Squeak etoys. First,
we really do need better documentation, even for a system that is
still being tested by us. We have found that it takes about 3 years
in a classroom to get a good set of tests and we are just now in that
3rd year. The results of these 3 years have been written up by
teacher BJ Allen-Conn and Kim Rose in a "book of 10 projects" -- they
have done a great job! -- and drafts of this book will be available
online not too far in the future. Another terrific contribution is
from Sebastian Hergott's 8th grade class in Toronto. They did lots of
projects and he got them to write them up as documented examples.
These two books together supply lots of examples and should help to
bridge some of the gaps in documentation.
However, I should say a little about the history of etoys. They were
originally not aimed at classrooms but as 10-20 minute projects
supplied on the web for parents and their children to do together. I
stripped out as many features as I could and tried to come up with a
system that could do "100 examples" pretty straightforwardly. The
documentation that was intended here was to have been to teach
parents how to do the examples so they and their kids could have a
good experience. For several reasons, this plan did not work out at
Disney. But BJ saw it and wanted to try etoys in her 5th grade
classroom. I was initially against the idea because I thought that
etoys were not complete enough for that venue. But she and Kim Rose
decided to do it anyway. Six weeks later they started to show me some
really good results, and I realized that it would be worth doing a 3
year experiment to see how well the etoys -- even with some of their
lacks -- would work out with 10 and 11 year olds.
The results have been excellent -- in the proper environment most
children have no trouble getting joyously creative and fluent -- and
hence the forthcoming book by BJ and Kim to help other teachers and
parents achieve the same results.
Our previous plans to make a kind of "superhypercard" and then get
version 2 of etoys from that much more comprehensive design did not
work out at Disney, and it wasn't until recently that we've been able
to get that plan going again. I think this is more like the system
you want, and you'll have a chance to try it out this summer.
To zero in on a real critique of today's etoys, it is helpful to
confine discussion to 10 year olds and up, since essentially all the
experience that we and others have had are in this age range. The
etoys have changed very little in several years, in part because of
the testing that is going on, so comments such as "too fast moving"
really have to do with the larger Squeak community over at
www.squeak.org. Here I think the problems are not so much lack of
documentation as lack of particular kinds of documentation, such as
detailed tutorials and project workbooks. The user-tested books
mentioned above should help this.
Let me turn to another area, and tell a story that I witnessed
recently. I was visiting a classroom with a really terrific teacher,
who was truly ecstatic when his children could figure out something
before him (we need more of these kinds of teachers!). But he brought
up a problem that he couldn't see how to do. He wanted to general
random colors, and had seen that the red, green and blue blends are
given in the color picker. In etoys colors are not manifested as
three numbers (we possibly should, but don't) though they are in the
larger Squeak system (and in many other ways). So he didn't see how
to make up colors, especially random ones. My thought was to put a
bunch of objects (such as ellipses) into a holder, give them
different colors and then do random picking by moving the cursor
holder's cursor <- random
to get an object whose color can be gotten at.
We did that and he was happy. But then we saw a child who came
up with a much better way to do this. He just put splotches of paint
on the desktop and ran a Squeak player (like a car) over the
splotches in a random "drunkard's walk" and used "color under" to
pick up the color as a value.
My thought on seeing that was that it was the child who found
the "etoys way" of solving this problem, and that the general
solution in this fashion would involve using the color rainbow of a
color picker to supply a wide range of colors for the car to wander
about on.
My second thought was that both the teacher and I were somewhat
trapped in our pasts. The teacher had done something with color
numbers in the past and wanted to do it again. I went to a table
lookup solution that I had done many times in the past for other
kinds of problems, and this worked. The child went at the heart of
the matter with a completely simple and concrete approach that was
quite brilliant and original.
One of the reasons I'm telling this story is that today's etoys --
that lack a wide and comprehensive range of features that "they
should have" -- are best approached through the kinds of projects
that *can* be done really nicely using the features that are there.
There are more than enough such projects to occupy a full year
(really more like 3 years) of work and play by children. As for the
larger scope that is eventually needed, I'm hoping we can accomplish
this by the time today's projects are used up.
Now to another one of your comments in yesterday's email. You wrote:
At 6:44 PM -0800 3/10/03, Jerry Balzano wrote:
>Get a load of these (the total "partial" list was almost 40 lines long):
>
>Orbits
>Springs
>Weighing
>Gradient following - Salmon and Clownfish
>Tree Growing
>Epidemics
>Multiple Mentalities
>Grey Walter Conditioned Response Learning
>Circuit Models
>Anyone who could create projects like these in any programmable
>medium, I'd say, would have a serious leg up on "real" programming
>by anyone's hard-nosed definition of that elusive (and
>ever-changing) concept.
I think I agree here. I've done each of these strictly in etoys to
see what the process is like and to understand how one would explain
the process to both teachers and children. Most of these projects are
aimed at older children (such as Sebastian's 8th graders and older),
and I think are quite doable, but they haven't been tested yet with
adults and children of a good age and mindset. Just to provide a few
more comments on some of these:
*Orbits* is easily done in etoys if you understand Newton's inverse
square law, vectors (and that each etoy player -- like a logo turtle
-- is a vector and can do vector arithmetic). The script that does
the work is about 4 lines of tiles long and is a pretty direct
translation of the inverse square law using "increase by" of vectors.
It's a very clean script.
Here quite a bit has to be worked up to for most teachers and
other adults. There are hurdles of mathematics, science, and learning
more about how to use etoys. The scaffolding would require many
projects to be done earlier, including the accelleration and gravity
projects that were easily done by BJ's 5th graders. I think a good
next one is to do a spaceship floating in space without a gravity
field to get a sense of how velocity is often (usually) in a
different direction than the ship is pointing.
*Springs* are fun to do, and easy to script in etoys if you go
through the exercise of deciding that the force on a spring is
proportional to the displacement and in the opposite direction. I
think there is quite a bit of scaffolding needed to do the science
part.
*Weighing* is part of doing a real roller coaster in etoys. An
insight is required here. Most people get stumped about needing sine
and cosine, etc., to find the forces on an inclined plane. But in
fact, you can "weigh" them using a postal scale on an inclined scale.
You can make up a simple table -- using a holder -- of the forces
every few degrees and this is quite good enough to make a real roller
coaster in etoys.
*Gradient following* If you make a gradient using the graphic
properties sheet you can do tests on it using "Brightness under".
This allows a simple feedback program to be written (very much like
the follow the road ones) that will cause a simulated object to
follow and find the darker or lighter regions of the gradient.
(Gradient following is a feature in starLogo, but I think people
should learn about it by actually scripting it.)
*Tree Growing* Most people have cognitive difficulties with
recursion, but one nice way to look at trees is recursively. This is
a conflict. Because etoys can make new objects via copies (see below)
it is possible to bypass recursion altogether in favor of a branching
activation. This turned out to be a very clear script and a good
model for other kinds of "recursion changed to branching activation"
problems.
*Epidemics* have a wide range. The easiest ones are just having
infected objects bump into noninfected ones and transmit the
infection. This is just a few lines of script to do.
*Multiple mentalities* comes from the Vivarium work we did 15 years
ago. Here we have separate scripts or even objects that represent
parallel and mostly independent drives of the simulated animal. The
main thinking that is needed is to figure out which of the drives
should be allowed to control the animal. This is easy for two (a
simple comparison) and needs something like a sort for more (it is
actually just looking for the one with the largest "urgency", so it's
a matter of using the "max" operator to perculate the largest urgency
one in a holder.
*Grey Walter* conditioned reflex learning model. Here it is hard to
guess about the appropriate age for this wonderful etoy. My guess is
high school since Grey Walter's model is nicely subtle. (He did this
with a single vacuum tube in 1949, so parsimony was the order of the
day. He got all of his power from very careful reasoning and clear
thinking about a simple model to do this.) Once you understand how he
did it (I made a diagram to show the 7 steps you have to go through)
it was quite easy to do in etoys and generated a nice set of dynamic
graphs for the animal's "state of mind".
*Circuit Models* I've not quite figured out an appropriate approach
here. One way is to use the connectors stuff of Ned Konz and
propagate signals though his objects. Several folks have done this,
most notably a high school student who is working with us -- he went
to the heart of the matter and decided not to do batteries and bulbs
per se but to see about simulating logic.
> My students (same ones as above) wrote programs in NetLogo,
>Microworlds (a descendant of Logo),
This is a product
>and Stagecast Creator
so is this. Etoys is an experimental system that is still quite a
ways from being a finished packaged product.
>, including a "Turtle Epidemic" model in NetLogo for which I wrote
>the tutorial (see
>http://ccl.northwestern.edu/netlogo/resources.shtml) and a "Food
>Fight" game in Stagecast Creator, for which I'd love to be able to
>write the "etoys tutorial", if I could only see how to do several
>simple things in Etoys, for example
> * have an agent (smiley) create another agent (burger) in the
>space next to him
Let's suppose that smiley is in a playfield called "fastfood".
smiley create
smiley's temp <- burger copy
fastfood include smiley's temp
smiley's temp's x <- smiley's x + 25
smiley's temp's y <- smiley's y
I found "copy" and "include" just by going through the views of the
two objects and seeing what the balloon help told me. This is the
documentation that is there, but most people don't use it. I found
that I could make a player valued variable by looking at the menu
item "change data type", etc.
> * have an agent (smiley) send a message to a counter agent (count
>down) each time he "uses up" a burger, and another message to a
>counter-scorer agent (count up) each time one of his burgers hits
>his opponent
burger scoring
Test burger's color sees <color of boundary>
Yes smiley's score decrease by 1
Test burger's color sees <color of opponent>
Yes smiley's score increase by 1
>...just to name two.
>
>So, speaking of "viable learning paths", does anyone have a
>suggestion for one for *me*? Who wants to respond to all the
>questions my teacher-students raised in my field notes?
I do.
> Who wants to help me complete all the projects on Alan's list?
I have done these projects. I need help in explaining them in a way
useful to parents and teachers.
>
>If *I* can't figure out how to do this stuff on my own, there's no
>way any of the teachers I teach -- even after they've been
>thoroughly Balzano-indoctrinated to the virtues of programming and
>completed my
>more-rigorous-than-99%-of-other-teacher-ed-computer-courses course
>-- will be able to figure it out either.
I don't necessarily agree here, but your point is well taken. I think
that quite a bit of success for different kinds of people is the
match up between types of thinking, types of motivation, and the
kinds of materials and scaffolding available. Some teachers have been
amazingly successful with our inadequate documentation and others
have been less successful that one would expect, given the amount of
documentaiton that is there. Many children who like to explore and
don't want to read documentation have done even better. Some children
are quite stumped without explicit help (but that's what teachers are
supposed to be for.)
But the clear lesson is that we need to provide enough coverage for a
wide range of styles of learning. Please continue to be interested
and to help.
Cheers,
Alan
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030311/3972c7d2/attachment.htm
More information about the Squeak-dev
mailing list
|