[squeakland] Learnable Programming

karl ramberg karlramberg at gmail.com
Mon Nov 5 12:30:42 EST 2012

On Mon, Nov 5, 2012 at 6:45 AM, Steve Thomas <sthomas1 at gosargon.com> wrote:
> On Thu, Sep 27, 2012 at 6:24 AM, Bert Freudenberg <bert at 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
I have not read it yet.

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

More information about the squeakland mailing list