[IAEP] Turtles All The Way Out

[mokurai at earthtreasury.org]

On Mon, June 6, 2011 8:11 pm, John Gilmore wrote:
> I had to think about this some before having a useful response.

Excellent questions, and very timely.

I believe that Walter Bender wrote:
>> 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 contend 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.

Several programming languages have been successfully taught in third
grade, including Logo, LISP, Smalltalk, BASIC and a few others. APL has
been successfully taught as a math language rather than a programming
language starting in first grade, with programming introduced in third
grade. (APL is the only programming language that has times × and divide ÷
symbols that match first-grade arithmetic books, as does the XO keyboard.)

All of the successful experiments that I know of on teaching programming
in elementary school started with simple examples and free exploration,
and then showed users how to make small modifications to start with,
advancing gradually through various problems of interest and the relevant
functions and features of the languages. There is an excellent tutorial
sequence of problems on the front page of Etoys, and there are people
working on creating a sequence of perhaps a hundred topics to introduce
the rest of the language. We must do the same in Turtle Art.

> 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.

Exactly so. See my Wiki page, The Undiscoverable, about this problem in
Sugar generally, and the necessity of providing hints at appropriate
points in lessons that require these features.

http://wiki.sugarlabs.org/go/The_Undiscoverable

I am about to give Turtle Art its own page, discussing the issues you
raise, and suggesting a strategy to overcome them.

Also http://booki.treehouse.su/discovering-discovery/

which should soon have a chapter on Turtle Art, and eventually others on
other approaches to programming in Smalltalk, Python, and FORTH.

> 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.

The sequence

* Play with blocks and GUI
* Square example (7 blocks with loop)
* Play with example
* Squares example (13 blocks with nested loops)
* Play with example
* Flower example (3 nested routines with 20, 7, and 6 blocks, each
containing a loop)
* Play with example

does what you want. Start with moving, drawing lines, and turning. Then
put move and turn together, and repeat four times. Then repeat that
several times at angles that make up a full circle. Then do that in
different sizes and colors. Allow sufficient time for exploration in
between. Answer questions with well-chosen hints, rather than showing
students exactly how something works.

I have been working on various ideas for math and physics lessons based on
Turtle Art, and I am about to work out a proper sequence of programming
ideas covering many basic programming and Computer Science ideas,
involving every block and other function in Turtle Art. I have mentioned
elsewhere in this thread that I like Turtle Art because it exposes a
central concept in programming and Computer Science, the parse tree, and
because it allows us to build models of other CS concepts.

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

Much better. TA-108 has infix arithmetic and logic, much better variable
and subroutine handling, better control structures, stack programming,
presentations, sensors, polar and cartesian coordinates, the ability to
save TA programs as Logo and TA art as .png files...It also runs on
Ubuntu, as its immediate predecessors did not. (Testers of TA and other
activities on other distros, please join me.)

> (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?)

With a sequence of models and hints. What is the fastest and simplest way
to paint the screen? One quick way is to make the brush the width of the
screen, and go forward the height from an appropriate spot. How else can
you do it? Loop. And? That would be telling. Go find the actual quickest
way yourself. There is no difficulty in this task, if you just click
everything in sight until the "Aha!" moment.

What is the fiddliest way to paint the whole screen? How about a Peano
space-filling curve? It requires some class preparation, of course, but
the program could be added to the examples directory even without
explanation.

>> 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).

In the same way, we can create models using Turtle Art with a graded
sequence of Python blocks illustrating almost all of the functions and
syntax of Python. We can do the same with Logo, using the ability to save
TA programs as Logo, and with Smalltalk, which has its own Turtle Graphics
module.

> 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.

No, thank you, I think. That means that students have to discover how to
get a blank slate. But making the Examples directory much more prominent
would help. Perhaps the UI could start with buttons for Examples, Load
from Journal, and Blank screen, which would disappear if the user clicked
anything else.

> 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).

Absolutely. Walter has added a two-place Python block that takes a
function on a text block and a variable or constant argument. It will also
give me an excuse to teach argument bindings and namespaces.

> 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.

No, it's right there in the GUI. You are thinking of the old Pippy python
block that takes code from a file in the Journal. It is still there, but
can be reserved for more advanced users who need more than single lines of
code.

> 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.

Will do. I have a TA program that graphs a given Python function, and I
can make many more interesting examples.

> 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.

You can select Python blocks from the Journal. By default they are named
tamyblock.py, but you can give them meaningful names. You can write and
display Python code in Write and Pippy, and with Terminal you have access
to nano and pico.

We need to provide hints to budding programmers at the appropriate points
in the process. Once they are used to working with blocks of Python code,
we can show them where to find the TA and other activity code, and how to
experiment with it. On my Ubuntu system, that would be in

/usr/share/sugar/activities
~/Activities

Motivated students can do quite a lot with that information and a text
editor in Terminal, and we can do much more for them than that.

> 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.

The underlying Smalltalk language allows users to view the source of every
object, down to the virtual machine. We can use the Etoys turtle graphics
functions to do what you are asking for here.

> 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;

Mine aren't.

> 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.

But I helped create the first ISO/ANSI standard APL system, and I tended
to stay with standard features. There is a WorkSpace Interchange Standard
that will let you get code from working programs into files, and then into
other APL systems. However, J uses external code files in ASCII.

> 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.

Smalltalk/Etoys seems to be a counterexample to your claim.

> 	John
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>


-- 
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