[IAEP] Turtles All The Way Out

[mokurai at earthtreasury.org]

On Tue, June 7, 2011 6:06 pm, Dr. Gerald Ardito wrote:
> Walter and Edward,
>
> I am very interested in this conversation.
> As you know, I have been working with 5th graders and XO Laptops for the
> past 3 years in the middle school in which I teach.
> For next year, I have designed a pilot program to teach our 6th graders
> about programming software and devices. I have seen the sequence as
> beginning with software and then leading to robots of some kind.
> I think Turtle Art is a perfect place to start, especially given this
> conversation, and the availability of the XOs.

True. Of course, it works even better if introduced in preschool, with the
teacher giving commands to a child being the turtle, and then children
give commands to each other, for some time before getting on the computer.
I have been working on a version of TA with icons rather than words on the
blocks, and would like to get it tested in kindergarten.

There have been numerous experiments on introducing programming in third
grade in a number of languages. (It is also possible to introduce
calculator languages in first grade.) The usual starting point is to give
children simple programs to run, then show them how to make simple changes
such as variable values. Peter Hewitt's Spirolateral and Turtle Machine
programs are examples of this, where children get to set parameters and
see what they get, and learn to predict what they get as they try to match
the forms presented to them.

> So, I am willing to test out the work you are doing with these students.
>
> I have some questions:
> 1. Will the recent version of Turtle Art (Turtle Blocks) run on the latest
> XO build?

I don't know. I have not been able to install recent versions of Sugar on
my two XOs. However TA-109 works fine in Ubuntu.

> 2. In order to use sensors, what kind of devices are you talking about
> (WeDos?; Arduino? Something else?).

http://wiki.sugarlabs.org/go/Activities/TurtleArt#Sensors_Palette

* keyboard
* sound from microphone
* voltage from sound input port
* time
* read color from camera
* read color from canvas

The OLPC XO can measure external inputs with its microphone jack:

    resistance: measurement range is 750 to 14k ohms, (OLPC XO1) and 2k
ohms to open circuit (OLPC XO1.5)
    voltage: measurement range is DC 0.4V to 1.85V. (OLPC XO1) and 0.17V
to 3.0V (OLPC XO1.5)

http://wiki.sugarlabs.org/go/Activities/TurtleArt/Using_Turtle_Art_Sensors

many examples

> 3. Do you have or know of a curriculum that addresses our project?

We are building one. What topics would you like to brainstorm with us?

I am going to build a Turing Machine in Turtle Art, using read pixel to
read the state from the tape and the instructions from the program array.
In a sort of TA pseudocode,

Write tape
Write program table
Go to beginning of tape
Repeat until state = halt
  read pixel #from tape
  arithmetic on state value and pixel (tape symbol) value; goto row of
program array
  read pixel #from first column of program array
    subroutine: go to tape and write the same pixel color, then go back to
program array
  move right
  read pixel, set that as new state #from second column
  move right
  read pixel #from third column
  go to current cell on tape
  move left or right on tape in response to value read

with a bit more housekeeping code to keep from running off either end of
the tape.

> Thanks.
> Gerald
>
> On Tue, Jun 7, 2011 at 7:37 AM, Walter Bender
> <walter.bender at gmail.com>wrote:
>
>>
>>
>> On Mon, Jun 6, 2011 at 8:11 PM, John Gilmore <gnu at toad.com> wrote:
>>
>>> I had to think about this some before having a useful response.
>>>
>>
>> Lots of good ideas here, so thank you for taking the time.
>>
>>>
>>> > 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.)
>>>
>>
>> Please grab a recent version. It is quite different from even a year
>> ago.
>>
>>>
>>> (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?)
>>>
>>
>> Cute idea for a project: "fill the screen." There are of course many
>> ways
>> to do it: from using the fill-screen block to setting the pen size to
>> the
>> screen width to discovering the repeat block to discovering that you can
>> launch as many turtles as you'd like, each of which has a pen.
>>
>>>
>>> > 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.
>>>
>>
>> I have gone back and forth on this one. I think that you are right: I
>> should start with a program on the screen, probably a simple example of
>> a
>> spiral that introduces the concepts of loops and variables (and perhaps
>> sensors).
>>
>>
>>>
>>> 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.
>>>
>>
>> All of the blocks are implemented as short bits of Python. But I
>> deferred
>> to the Sugar View Source mechanism for revealing the contents. I use a
>> simple plug-in mechanism to define blocks and palettes, but the
>> disconnect
>> is that I don't (generally) edit them in line; rather, I leave that to
>> other
>> tools. This was a design decision; in part my goal was to give incentive
>> to
>> using Pippy and Edit rather than recreate Pippy and Edit in Turtle Art
>> itself. But I suppose that making it possible to change them directly in
>> Turtle Art as well maybe necessary. I can do it easily enough, but it
>> adds
>> more complexity.
>>
>>
>>> 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.
>>>
>>
>> I am hoping that the recent work I have been doing on View Source -- you
>> can use it to make copies of the source -- may help.
>>
>>
>>>
>>> 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.
>>>
>>
>> This is why I am trying to get kids to leave Turtle Art behind. It is
>> there
>> as a hook to get them started, but not intended to be more than a
>> stepping
>> stone.
>>
>>
>>>
>>> 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
>>>
>>>
>> It is worth pointing out that there are some math teachers in .UY who
>> are
>> using the export SVG capabilities of Turtle Art to launch their students
>> into more sophisticated graphing and data visualization. Not what I had
>> expected, but quite a good outcome nonetheless.
>>
>> -walter
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>>
>>
>> _______________________________________________
>> IAEP -- It's An Education Project (not a laptop project!)
>> IAEP at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep


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