Lots of concurrency

Alan Kay Alan.Kay at squeakland.org
Thu Oct 25 23:43:57 UTC 2001


It is certainly difficult to get definitive results from observing 
learners. There are so many artifacts to deal with.

In our observations of "zillions of children", particularly with 
several hundred children in the last year using Etoys, a workable 
generalization is that the second script that they make almost always 
runs concurrently with the first script that they made. They are also 
quite good at thinking out parallel conditionals, and not so good at 
(they hardly ever do) nested conditionals.

      Another generalization that works pretty well is that children 
before the age of 11 or 12 are not very good at large scale 
sequential planning, but are pretty good at cause-effect 
relationships on a small scale. We used to call these "bird's nest 
algorithms" when we were doing Playground in the late 80s. What I 
mean by this is that they were pretty darn good at looking at a 
situation, seeing a *one-step* that would improve it, and coming up 
with the conditional-action code to do that one step. Even 3rd 
graders were quite good at this. Then they could look at the next 
situation and do the same. Children of this age were not good at all 
in coming up with multiple sequential operations that would yield 
some effect. (No one knows whether this is teachable at ages 7-10. 
Piaget would say "probably not", but it reall
      Playground was an OOP language in which objects were very much 
like a collection of spreadsheetcells, and the "cell method" was 
basically a condition-action pair. Everything was concurrent.

        (This is where an experimental language we made -- called 
Tableau -- came from. It was later made into a language calledKidSim, 
then Cocoa, then StageCast. However, this way of doing things was 
pretty limited and we abandoned it early. I still don't think the 
StageCast route is really the way to do the before-after programming.)

The Playground experience (we thought it was too top down in its 
"one-wayness") got us very interested in bottom up messier ways to 
make things that could nonetheless concurrent. The Etoys stuff is not 
as pretty in its concepts, but it works extremely well (far better 
than anything we've done so far) with the several hundred children 
we've worked with. OTOH, Etoys was to be an Internet toy-builder, and 
was never meant to be an actual general authoring environment for 
kids. It needs quite a bit more (some of it qualitative) to give it 
enough "width and depth" of expression, if it is to be generally 
useful. However, it continues to supply really interesting examples 
of children's thinking about programming.

Cheers,

Alan


At 2:30 PM -0700 10/25/01, Ken Kahn wrote:
>Mark Guzdial  wrote:
>
>>  >And I think it is just an illusion
>>  >that this parallelism is only at a low level (e.g. neurons). Read
>Minsky's
>>  >Society Theory of Mind ( http://www.media.mit.edu/people/minsky/ ) for
>>  >example.
>>
>>  But also consider Herb Simon's arguments in opposition -- and Simon
>>  has a lot more empirical evidence in his favor.  I don't have an
>>  opinion on which is right yet, but I don't think that this is a
>>  settled point.
>>
>
>I'll agree it isn't settled. At the level of thoughts that I have
>self-awareness of, they seem pretty sequential but that is just the "tip of
>the iceberg".
>
>>
>>  I really love Mitchel's MultiLogo work, but part of what I love about
>>  it is his honesty in how *confusing* students found all the
>>  concurrency.
>>
>Yes. I too find sequential languages with a few concurrency constructs
>confusing. I want languages designed from the bottom up to be concurrent.
>
>>
>>  I don't find the "year of Logo programming" argument convincing.
>>  There are too many studies (most prominently the Pea and Kurland
>>  work, but even Idit Harel's and Yasmin Kafai's versions of ISDP) that
>>  shows that not much gets learned in a year of programming.  That deep
>>  mindsets about the universe get changed in a single year is a
>>  stretch.  (For example, Idit's and Yasmin's studies have taken more
>  > than a full year.)
>>
>
>Mitch writes "Several researchers (Pea et al. (1987), Bonar and Soloway
>(1985)) note that novice programmers (using traditional sequential
>languages) often assume parallelism where none exists." I have noticed this
>as well - especially in the context of object-oriented programming. Novices
>assume that each object is active and working independent of the others.
>
>Regarding whether a year is enough I think it rarely is. But as Mitch
>writes, "the students were part of a special computer-intensive environment,
>in which students worked at the computer for roughly an hour each day". And
>they probably were taught by MIT grad students. Most studies are of students
>taught by "ordinary" teachers in classes that meet less frequently.
>
>>  The other examples (sports teams, traffic, etc.) seem more an
>>  argument that students hold a centralized, sequential model of the
>>  universe -- consider Mitchel's work with StarLogo and how hesitant
>>  the students were to release the centralized models.
>>
>
>Yes, students hold centralized models (unfortunately). But I'm don't think
>they are sequential. They may all think that the bird in front is leading
>the flock but all the birds are flying at the same time. The centralized
>mindset interferes with seeing emergent phenomenon where there is no leader.
>
>>  It should be noted that Mitchel's StarLogo work is a dissertation
>>  about MENTAL MODELS OF CONTROL, *NOT* programming.  I asked Mitchel
>>  once about the interface that students used to StarLogo, and he told
>>  me that he was it.  None of his subjects actually wrote any of those
>>  programs!  Rather, they told Mitchel about their ideas, and he coded
>>  them -- explaining what he was doing -- and then worked with the kids
>>  to understand the results.  It's important to note that the kids
>>  didn't write the code.  They might have been able to, but that hasn't
>>  been tested  As far as I know, there have been no empirical studies
>>  of kids programming in StarLogo -- we don't know if it would work for
>>  the average kid.  So, we can't use StarLogo as an example of a
>>  concurrent programming language that works for kids.
>>
>
>We probably can assume that a fair number of high school students can
>program StarLogo. A Google search 'starlogo "high school"' yields almost 400
>hits; 'starlogo school' yields almost 1500. StarLogo once only ran on a
>million dollar Connection Machine so student access was probably limited.
>
>There are lots of wonderful StarLogo sample projects (and NetLogo too) but I
>don't like the SIMD flavor of the system. I would rather have the
>flexibility of having lots of autonomous communicating activities.
>
>Best,
>
>-ken kahn ( www.toontalk.com )


-- 




More information about the Squeak-dev mailing list