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
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel