[IAEP] Turtles All The Way Out

[John Gilmore]

I had to think about this some before having a useful response.

> I cannot speak for every Sugar developer, but the approach I have tried to
> take with Turtle Art is a bit different than you are describing. The
> block-based programming environment is not meant to be a substitute for real
> tools; it is meant to be a place to get started; to learn that you can write
> and modify code; and to provide multiple motivations and launch pads for
> getting into the "real" thing. I've worked pretty hard to make the
> "structured thing" behind the view more approachable, and have provided
> multiple ways in and out: exporting your "fluffy" view into Logo that can be
> run in Brian Harvey's text-based Logo environment; direct, in-line
> extensions written in Python; the ability to create new blocks by importing
> Python; a plugin mechanism for making major interventions; and a refactoring
> of the underlying structures to make the code more approachable. (The source
> code is peppered with comments and examples of how to make modifications.)
> None of these interventions are intended to keep the kids programming in
> Turtle Art. They are all intended to get the kids started down the path of
> "real" programming. But I content that we need to engage them; let them
> discover that they can write code; and make changes; and that it is not
> something just for "others" but for everyone. 

Walter, this is a worthwhile approach.

But it was all invisible from an OLPC user's point of view (i.e. a
child's).  All they get is a GUI in which they can hook blocks
together and see graphics.

Even finding the library of fun looking pre-existing designs was hard
(it's hiding behind a bizarre looking icon that you can't even see
until you go to a different tab in the Frame than the default one).
If you show a kid how to find one of those designs, they get the idea
of TurtleArt, and can modify them to see how the design changes.
Until they see a complete, working design in 10 blocks including a
loop, TurtleArt is a morass where new users can drag things around but
it doesn't do anything fun.

(Note I'm working from memory of a several-year-old TurtleArt.  Perhaps
it's better now.)

(Also, it's hard to make the leap from a slow turtle leaving marks
behind as it goes two steps and turns, to the whole screen being
filled with colors in a flash.  Most things in the world don't have
the many-orders-of-magnitude speedups that we in computing have become
blase about.  It wouldn't occur to us that to paint an entire wall in
a second, we should tell the painter to move the brush one inch and
then repeat that over and over until done.  We'd look for a spray gun,
or toss a whole bucket of paint, or recruit a crowd of painters, or
something.  Fast things and painstaking things aren't disjoint in
computing, as they are elsewhere; how do you teach that powerful insight?)

> I am open to suggestions as to how to get more kids to move on from Turtle
> Art to ___ (insert you favorite "real" programming environment here).

First, have Turtle Art start up not with a blank slate, but by
bringing in one of the predefined designs -- preferably at random, so
they'll see more of the corpus as they run it over and over.

Second, I suggest that if some blocks are implemented in short bits of
Python, that there be a user interface for seeing and modifying those
short bits of Python (by examining the block in the GUI).  This will
provide a bridge for exploring kids to notice that the blocks are
built out of short bits of structured text -- and that they can
understand and modify those texts.  If they've already figured out
that they can modify the numeric blocks, then they'll try modifying
these too.  The thing that pops the blocks open shouldn't be too hard
to find -- perhaps a double-click, or something else that they'll do
by accident sometime.

If you can implement more blocks in such bits of Python, do it, so
they'll have more blocks they can open up and examine and modify from
the GUI.

How to get them beyond the TurtleArt GUI into the actual Python source
code of the body of TurtleArt is a challenge that nobody seems to have
insight on.  The "View Source" concept seems to have been much harder
to implement than we all expected.

Don Hopkins worked on a PostScript-based window system (HyperLook)
that would let you "flip over" an object on the screen to see "behind
it" a control panel with the guts of its implementation visible.  You
could modify those, then "flip it back" and it would resume running.
See: http://www.art.net/~hopkins/Don/hyperlook/index.html and
http://www.art.net/~hopkins/Don/simcity/hyperlook-demo.html .

Looking back at HyperLook, it looks a lot like the etoys environment,
full of object oriented code with direct manipulation gui editor
interfaces.  It's dead now; a historical curiosity of interest only to
prior-art searchers defeating too-obvious software patents.  It's hard
to keep such self-contained and self-referential environments alive
and relevant in the world at large.  I think one problem is that the
state of the environment doesn't get kept in simple text "files" -- a
concept of enduring value.  My old APL programs are all dead too; they
were "objects" in "workspaces" and weren't usually stored in small,
persistent, portable, named, modular textual representations, the way
C or Python programs are.

Perhaps the key is to keep these immersive environments sufficiently
tiny that you don't mind them dying when you turn your attention to
something else.  Tininess also helps to make one understandable and
modifiable by others in case they DO want to keep it going after you
move on.

	John