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 )
Ken Kahn wrote
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.
I think one major advantage of the SIMD StarLogo-World versus the "ticking" MIMD morphic world, is that the turtles in StarLogo live in serveral ticking patches where as the morphs live in only one ticking world.
Why not creating a patchboard in squeak, where morphs could live in?
It would be much easier to implement sniffing or other sensors for the morphs, if they knew the patch they live in and this patches knew their neighbours. I miss more sensors in the current morphic world; right now "color of morph sees color of other morph" seems to be the most valuable, thats what pixels are good for...
These patchmorphs certainly would have more "intelligence" as pixels (where the poor morphs right now have to live on), so they could distribute pheromone (or "light", "sound", "gravity" etc.) based on their contents.
By the way, with a small patchmatrix-extent at least many board-games could make some use of such a patchboard-framework, with more horsepower or parallel processors I could imagine easy programming of video-games in squeak.
Suggestions? Worth implementing it? Aren't patches a bit like synchonization-channels?
Best,
Markus
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 )
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 childrenbefore 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 -- calledTableau -- 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@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
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@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Mark Guzdial Sent: Thursday, October 25, 2001 10:03 PM To: squeak-dev@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 childrenbefore 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 -- calledTableau -- 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@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty%3E /Mark.Guzdial.html
On Thursday 25 October 2001 10:54 pm, you wrote:
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
I agree, languages that make multi-processing hard to use cause people not to use that feature... ;)
Which is why modern languages should have more support for such features. Easy support.
Not the silliness of writing threads in C, or even java, but a good way to handle all such cases.
Daniel
At 15:43 -0800 10/25/01, Alan Kay wrote:
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.)
...
I found Cocoa on the Apple Research web site one day and I had a lot of fun playing with it one weekend. Its limitations were obvious but I was surprised how much one could do with it. I wrote a maze crawler (using the 'hold one finger to the wall at all times' algorithm) among other things. The programming model was really different, though it didn't scale and was far too concrete.
It's too bad there isn't some way to go back and run old software like one can go back and read old journals or books. Cocoa needs to be experienced for a day to really get a feel for the strengths and weaknesses of the approach.
Dave
[A.Kay:]
(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.)
...
[D.Smith:]
I found Cocoa on the Apple Research web site one day and I had a lot of fun playing with it one weekend. Its limitations were obvious but I was surprised how much one could do with it. I wrote a maze crawler (using the 'hold one finger to the wall at all times' algorithm) among other things. The programming model was really different, though it didn't scale and was far too concrete.
It's too bad there isn't some way to go back and run old software like one can go back and read old journals or books. Cocoa needs to be experienced for a day to really get a feel for the strengths and weaknesses of the approach.
----
This seems like a good place for me to insert my own experiences with Cocoa/Stagecast. I have spent a significant amount of time over the past three years working with (mostly middle school, some elementary) kids in an after-school "game design" context where the main software used is Stagecast Creator, the Tableau-KidSim-Cocoa descendant Alan mentions. It uses graphical rewrite rules and programming by demonstration and uses a metaphor of *characters* on a *stage* who carry out behaviors according to *rules*. My experiences have been very positive and kids keep coming back and learning how to do more sophisticated things, e.g. using variables intelligently. Under its current implementation I don't think the program is as limited as Alan suggests (altho I may be mind-reading here), but there is a problem (one that Alan mentions himself in an earlier post about Playground) that you need to be "clever" to solve problems in it that are at all complex. These "clever" solutions can be very simple, but that doesn't mean that most novices would ever come up with them on their own. This in itself is not a problem, however, if one is "building a culture" where expertise is distributed and where various programming "tricks" come to be part of the lore.
I should also mention that with the if-then/production-system form in which all rules in Creator are written, kids do tend to become relatively fluent in the kind of "conditional evaluation" thinking that a number of contributors have suggested is (a) hard and (b) infrequently observed.
There is a very simple game that I teach kids to build in Stagecast that I was in fact wondering how to do in Squeak. I call it "Food Fight"; it involves two players, each of which is represented by a character that can move up and down along either the left or right edge of the stage (screen). Each character can "throw" a food item (say a hamburger for player A, a taco for player B) that travels across the screen and if it hits the opposing player, that player gets one "life" subtracted from its total. When a player loses all its lives it disappears. Each player has a limited number of food items and a limited number of lives, and the winner is either the last player left standing or the one with the most lives left when all the food ammo is gone (lives left and food left are displayed on screen at all times).
It is very natural for kids to think about all these things happening more or less in parallel in this game: player A moving, player B moving, player A shooting, player B shooting, food traveling, food hitting other player, score updating. And a large number of kids succeed in creating this game. (It also absorbs some of the natural tendency of kids -- esp boys -- to want to make "shooting" games and transforms it into a "food fight" instead of something more violent.)
Is a game like this easy to create in Squeak? It seems like it ought to be, but I seem to remember reading somewhere that "keyboard focus" is generally held by one morph at any given time. How then would one handle the problem of allowing each player to have different "move" and "shoot" keys where different morphs are "looking for" different keys all the time, at the same time?
If there were some way that an explanation/mini-lesson on a squeak version of this game could be provided by one of the kind folks in this discussion, and also perhaps serve as a more kid-friendly example of concurrency, that would certainly "feed two birds with one burger" for me!
Thanks for listening, and for a very stimulating set (sequence?) of messages.
- Jerry Balzano
------------------------- Dr. Gerald J. Balzano Teacher Education Program Dept of Music Laboratory for Comparative Human Cognition Cognitive Science Program UC San Diego La Jolla, CA 92093 (619) 822-0092 gjbalzano@ucsd.edu
On Friday 26 October 2001 03:40 pm, Jerry Balzano wrote:
Is a game like this easy to create in Squeak? It seems like it ought to be, but I seem to remember reading somewhere that "keyboard focus" is generally held by one morph at any given time. How then would one handle the problem of allowing each player to have different "move" and "shoot" keys where different morphs are "looking for" different keys all the time, at the same time?
There's two possibilities that I can think of offhand.
First, the event routing is to the Morph with keyboard focus, if any, otherwise to the World. Which could route the messages as needed.
But perhaps easier, you can just do:
World currentHand addKeyboardListener: someMorph
and someMorph would get sent handleListenEvent: with a copy of the event. So you could have each player morph listening to the keys and only responding to the ones it recognized.
If there were some way that an explanation/mini-lesson on a squeak version of this game could be provided by one of the kind folks in this discussion, and also perhaps serve as a more kid-friendly example of concurrency, that would certainly "feed two birds with one burger" for me!
Ok, try the attached change set (it's not a full demo, but it shows the keyboard hooking).
On Friday 26 October 2001 05:06 pm, I wrote:
Ok, try the attached change set (it's not a full demo, but it shows the keyboard hooking).
Here's a better version that distinguishes between key up and key down, and doesn't use keyboard repeat.
Thanks so much Ned; I've filed in the first change set and I'm poking around thoroughly to make sure I understand it all before going on to the second one. Lots of new stuff for me, just in the first one: IdentityDictionary, addKeyboardListener, handleListenEvent:, plus a number of subtleties... so far so good though...
- Jerry
At 6:09 PM -0700 10/26/01, Ned Konz wrote:
On Friday 26 October 2001 05:06 pm, I wrote:
Ok, try the attached change set (it's not a full demo, but it shows the keyboard hooking).
Here's a better version that distinguishes between key up and key down, and doesn't use keyboard repeat.
-- Ned Konz currently: Stanwood, WA email: ned@bike-nomad.com homepage: http://bike-nomad.com
Attachment converted: Jerry HD:KeyboardListenerDemo-nk.2.cs (TEXT/BOBO) (000302AE)
Jerry --
Some of the things I didn't like about StageCast were: * its abrupt change in metaphor from pattern matching to what is in effect a different language to handle more complex situations (somewhat in the same spirit of the initial magic of Prolog degenerating into having to understand the depths of how the inference engine works just as things get interesting). It's nicer when the learning curve is more gradual and without big cliffs to fall over. * the almost universal tendency of the children to reorder rules randomly because sometimes this helps (guessing and superstition are not really how you would like to see children debugging -- this is too much like most adult programmers!!!). * not enough routes for solving problems + the requirement to be "too clever too early" -- we would rather try to build a culture of understanding vs a culture of tricks. (This was also one of our criticisms about Playground as well.)
The food fight game sounds like fun. It's easy to do in Squeak. The limitation right now in Etoys is just that there is no real facility to deal with keyevents in the Etoy system itself -- but this is pretty easy to put in (and we should fix this). However, Mike Rueger did put support in for multiple physical joysticks, and -- even more weird in a sense -- is that you can have as many SW joysticks as you want in Etoys. This means that your game can easily be programmed right now to be played via Nebraska (with n kids and n computers both on the Internet and sharing a screen -- n = 4 would be fun -- you could use all four sides of the screen).
Cheers,
Alan
-------
At 3:40 PM -0700 10/26/01, Jerry Balzano wrote:
[A.Kay:]
(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.)
...
[D.Smith:]
I found Cocoa on the Apple Research web site one day and I had a lot of fun playing with it one weekend. Its limitations were obvious but I was surprised how much one could do with it. I wrote a maze crawler (using the 'hold one finger to the wall at all times' algorithm) among other things. The programming model was really different, though it didn't scale and was far too concrete.
It's too bad there isn't some way to go back and run old software like one can go back and read old journals or books. Cocoa needs to be experienced for a day to really get a feel for the strengths and weaknesses of the approach.
This seems like a good place for me to insert my own experiences with Cocoa/Stagecast. I have spent a significant amount of time over the past three years working with (mostly middle school, some elementary) kids in an after-school "game design" context where the main software used is Stagecast Creator, the Tableau-KidSim-Cocoa descendant Alan mentions. It uses graphical rewrite rules and programming by demonstration and uses a metaphor of *characters* on a *stage* who carry out behaviors according to *rules*. My experiences have been very positive and kids keep coming back and learning how to do more sophisticated things, e.g. using variables intelligently. Under its current implementation I don't think the program is as limited as Alan suggests (altho I may be mind-reading here), but there is a problem (one that Alan mentions himself in an earlier post about Playground) that you need to be "clever" to solve problems in it that are at all complex. These "clever" solutions can be very simple, but that doesn't mean that most novices would ever come up with them on their own. This in itself is not a problem, however, if one is "building a culture" where expertise is distributed and where various programming "tricks" come to be part of the lore.
I should also mention that with the if-then/production-system form in which all rules in Creator are written, kids do tend to become relatively fluent in the kind of "conditional evaluation" thinking that a number of contributors have suggested is (a) hard and (b) infrequently observed.
There is a very simple game that I teach kids to build in Stagecast that I was in fact wondering how to do in Squeak. I call it "Food Fight"; it involves two players, each of which is represented by a character that can move up and down along either the left or right edge of the stage (screen). Each character can "throw" a food item (say a hamburger for player A, a taco for player B) that travels across the screen and if it hits the opposing player, that player gets one "life" subtracted from its total. When a player loses all its lives it disappears. Each player has a limited number of food items and a limited number of lives, and the winner is either the last player left standing or the one with the most lives left when all the food ammo is gone (lives left and food left are displayed on screen at all times).
It is very natural for kids to think about all these things happening more or less in parallel in this game: player A moving, player B moving, player A shooting, player B shooting, food traveling, food hitting other player, score updating. And a large number of kids succeed in creating this game. (It also absorbs some of the natural tendency of kids -- esp boys -- to want to make "shooting" games and transforms it into a "food fight" instead of something more violent.)
Is a game like this easy to create in Squeak? It seems like it ought to be, but I seem to remember reading somewhere that "keyboard focus" is generally held by one morph at any given time. How then would one handle the problem of allowing each player to have different "move" and "shoot" keys where different morphs are "looking for" different keys all the time, at the same time?
If there were some way that an explanation/mini-lesson on a squeak version of this game could be provided by one of the kind folks in this discussion, and also perhaps serve as a more kid-friendly example of concurrency, that would certainly "feed two birds with one burger" for me!
Thanks for listening, and for a very stimulating set (sequence?) of messages.
- Jerry Balzano
Dr. Gerald J. Balzano Teacher Education Program Dept of Music Laboratory for Comparative Human Cognition Cognitive Science Program UC San Diego La Jolla, CA 92093 (619) 822-0092 gjbalzano@ucsd.edu
Alan Kay wrote:
However, Mike Rueger did put support in for multiple physicaljoysticks, and -- even more weird in a sense -- is that you can have
Uh, yes and no. The joystick support was never ported to the new event model :-( The old source can be found here: http://www.squeaklet.com/~michael/joystickevents.zip
I hope the support for joystick events is still in the VM and I know that Bert worked on multiple input devices for Linux.
So, whoever is willing to take a look at it...
Michael
Hi Dave Sorry to butt in but, since I have been following the discussion on concurrency, I'm not convinced that this problem, with Reasoning, has anything to do with the age group 7 - 10. I do, in principle, agree with Piagets studies though. It is more likely the Culture of Pragmatic and Empirical "scientific" indulgence that is flawed. The passage should read 7 - 70. Piaget was influenced by Kant but, only empirically. Piaget never properly studied Kants major work. Planning, parallel or concurrent thought is a product of advanced maturation: as the physical abilities of the body diminish the faculties of mind are forced into more efficient and effective behavior. Poverty is another cause. This can also be seen during hyperthermia. Every elder person realises this. This knowledge and it's power is only, as a rule, fully respected in indigenous communities. The culture of "bonsai"ing the mind with continual play and pleasure, the hot-housing of industrial responsibility and obedience; ensuring that the faculties of the brain never properly mature is a peculiarly western european control device. It's purpose: production Planning Inventory and Control Systems. I know, because I'm "industrial" Plantation, born n' bred. Toolmaking and PICS (and programming for PICS) are some of my earlier skills. Justin
At 15:43 -0800 10/25/01, Alan Kay wrote: 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"...,
----- Original Message ----- From: "David N. Smith (IBM)" dnsmith@watson.ibm.com To: squeak-dev@lists.squeakfoundation.org Cc: squeak-dev@lists.squeakfoundation.org; "Alan Kay" Alan.Kay@squeakland.org Sent: Saturday, October 27, 2001 6:25 AM Subject: Re: Lots of concurrency
At 15:43 -0800 10/25/01, Alan Kay wrote:
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.)
...
I found Cocoa on the Apple Research web site one day and I had a lot of
fun playing with it one weekend. Its limitations were obvious but I was surprised how much one could do with it. I wrote a maze crawler (using the 'hold one finger to the wall at all times' algorithm) among other things. The programming model was really different, though it didn't scale and was far too concrete.
It's too bad there isn't some way to go back and run old software like one
can go back and read old journals or books. Cocoa needs to be experienced for a day to really get a feel for the strengths and weaknesses of the approach.
Dave
David N. Smith IBM T J Watson Research Center Hawthorne, NY dnsmith@watson.ibm.com
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.
I don't know which Pea reference that is, but Jeffrey Bonar's work was on how students got natural and artificial languages confused -- making assumptions of natural language in artifical language. Brad Myers was working on this problem at CMU the last few years, but from the opposite angle: He asked people to describe how a video game should work, then he tried to create a language and interface that would work with the "natural" input.
Some of the "parallelism" in at least Bonar's and Myers' work is basically enumeration of a set. "Do this action to everything that looks like that." It's clearly parallelizable, but it's not clear that the speaker really meant that it had to be done in parallel.
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.
I'll bet that "java school" yields gobs, too, but I'll also bet that most of those students don't really know Java :-). In our studies (most recent this summer, in US, UK, and Poland, in four institutions) showed that CS1/2 students really don't know much Java/C++/Scheme/WhateverThey'reLearning even after the second year. We asked students to input equations (no parens, in either infix or postfix notation) from a file and print the result, on-line, in 90 minutes. Average score was about 25%.
But I will agree that the odds are much better for the StarLogo students than the Java students. I'm convinced that the answer to programming learning is engagement -- if there's something worth doing, students will learn all kinds of hard things in order to do it. StarLogo feels much more engaging to me than Java...but Squeak even more so :-)
Mark
-------------------------- 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@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Daniel Joyce -
David N. Smith (IBM) -
Jerry Balzano -
Justin Walsh -
Ken Kahn -
Mark Guzdial -
Markus Gaelli -
Michael Rueger -
Ned Konz -
Stephen Pair