[IAEP] Turtles All The Way Out

Tue Jun 7 18:17:24 EDT 2011

On Tue, Jun 7, 2011 at 6:15 PM, Dr. Gerald Ardito
<gerald.ardito at gmail.com>wrote:

> Walter,
>
> Thanks. And I'll check out Fred Martin's book.
> If you are up for another visit to us in the Fall to do some more intensive
> Turtle Art work, we'd love to have you.
>

Sounds like fun. Maybe early in the semester to get them up and running.

-walter

>
>
> Gerald
>
>
> On Tue, Jun 7, 2011 at 6:13 PM, Walter Bender <walter.bender at gmail.com>wrote:
>
>>
>>
>> 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
>>
>>
>

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20110607/f5eea7b1/attachment.html>