Learnable Programming

> On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg <[hidden email]>
> wrote:
>>
>> Great essay by Bret Victor on "Designing a programming system for
>> understanding programs":
>>
>>         http://worrydream.com/LearnableProgramming/
>>
>> He clearly explains what makes a programming system "learnable". While
>> Etoys does not do all of it, many of its features fit right in, in
>> particular as compared to other widely used programming systems. An Etoys
>> project can be always running, changes have effect immediately, all state is
>> visible (through the readouts in viewers) and most of the state can be
>> changed directly (e.g. by dragging up and down the number arrows), tiles
>> have default arguments so they do something useful immediately, there is an
>> explanation (balloon help) for each tile
>
>
> Yes but it is only textual help.  It would be great if they could be a
> combination of Ricardo's Speech Bubbles and Ted Kaehler's roll your own
> quick guide feature.  With one or two changes, the roll your own quick
> guides should be in a folder in the Etoys directory so it is easier for
> students and teachers to find and save these guides.  The current location
> is hard to find, I believe varies by platform and can be locked down by
> school administrators.  Also when saving a "My Quick Guides"  area would be
> nice.  Perhaps even encourage folks to modify them by having the New
> Help/Speech Bubbles have a "Modify Me" icon, which would open a new project
> with the existing Help/Speech Bubble opened.  We should also have a
> mechanism to revert to the original so kids can easily experiment without
> fear of messing things up too badly.
>
>
>> , etc. And maybe this essay inspires some improvements to Etoys :)
>
>
> I currently have the two key take aways so far as it relates to improvements
> to make in Etoys:
>
> "Create by Abstracting"
> "Recomposition"
>
> "Create by Abstracting": I believe the tools are already there, but what is
> needed is the "Great Literature" and Lessons teachers and learners can use.
> Not sure how this would impact the interface or if it should, but I think
> its a really important lesson.  One possible way this could impact interface
> design is to provide a "turn #/expression into a variable" function.  Where
> there is a way to click/touch on a variable and have a easily
> discoverable/accesible method to turn it into a variable.  Actually it
> should work for "players/objects/morphs/colors" as well.
> Also kudo's to Etoys and its copy/sibling approach which IMO is a better
> design for "Start with one, make many" than the one for text based languages
> demonstrated by Brett.
>
> "Recomposition": object re-use (across projects) is not very simple in
> Etoys.  I like Scratch 2.0's use of a Backpack, which yes could be
> implemented as "add your own" section in the Object Catalog, but I think
> they made a good design choice in making it an "always there and visible"
> flap.
>
> Regarding "Decomposition" Brett states
>>
>> "Consider a programmer who has made a bouncing ball animation. How does
>> she go from one ball to two, to a hundred? How does she make the balls
>> bounce off one another? How does she make balls draggable with the mouse? In
>> a genuine learning environment such as Etoys, this progression is natural
>> and encouraged."
>
>
> My suggestions here is that it would be good if Etoys "scaled better" when
> executing scripts on multiple objects. Unless you are using Kedama (which
> rocks in this aspect) Etoys slows down when you have say 20+ objects
> executing.
>
> Okay, so that brings me to another area for improvement Kedama.  Kedama is
> amazing and definitely rocks at massively parallel simulations, But it
> either needs a better (read easier to understand/grok) set of scripting
> tiles or I need a better model in my head of how it works.  Probably more of
> the latter than the former.

>
> Of course all of the above would be great if we had more development
> resources :)
>
> Cheers,
> Stephen
>
> _______________________________________________
> squeakland mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/squeakland
>

