Re: Learnable Programming

On Mon, Nov 5, 2012 at 6:30 PM, karl ramberg <[email protected]> wrote:
> On Mon, Nov 5, 2012 at 6:45 AM, Steve Thomas <sthomas1-gQhbkF4bah9Wk0Htik3J/[email protected]> wrote:
>> On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg <[email protected]>
>> 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
>> [email protected]
>> http://lists.squeakland.org/mailman/listinfo/squeakland
>>