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
|