> On Mon, Nov 5, 2012 at 6:45 AM, Steve Thomas <[hidden email]> wrote:
>> On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg <[hidden email]>
>> wrote:
>>>
>>> Great essay by Bret Victor on "Designing a programming system for
>>> understanding programs":
>>>
>>>         http://worrydream.com/LearnableProgramming/
>>>
>>> He clearly explains what makes a programming system "learnable". While
>>> Etoys does not do all of it, many of its features fit right in, in
>>> particular as compared to other widely used programming systems. An Etoys
>>> project can be always running, changes have effect immediately, all state is
>>> visible (through the readouts in viewers) and most of the state can be
>>> changed directly (e.g. by dragging up and down the number arrows), tiles
>>> have default arguments so they do something useful immediately, there is an
>>> explanation (balloon help) for each tile
>>
>>
>> Yes but it is only textual help.  It would be great if they could be a
>> combination of Ricardo's Speech Bubbles and Ted Kaehler's roll your own
>> quick guide feature.  With one or two changes, the roll your own quick
>> guides should be in a folder in the Etoys directory so it is easier for
>> students and teachers to find and save these guides.  The current location
>> is hard to find, I believe varies by platform and can be locked down by
>> school administrators.  Also when saving a "My Quick Guides"  area would be
>> nice.  Perhaps even encourage folks to modify them by having the New
>> Help/Speech Bubbles have a "Modify Me" icon, which would open a new project
>> with the existing Help/Speech Bubble opened.  We should also have a
>> mechanism to revert to the original so kids can easily experiment without
>> fear of messing things up too badly.
>>
>>
>>> , etc. And maybe this essay inspires some improvements to Etoys :)
>>
>>
>> I currently have the two key take aways so far as it relates to improvements
>> to make in Etoys:
>>
>> "Create by Abstracting"
>> "Recomposition"
>>
>> "Create by Abstracting": I believe the tools are already there, but what is
>> needed is the "Great Literature" and Lessons teachers and learners can use.
>> Not sure how this would impact the interface or if it should, but I think
>> its a really important lesson.  One possible way this could impact interface
>> design is to provide a "turn #/expression into a variable" function.  Where
>> there is a way to click/touch on a variable and have a easily
>> discoverable/accesible method to turn it into a variable.  Actually it
>> should work for "players/objects/morphs/colors" as well.
>> Also kudo's to Etoys and its copy/sibling approach which IMO is a better
>> design for "Start with one, make many" than the one for text based languages
>> demonstrated by Brett.
>>
>> "Recomposition": object re-use (across projects) is not very simple in
>> Etoys.  I like Scratch 2.0's use of a Backpack, which yes could be
>> implemented as "add your own" section in the Object Catalog, but I think
>> they made a good design choice in making it an "always there and visible"
>> flap.
>>
>> Regarding "Decomposition" Brett states
>>>
>>> "Consider a programmer who has made a bouncing ball animation. How does
>>> she go from one ball to two, to a hundred? How does she make the balls
>>> bounce off one another? How does she make balls draggable with the mouse? In
>>> a genuine learning environment such as Etoys, this progression is natural
>>> and encouraged."
>>
>>
>> My suggestions here is that it would be good if Etoys "scaled better" when
>> executing scripts on multiple objects. Unless you are using Kedama (which
>> rocks in this aspect) Etoys slows down when you have say 20+ objects
>> executing.
>>
>> Okay, so that brings me to another area for improvement Kedama.  Kedama is
>> amazing and definitely rocks at massively parallel simulations, But it
>> either needs a better (read easier to understand/grok) set of scripting
>> tiles or I need a better model in my head of how it works.  Probably more of
>> the latter than the former.
>
> I found this searching a while ago
> http://www.is.titech.ac.jp/~sassa/lab/papers-written/ohshima-phdthesis-070109.pdf
> I have not read it yet.

>
> Karl
>>
>> Of course all of the above would be great if we had more development
>> resources :)
>>
>> Cheers,
>> Stephen
>>
>> _______________________________________________
>> squeakland mailing list
>> [hidden email]
>> http://lists.squeakland.org/mailman/listinfo/squeakland
>>

