[IAEP] Turtles All The Way Out

Dr. Gerald Ardito gerald.ardito at gmail.com
Tue Jun 7 18:18:44 EDT 2011 

Walter,

That would be great. Thanks.
Can you look and see when in September might work for you?

Gerald

On Tue, Jun 7, 2011 at 6:17 PM, Walter Bender <walter.bender at gmail.com>wrote:

>
>
> 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/b8dd9a7a/attachment.html>

More information about the Devel mailing list