Lots of concurrency

Ken Kahn kenkahn at toontalk.com
Thu Oct 25 21:30:50 UTC 2001


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