> On Mon, Nov 5, 2012 at 6:30 PM, karl ramberg <[hidden email]>
> wrote:
>> On Mon, Nov 5, 2012 at 6:45 AM, Steve Thomas <[hidden email]>
>> wrote:
>>> On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg
>>> <[hidden email]>
>>> wrote:
>>>>
>>>> Great essay by Bret Victor on "Designing a programming system for
>>>> understanding programs":
>>>>
>>>>         http://worrydream.com/LearnableProgramming/
>>>>
>>>> He clearly explains what makes a programming system "learnable". While
>>>> Etoys does not do all of it, many of its features fit right in, in
>>>> particular as compared to other widely used programming systems. An
>>>> Etoys
>>>> project can be always running, changes have effect immediately, all
>>>> state is
>>>> visible (through the readouts in viewers) and most of the state can be
>>>> changed directly (e.g. by dragging up and down the number arrows),
>>>> tiles
>>>> have default arguments so they do something useful immediately, there
>>>> is an
>>>> explanation (balloon help) for each tile
>>>
>>>
>>> Yes but it is only textual help.  It would be great if they could be a
>>> combination of Ricardo's Speech Bubbles and Ted Kaehler's roll your own
>>> quick guide feature.  With one or two changes, the roll your own quick
>>> guides should be in a folder in the Etoys directory so it is easier for
>>> students and teachers to find and save these guides.  The current
>>> location
>>> is hard to find, I believe varies by platform and can be locked down by
>>> school administrators.  Also when saving a "My Quick Guides"  area
>>> would be
>>> nice.  Perhaps even encourage folks to modify them by having the New
>>> Help/Speech Bubbles have a "Modify Me" icon, which would open a new
>>> project
>>> with the existing Help/Speech Bubble opened.  We should also have a
>>> mechanism to revert to the original so kids can easily experiment
>>> without
>>> fear of messing things up too badly.
>>>
>>>
>>>> , etc. And maybe this essay inspires some improvements to Etoys :)
>>>
>>>
>>> I currently have the two key take aways so far as it relates to
>>> improvements
>>> to make in Etoys:
>>>
>>> "Create by Abstracting"
>>> "Recomposition"
>>>
>>> "Create by Abstracting": I believe the tools are already there, but
>>> what is
>>> needed is the "Great Literature" and Lessons teachers and learners can
>>> use.
>>> Not sure how this would impact the interface or if it should, but I
>>> think
>>> its a really important lesson.  One possible way this could impact
>>> interface
>>> design is to provide a "turn #/expression into a variable" function.
>>> Where
>>> there is a way to click/touch on a variable and have a easily
>>> discoverable/accesible method to turn it into a variable.  Actually it
>>> should work for "players/objects/morphs/colors" as well.
>>> Also kudo's to Etoys and its copy/sibling approach which IMO is a
>>> better
>>> design for "Start with one, make many" than the one for text based
>>> languages
>>> demonstrated by Brett.
>>>
>>> "Recomposition": object re-use (across projects) is not very simple in
>>> Etoys.  I like Scratch 2.0's use of a Backpack, which yes could be
>>> implemented as "add your own" section in the Object Catalog, but I
>>> think
>>> they made a good design choice in making it an "always there and
>>> visible"
>>> flap.
>>>
>>> Regarding "Decomposition" Brett states
>>>>
>>>> "Consider a programmer who has made a bouncing ball animation. How
>>>> does
>>>> she go from one ball to two, to a hundred? How does she make the balls
>>>> bounce off one another? How does she make balls draggable with the
>>>> mouse? In
>>>> a genuine learning environment such as Etoys, this progression is
>>>> natural
>>>> and encouraged."
>>>
>>>
>>> My suggestions here is that it would be good if Etoys "scaled better"
>>> when
>>> executing scripts on multiple objects. Unless you are using Kedama
>>> (which
>>> rocks in this aspect) Etoys slows down when you have say 20+ objects
>>> executing.
>>>
>>> Okay, so that brings me to another area for improvement Kedama.  Kedama
>>> is
>>> amazing and definitely rocks at massively parallel simulations, But it
>>> either needs a better (read easier to understand/grok) set of scripting
>>> tiles or I need a better model in my head of how it works.  Probably
>>> more of
>>> the latter than the former.
>>
>> I found this searching a while ago
>> http://www.is.titech.ac.jp/~sassa/lab/papers-written/ohshima-phdthesis-070109.pdf
>> I have not read it yet.
>
>
> I skimmed through this and it seems the Etoy user aspects of Kedama is
> described in chapter 3 and 4.
> I must say Kedama got a lot more understandable reading these chapters :-)
> Maybe we could extract the and post them on Squeakland ?
>
> Also some chapters have info for the Etoys reference manual eg the
> Etoys language extensions and the features.
>
> Yoshiki:
> Is it ok to use/copy from the thesis to the Etoys reference manual and
> eventually to a brief Kedama user guide ?
>
> Karl
>
>
>
>
>>
>> Karl
>>>
>>> Of course all of the above would be great if we had more development
>>> resources :)
>>>
>>> Cheers,
>>> Stephen
>>>
>>> _______________________________________________
>>> squeakland mailing list
>>> [hidden email]
>>> http://lists.squeakland.org/mailman/listinfo/squeakland
>>>
> _______________________________________________
> squeakland mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/squeakland
>

> I skimmed through this and it seems the Etoy user aspects of Kedama is
> described in chapter 3 and 4.
> I must say Kedama got a lot more understandable reading these chapters :-)
> Maybe we could extract the and post them on Squeakland ?
>
> Also some chapters have info for the Etoys reference manual eg the
> Etoys language extensions and the features.
>
> Yoshiki:
> Is it ok to use/copy from the thesis to the Etoys reference manual and
> eventually to a brief Kedama user guide ?

> On Tue, Nov 6, 2012 at 12:58 PM, karl ramberg <[hidden email]> wrote:
>> I skimmed through this and it seems the Etoy user aspects of Kedama is
>> described in chapter 3 and 4.
>> I must say Kedama got a lot more understandable reading these chapters :-)
>> Maybe we could extract the and post them on Squeakland ?
>>
>> Also some chapters have info for the Etoys reference manual eg the
>> Etoys language extensions and the features.
>>
>> Yoshiki:
>> Is it ok to use/copy from the thesis to the Etoys reference manual and
>> eventually to a brief Kedama user guide ?
>
> I don't mind that.  Thank you!
>
> --
> -- Yoshiki

