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.ben...@gmail.com>wrote: > > > On Mon, Jun 6, 2011 at 8:11 PM, John Gilmore <g...@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@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep >
_______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep