[squeakland] Learnable Programming

[Steve Thomas]

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.

Of course all of the above would be great if we had more
development resources :)

Cheers,
Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/squeakland/attachments/20121105/1005c4cc/attachment.html>