That is interesting.  I think it's perfectly reasonable to expect an OO
language to offer good support for concurrency.  It's a natural way to
model a problem...which is different than actually thinking in parallel.
The trouble is that it's easy to provide nice concurrency abstractions,
but it's a whole a different affair to make those abstractions work
without introducing all sorts of concurrency related bugs.

I've found that programmers that have worked for years with languages
that have little or no support for concurrency (like C for instance)
tend to solve problems sequentially (and even go to very extreme lengths
to keep the solution sequential!).  On the other hand, programmers that
may have started with environments like Smalltalk (where they can be
exposed to multi-processing earlier in their programming career), tend
to be more aware of multi-processing and how it can be used in modeling
a problem.  Part of the problem is that multi-processing has
traditionally been seen as something that the operating system (or web
server these days) does and not viewed as a programming language
construct.

- Stephen

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Mark Guzdial
> Sent: Thursday, October 25, 2001 10:03 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Lots of concurrency
> 
> 
> 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
> 
>