[IAEP] Turtles All The Way Out

Tue Jun 7 18:06:42 EDT 2011

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?
2. In order to use sensors, what kind of devices are you talking about
(WeDos?; Arduino? Something else?).
3. Do you have or know of a curriculum that addresses our project?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20110607/607990d3/attachment.html>