Lots of concurrency

Mark Guzdial guzdial at cc.gatech.edu
Fri Oct 26 02:02:33 UTC 2001


I find the concurrent eToys compelling.  I also find Amy Bruckman's 
results compelling: Of the "zillions" of kids she's had program in 
MOOSE Crossing, almost none ever learned conditionals or loops.  But 
almost every one used a "fork"!  Pretty striking.

Mark

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

--------------------------
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
Associate Professor - Learning Sciences & Technologies.
Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/
(404) 894-5618 : Fax (404) 894-0673 : guzdial at cc.gatech.edu
http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html




More information about the Squeak-dev mailing list