[IAEP] Turtles All The Way Out

[Walter Bender]

On Tue, Jun 7, 2011 at 6:06 PM, Dr. Gerald Ardito
<gerald.ardito at gmail.com>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.
> 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?
>
Yes. v108 should run on any XO build.

2. In order to use sensors, what kind of devices are you talking about
> (WeDos?; Arduino? Something else?).
>
Those are all nice, but just using the microphone in works nicely. Plus you
have the camera.


> 3. Do you have or know of a curriculum that addresses our project?
>
There are lots of bits and pieces. Regarding robots, there is a nice book
written by Fred Martin that came out maybe 5 years ago. (Fred was one of the
principal designers of the original Lego robotics kits at MIT and helped
develop with 6.270 curriculum. He teaches at UMass-Lowell.

enjoy.

-walter

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


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20110607/4956b795/attachment.html>