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 --