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.ben...@gmail.com>wrote: > > > On Tue, Jun 7, 2011 at 6:15 PM, Dr. Gerald Ardito <gerald.ard...@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.ben...@gmail.com>wrote: >> >>> >>> >>> On Tue, Jun 7, 2011 at 6:06 PM, Dr. Gerald Ardito < >>> gerald.ard...@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.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!) >>>>> i...@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 > >
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel