I want to document but I need to learn first!

[Alan Kay]

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://squeakland.org/mailman/private/squeakland/attachments/20030311/3972c7d2/attachment.htm