> Bookmarked to use in the Etoys Reference Manual. Thanks.
>
> I took off a few days for the election, but will be back on the manual as
> soon as I clear out this e-mail backlog. It is going quite well, although
> there are a few niggles, and I have reported a number of bugs in Etoys,
> some of them serious.
>
> I am starting to plan out a companion Etoys by Example, which will include
> dissections and annotations of the projects provided with Etoys v5, and a
> variety of extensions. I was particularly pleased to see the fractions
> project, which has endless potential for further development.
>
> I have had a notion of using Etoys to write OERs (Open Educational
> Resources) to replace textbooks (see link in sig). I can see the outlines
> of an architecture for this, but I need help to understand and explain how
> to construct interactive books such as some of the projects use.

>
> On Tue, November 6, 2012 3:58 pm, karl ramberg wrote:
>> On Mon, Nov 5, 2012 at 6:30 PM, karl ramberg <[hidden email]>
>> wrote:
>>> On Mon, Nov 5, 2012 at 6:45 AM, Steve Thomas <[hidden email]>
>>> wrote:
>>>> On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg
>>>> <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Great essay by Bret Victor on "Designing a programming system for
>>>>> understanding programs":
>>>>>
>>>>>         http://worrydream.com/LearnableProgramming/
>>>>>
>>>>> He clearly explains what makes a programming system "learnable". While
>>>>> Etoys does not do all of it, many of its features fit right in, in
>>>>> particular as compared to other widely used programming systems. An
>>>>> Etoys
>>>>> project can be always running, changes have effect immediately, all
>>>>> state is
>>>>> visible (through the readouts in viewers) and most of the state can be
>>>>> changed directly (e.g. by dragging up and down the number arrows),
>>>>> tiles
>>>>> have default arguments so they do something useful immediately, there
>>>>> is an
>>>>> explanation (balloon help) for each tile
>>>>
>>>>
>>>> Yes but it is only textual help.  It would be great if they could be a
>>>> combination of Ricardo's Speech Bubbles and Ted Kaehler's roll your own
>>>> quick guide feature.  With one or two changes, the roll your own quick
>>>> guides should be in a folder in the Etoys directory so it is easier for
>>>> students and teachers to find and save these guides.  The current
>>>> location
>>>> is hard to find, I believe varies by platform and can be locked down by
>>>> school administrators.  Also when saving a "My Quick Guides"  area
>>>> would be
>>>> nice.  Perhaps even encourage folks to modify them by having the New
>>>> Help/Speech Bubbles have a "Modify Me" icon, which would open a new
>>>> project
>>>> with the existing Help/Speech Bubble opened.  We should also have a
>>>> mechanism to revert to the original so kids can easily experiment
>>>> without
>>>> fear of messing things up too badly.
>>>>
>>>>
>>>>> , etc. And maybe this essay inspires some improvements to Etoys :)
>>>>
>>>>
>>>> I currently have the two key take aways so far as it relates to
>>>> improvements
>>>> to make in Etoys:
>>>>
>>>> "Create by Abstracting"
>>>> "Recomposition"
>>>>
>>>> "Create by Abstracting": I believe the tools are already there, but
>>>> what is
>>>> needed is the "Great Literature" and Lessons teachers and learners can
>>>> use.
>>>> Not sure how this would impact the interface or if it should, but I
>>>> think
>>>> its a really important lesson.  One possible way this could impact
>>>> interface
>>>> design is to provide a "turn #/expression into a variable" function.
>>>> Where
>>>> there is a way to click/touch on a variable and have a easily
>>>> discoverable/accesible method to turn it into a variable.  Actually it
>>>> should work for "players/objects/morphs/colors" as well.
>>>> Also kudo's to Etoys and its copy/sibling approach which IMO is a
>>>> better
>>>> design for "Start with one, make many" than the one for text based
>>>> languages
>>>> demonstrated by Brett.
>>>>
>>>> "Recomposition": object re-use (across projects) is not very simple in
>>>> Etoys.  I like Scratch 2.0's use of a Backpack, which yes could be
>>>> implemented as "add your own" section in the Object Catalog, but I
>>>> think
>>>> they made a good design choice in making it an "always there and
>>>> visible"
>>>> flap.
>>>>
>>>> Regarding "Decomposition" Brett states
>>>>>
>>>>> "Consider a programmer who has made a bouncing ball animation. How
>>>>> does
>>>>> she go from one ball to two, to a hundred? How does she make the balls
>>>>> bounce off one another? How does she make balls draggable with the
>>>>> mouse? In
>>>>> a genuine learning environment such as Etoys, this progression is
>>>>> natural
>>>>> and encouraged."
>>>>
>>>>
>>>> My suggestions here is that it would be good if Etoys "scaled better"
>>>> when
>>>> executing scripts on multiple objects. Unless you are using Kedama
>>>> (which
>>>> rocks in this aspect) Etoys slows down when you have say 20+ objects
>>>> executing.
>>>>
>>>> Okay, so that brings me to another area for improvement Kedama.  Kedama
>>>> is
>>>> amazing and definitely rocks at massively parallel simulations, But it
>>>> either needs a better (read easier to understand/grok) set of scripting
>>>> tiles or I need a better model in my head of how it works.  Probably
>>>> more of
>>>> the latter than the former.
>>>
>>> I found this searching a while ago
>>> http://www.is.titech.ac.jp/~sassa/lab/papers-written/ohshima-phdthesis-070109.pdf
>>> I have not read it yet.
>>
>>
>> I skimmed through this and it seems the Etoy user aspects of Kedama is
>> described in chapter 3 and 4.
>> I must say Kedama got a lot more understandable reading these chapters :-)
>> Maybe we could extract the and post them on Squeakland ?
>>
>> Also some chapters have info for the Etoys reference manual eg the
>> Etoys language extensions and the features.
>>
>> Yoshiki:
>> Is it ok to use/copy from the thesis to the Etoys reference manual and
>> eventually to a brief Kedama user guide ?
>>
>> Karl
>>
>>
>>
>>
>>>
>>> Karl
>>>>
>>>> Of course all of the above would be great if we had more development
>>>> resources :)
>>>>
>>>> Cheers,
>>>> Stephen
>>>>
>>>> _______________________________________________
>>>> squeakland mailing list
>>>> [hidden email]
>>>> http://lists.squeakland.org/mailman/listinfo/squeakland
>>>>
>> _______________________________________________
>> squeakland mailing list
>> [hidden email]
>> http://lists.squeakland.org/mailman/listinfo/squeakland
>>
>
>
> --
> Edward Mokurai
> (&#40664;&#38647;/&#2344;&#2367;&#2358;&#2348;&#2381;&#2342;&#2327;&#2352;&#2381;&#2332;/&#1606;&#1588;&#1576;&#1583;&#1711;&#1585;&#1580;)
> Cherlin
> Silent Thunder is my name, and Children are my nation.
> The Cosmos is my dwelling place, the Truth my destination.
> http://wiki.sugarlabs.org/go/Replacing_Textbooks
>
>
> _______________________________________________
> squeakland mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/squeakland

> On Wed, Nov 7, 2012 at 8:00 PM,  <[hidden email]> wrote:
>> Bookmarked to use in the Etoys Reference Manual. Thanks.
>>
>> I took off a few days for the election, but will be back on the manual
>> as
>> soon as I clear out this e-mail backlog. It is going quite well,
>> although
>> there are a few niggles, and I have reported a number of bugs in Etoys,
>> some of them serious.
>>
>> I am starting to plan out a companion Etoys by Example, which will
>> include
>> dissections and annotations of the projects provided with Etoys v5, and
>> a
>> variety of extensions. I was particularly pleased to see the fractions
>> project, which has endless potential for further development.
>>
>> I have had a notion of using Etoys to write OERs (Open Educational
>> Resources) to replace textbooks (see link in sig). I can see the
>> outlines
>> of an architecture for this, but I need help to understand and explain
>> how
>> to construct interactive books such as some of the projects use.
>
> Ask away, There are many people here that can help you here.
>
>>
>> I have mentioned the need for an extensive proofreading and refactoring
>> of
>> Etoys, plus writing of many more comments on classes and methods. Who is
>> working on such things?
>
> I do this as far as I have ability to.
>
> Refactorings is a long process, as one have to grasp the much of
> system and reformulate it in
> a more concise way. Often the complexity is mindnumbing ;-)
>
> Proofreading should be quite easy,
>  You can post issues on http://tracker.squeakland.org/
> Presented in this form it is quite fast for developers to fix:
> http://tracker.squeakland.org/browse/SQ-1036
>
> An other possibility is that you do the fixes yourself and upload
> them. It's a few tools that needs to be
> mastered to be able to do that but I assure you that it is quite fun :-)
>
> A very very brief document is posted here on how to develop for Etoys:
> http://etoys.squeak.org/svn/trunk/Documentation/Developer-HowTo.txt
>
> Karl
>>
>> On Tue, November 6, 2012 3:58 pm, karl ramberg wrote:
>>> On Mon, Nov 5, 2012 at 6:30 PM, karl ramberg <[hidden email]>
>>> wrote:
>>>> On Mon, Nov 5, 2012 at 6:45 AM, Steve Thomas <[hidden email]>
>>>> wrote:
>>>>> On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg
>>>>> <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> Great essay by Bret Victor on "Designing a programming system for
>>>>>> understanding programs":
>>>>>>
>>>>>>         http://worrydream.com/LearnableProgramming/
>>>>>>
>>>>>> He clearly explains what makes a programming system "learnable".
>>>>>> While
>>>>>> Etoys does not do all of it, many of its features fit right in, in
>>>>>> particular as compared to other widely used programming systems. An
>>>>>> Etoys
>>>>>> project can be always running, changes have effect immediately, all
>>>>>> state is
>>>>>> visible (through the readouts in viewers) and most of the state can
>>>>>> be
>>>>>> changed directly (e.g. by dragging up and down the number arrows),
>>>>>> tiles
>>>>>> have default arguments so they do something useful immediately,
>>>>>> there
>>>>>> is an
>>>>>> explanation (balloon help) for each tile
>>>>>
>>>>>
>>>>> Yes but it is only textual help.  It would be great if they could be
>>>>> a
>>>>> combination of Ricardo's Speech Bubbles and Ted Kaehler's roll your
>>>>> own
>>>>> quick guide feature.  With one or two changes, the roll your own
>>>>> quick
>>>>> guides should be in a folder in the Etoys directory so it is easier
>>>>> for
>>>>> students and teachers to find and save these guides.  The current
>>>>> location
>>>>> is hard to find, I believe varies by platform and can be locked down
>>>>> by
>>>>> school administrators.  Also when saving a "My Quick Guides"  area
>>>>> would be
>>>>> nice.  Perhaps even encourage folks to modify them by having the New
>>>>> Help/Speech Bubbles have a "Modify Me" icon, which would open a new
>>>>> project
>>>>> with the existing Help/Speech Bubble opened.  We should also have a
>>>>> mechanism to revert to the original so kids can easily experiment
>>>>> without
>>>>> fear of messing things up too badly.
>>>>>
>>>>>
>>>>>> , etc. And maybe this essay inspires some improvements to Etoys :)
>>>>>
>>>>>
>>>>> I currently have the two key take aways so far as it relates to
>>>>> improvements
>>>>> to make in Etoys:
>>>>>
>>>>> "Create by Abstracting"
>>>>> "Recomposition"
>>>>>
>>>>> "Create by Abstracting": I believe the tools are already there, but
>>>>> what is
>>>>> needed is the "Great Literature" and Lessons teachers and learners
>>>>> can
>>>>> use.
>>>>> Not sure how this would impact the interface or if it should, but I
>>>>> think
>>>>> its a really important lesson.  One possible way this could impact
>>>>> interface
>>>>> design is to provide a "turn #/expression into a variable" function.
>>>>> Where
>>>>> there is a way to click/touch on a variable and have a easily
>>>>> discoverable/accesible method to turn it into a variable.  Actually
>>>>> it
>>>>> should work for "players/objects/morphs/colors" as well.
>>>>> Also kudo's to Etoys and its copy/sibling approach which IMO is a
>>>>> better
>>>>> design for "Start with one, make many" than the one for text based
>>>>> languages
>>>>> demonstrated by Brett.
>>>>>
>>>>> "Recomposition": object re-use (across projects) is not very simple
>>>>> in
>>>>> Etoys.  I like Scratch 2.0's use of a Backpack, which yes could be
>>>>> implemented as "add your own" section in the Object Catalog, but I
>>>>> think
>>>>> they made a good design choice in making it an "always there and
>>>>> visible"
>>>>> flap.
>>>>>
>>>>> Regarding "Decomposition" Brett states
>>>>>>
>>>>>> "Consider a programmer who has made a bouncing ball animation. How
>>>>>> does
>>>>>> she go from one ball to two, to a hundred? How does she make the
>>>>>> balls
>>>>>> bounce off one another? How does she make balls draggable with the
>>>>>> mouse? In
>>>>>> a genuine learning environment such as Etoys, this progression is
>>>>>> natural
>>>>>> and encouraged."
>>>>>
>>>>>
>>>>> My suggestions here is that it would be good if Etoys "scaled better"
>>>>> when
>>>>> executing scripts on multiple objects. Unless you are using Kedama
>>>>> (which
>>>>> rocks in this aspect) Etoys slows down when you have say 20+ objects
>>>>> executing.
>>>>>
>>>>> Okay, so that brings me to another area for improvement Kedama.
>>>>> Kedama
>>>>> is
>>>>> amazing and definitely rocks at massively parallel simulations, But
>>>>> it
>>>>> either needs a better (read easier to understand/grok) set of
>>>>> scripting
>>>>> tiles or I need a better model in my head of how it works.  Probably
>>>>> more of
>>>>> the latter than the former.
>>>>
>>>> I found this searching a while ago
>>>> http://www.is.titech.ac.jp/~sassa/lab/papers-written/ohshima-phdthesis-070109.pdf
>>>> I have not read it yet.
>>>
>>>
>>> I skimmed through this and it seems the Etoy user aspects of Kedama is
>>> described in chapter 3 and 4.
>>> I must say Kedama got a lot more understandable reading these chapters
>>> :-)
>>> Maybe we could extract the and post them on Squeakland ?
>>>
>>> Also some chapters have info for the Etoys reference manual eg the
>>> Etoys language extensions and the features.
>>>
>>> Yoshiki:
>>> Is it ok to use/copy from the thesis to the Etoys reference manual and
>>> eventually to a brief Kedama user guide ?
>>>
>>> Karl
>>>
>>>
>>>
>>>
>>>>
>>>> Karl
>>>>>
>>>>> Of course all of the above would be great if we had more development
>>>>> resources :)
>>>>>
>>>>> Cheers,
>>>>> Stephen
>>>>>
>>>>> _______________________________________________
>>>>> squeakland mailing list
>>>>> [hidden email]
>>>>> http://lists.squeakland.org/mailman/listinfo/squeakland
>>>>>
>>> _______________________________________________
>>> squeakland mailing list
>>> [hidden email]
>>> http://lists.squeakland.org/mailman/listinfo/squeakland
>>>
>>
>>
>> --
>> Edward Mokurai
>> (&#40664;&#38647;/&#2344;&#2367;&#2358;&#2348;&#2381;&#2342;&#2327;&#2352;&#2381;&#2332;/&#1606;&#1588;&#1576;&#1583;&#1711;&#1585;&#1580;)
>> Cherlin
>> Silent Thunder is my name, and Children are my nation.
>> The Cosmos is my dwelling place, the Truth my destination.
>> http://wiki.sugarlabs.org/go/Replacing_Textbooks
>>
>>
>> _______________________________________________
>> squeakland mailing list
>> [hidden email]
>> http://lists.squeakland.org/mailman/listinfo/squeakland
>

> Squeakland twice hosted(*) Linda Kao's 37-page PDF tutorial for
> Kedama, and some example projects.
>
> They seem to be missing again. I have the PDF (I tried to send it
> to the list, but quite rightly, it seems that large attachments are blocked)
> and 2 of the 7 projects, but I don't have
> the Word document source.
>
> Did they make it onto flossmanuals?  If not, can someone offer a
> permanent online home for them. Some of the projects are already
> updated and included in the examples section of the Etoys package.
> A couple of others need some tweaks to work in Etoys 5.
> So the appendix listing them needs a little updating.
>
> Rita Freudenberg wrote a shorter tutorial in German:
> http://www.mttcs.org/Projekte/Projekte/Squeak/material/kedama.pdf
>
> David
>
> (*) Some background here
> http://forum.world.st/kedama-tutorial-by-linda-kao-td711852.html (
> another copy here
> http://lists.squeakland.org/pipermail/squeakland/2009-November/005027.html
> ) along with links
> to a brief tutorial by Yoshiki
> http://www.is.titech.ac.jp/~ohshima/squeak/kedama/ and some docs in
> French:
> http://community.ofset.org/index.php/Kedama
> _______________________________________________
> squeakland mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/squeakland

> On Thu, Nov 8, 2012 at 3:56 PM, David Corking <[hidden email]> wrote:
>> Squeakland twice hosted(*) Linda Kao's 37-page PDF tutorial for
>> Kedama, and some example projects.
>>
>> They seem to be missing again. I have the PDF (I tried to send it
>> to the list, but quite rightly, it seems that large attachments are blocked)
>> and 2 of the 7 projects, but I don't have
>> the Word document source.
>>
>> Did they make it onto flossmanuals?  If not, can someone offer a
>> permanent online home for them. Some of the projects are already
>> updated and included in the examples section of the Etoys package.
>> A couple of others need some tweaks to work in Etoys 5.
>> So the appendix listing them needs a little updating.
>>
>> Rita Freudenberg wrote a shorter tutorial in German:
>> http://www.mttcs.org/Projekte/Projekte/Squeak/material/kedama.pdf
>>
>> David
>>
>> (*) Some background here
>> http://forum.world.st/kedama-tutorial-by-linda-kao-td711852.html (
>> another copy here
>> http://lists.squeakland.org/pipermail/squeakland/2009-November/005027.html
>> ) along with links
>> to a brief tutorial by Yoshiki
>> http://www.is.titech.ac.jp/~ohshima/squeak/kedama/ and some docs in
>> French:
>> http://community.ofset.org/index.php/Kedama

> On 2012-11-08, at 00:11, [hidden email] wrote:
>
>> A complete refactoring of Squeak would be a huge undertaking, but I have
>> in mind refactoring a little bit at a time, as recommended in Extreme
>> Programming. At some point, I intend to produce a list of issues that I
>> would like to see fixed. Some of them are quite simple, such as objects
>> not in categories in the Object Catalog, and useful objects not in the
>> Object Catalog at all. (Tetris is not in the Games category.) Producing
>> meaningful comments for most Classes is more complex. There are other
>> coding issues, including bugs. Then there are architectural issues,
>> where
>> we have to ask what purposes we are trying to fulfill.
>
> Since you're new here I should mention that our medium-term goal is to
> merge the Etoys fork of Squeak back into the main squeak.org version,
> which has a larger and more active developer community. The Etoys image
> than would become just a pre-configured variant of Squeak.
>
> That means that if you think about adding better comments for Etoys
> objects, this would best be done in the Etoys image. Comments for other
> Squeak classes would better be contributed directly to Squeak at
> squeak.org.

> Also, since this is very much a developer issue, the etoys-dev list would
> be better suited as discussion place.
>
> - Bert -
>
>
> _______________________________________________
> squeakland mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/squeakland
>

> David
>
> (*) Some background here
> http://forum.world.st/kedama-tutorial-by-linda-kao-td711852.html (
> another copy here
> http://lists.squeakland.org/pipermail/squeakland/2009-November/005027.html
> ) along with links
> to a brief tutorial by Yoshiki
> http://www.is.titech.ac.jp/~ohshima/squeak/kedama/ and some docs in
> French:
> http://community.ofset.org/index.php/Kedama
> _______________________________________________
> squeakland mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/squeakland
>

>I have just watched the talk "It's Not You, It's Them: Why Programming
>Languages Are Hard To Teach" by Zed A. Shaw and he is very critical of
>Bret Victor's ideas, and also mentioned "Squeak Toys" and Scratch as
>examples of fallacies.
>
>>
>>http://oredev.org/2012/sessions/its-not-you-its-them-why-programming-lang
>>uages-are-hard-to-teach
>
>Though I disagree with nearly everything he says, it was still an
>interesting talk. I think that in many cases he subtly misunderstood
>some concepts. His complaint about the lack of formal studies, on the
>other hand, is entirely valid.
>
>An example of his misunderstanding: he shows Bret saying "if a
>programmer can't see something, then she can't understand it". Zed then
>complains about mixing text and drawings and using rectangles as a
>problem domain while the important things are concepts like "for". I am
>with Bret on this one: if a person can't "see" how a "for" works, they
>won't understand it. Most people who get good at programming as it is
>now can see it perfectly in their own heads. Having a visual
>representation animated on the screen will help the other people. Zed
>just ignored the first case of seeing and says the second case is a
>fallacy because "normal" people have trouble switching between
>linguistic and visual modes.
>
>-- Jecel
>
>_______________________________________________
>squeakland mailing list
>[hidden email]
>http://lists.squeakland.org/mailman/listinfo/squeakland

> I have just watched the talk "It's Not You, It's Them: Why Programming
> Languages Are Hard To Teach" by Zed A. Shaw and he is very critical of
> Bret Victor's ideas, and also mentioned "Squeak Toys" and Scratch as
> examples of fallacies.
>
>> http://oredev.org/2012/sessions/its-not-you-its-them-why-programming-languages-are-hard-to-teach
>
> Though I disagree with nearly everything he says, it was still an
> interesting talk. I think that in many cases he subtly misunderstood
> some concepts. His complaint about the lack of formal studies, on the
> other hand, is entirely valid.
>
> An example of his misunderstanding: he shows Bret saying "if a
> programmer can't see something, then she can't understand it". Zed then
> complains about mixing text and drawings and using rectangles as a
> problem domain while the important things are concepts like "for". I am
> with Bret on this one: if a person can't "see" how a "for" works, they
> won't understand it. Most people who get good at programming as it is
> now can see it perfectly in their own heads. Having a visual
> representation animated on the screen will help the other people. Zed
> just ignored the first case of seeing and says the second case is a
> fallacy because "normal" people have trouble switching between
> linguistic and visual modes.
>
> -- Jecel
>
> _______________________________________________
> squeakland mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/squeakland