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, etc. And maybe this essay inspires some improvements to Etoys :)
- Bert -
On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg bert@freudenbergs.dewrote:
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
On Mon, Nov 5, 2012 at 6:45 AM, Steve Thomas sthomas1@gosargon.com wrote:
On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg bert@freudenbergs.de 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-07010... 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 squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
On Mon, Nov 5, 2012 at 6:30 PM, karl ramberg karlramberg@gmail.com wrote:
On Mon, Nov 5, 2012 at 6:45 AM, Steve Thomas sthomas1@gosargon.com wrote:
On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg bert@freudenbergs.de 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-07010... 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 squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
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.
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?
On Tue, November 6, 2012 3:58 pm, karl ramberg wrote:
On Mon, Nov 5, 2012 at 6:30 PM, karl ramberg karlramberg@gmail.com wrote:
On Mon, Nov 5, 2012 at 6:45 AM, Steve Thomas sthomas1@gosargon.com wrote:
On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg bert@freudenbergs.de 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-07010... 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 squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
On Wed, Nov 7, 2012 at 8:00 PM, mokurai@earthtreasury.org 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 karlramberg@gmail.com wrote:
On Mon, Nov 5, 2012 at 6:45 AM, Steve Thomas sthomas1@gosargon.com wrote:
On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg bert@freudenbergs.de 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-07010... 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 squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
-- Edward Mokurai (默雷/निशब्दगर्ज/نشبدگرج) 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 squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
I intend to do a proofreading pass through all of Squeak when my part in the Etoys Reference Manual is done. I think I understand how to create and submit a change file, and I know I will understand when the time comes.
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.
I am trying to get Etoys into a state in which I can explain how to introduce it in detail at various levels of child development for various purposes. Among those purposes is the creation of digital replacements for textbooks, now that computers with Free Software and Creative Commons content cost much less than printed textbooks. We know how to do paged books, multimedia, and other formats, but we do not know what is most effective to use, nor do we know what we can teach most effectively.
Another purpose should be to answer in detail Seymour Papert's question, whether we can create an environment in which children can learn math and programming as readily as they learn to speak. We know that this can be done in other subject areas, such as art, music, history, geography, health, and so on. The question has been raised whether computers can teach children in illiterate societies to read and write. We have some positive but incomplete data on that question, and people with ideas to contribute.
On Wed, November 7, 2012 3:18 pm, karl ramberg wrote:
On Wed, Nov 7, 2012 at 8:00 PM, mokurai@earthtreasury.org 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 karlramberg@gmail.com wrote:
On Mon, Nov 5, 2012 at 6:45 AM, Steve Thomas sthomas1@gosargon.com wrote:
On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg bert@freudenbergs.de 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-07010... 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 squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
-- Edward Mokurai (默雷/निशब्दगर्ज/نشبدگرج) 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 squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
On 2012-11-08, at 00:11, mokurai@earthtreasury.org 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 -
Copied to Etoys-Dev. We can drop this topic from the general Etoys discussion, and take up Etoys By Example there. I will raise these refactoring issues on Squeak Dev also.
On Thu, November 8, 2012 9:32 am, Bert Freudenberg wrote:
On 2012-11-08, at 00:11, mokurai@earthtreasury.org 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.
Noted. I assume that you mean balloon help in Etoys, and Class comments in Squeak.
Also, since this is very much a developer issue, the etoys-dev list would be better suited as discussion place.
- Bert -
squeakland mailing list squeakland@squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
On Tue, Nov 6, 2012 at 12:58 PM, karl ramberg karlramberg@gmail.com 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!
On Wed, Nov 7, 2012 at 8:06 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Tue, Nov 6, 2012 at 12:58 PM, karl ramberg karlramberg@gmail.com 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
No, Thank you :-)
Karl
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-languag...
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@lists.squeakfoundation.org
-
Bert Freudenberg -
Jecel Assumpcao Jr. -
karl ramberg -
mokurai＠earthtreasury.org -
Steve Thomas -
Yoshiki Ohshima