Re: [IAEP] Turtles All The Way Out
On Mon, Jun 6, 2011 at 8:11 PM, John Gilmore g...@toad.com wrote: 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 . Self: The Movie is also worth watching. The self guys thought that continuous execution of the code was important for liveness, along with some other views (like direct correspondence between objects and representation) which I don't think I actually agree with. But still, worth thinking about: http://www.smalltalk.org.br/movies/ --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Out
On Tue, June 7, 2011 6:06 pm, Dr. Gerald Ardito 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. True. Of course, it works even better if introduced in preschool, with the teacher giving commands to a child being the turtle, and then children give commands to each other, for some time before getting on the computer. I have been working on a version of TA with icons rather than words on the blocks, and would like to get it tested in kindergarten. There have been numerous experiments on introducing programming in third grade in a number of languages. (It is also possible to introduce calculator languages in first grade.) The usual starting point is to give children simple programs to run, then show them how to make simple changes such as variable values. Peter Hewitt's Spirolateral and Turtle Machine programs are examples of this, where children get to set parameters and see what they get, and learn to predict what they get as they try to match the forms presented to them. 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? I don't know. I have not been able to install recent versions of Sugar on my two XOs. However TA-109 works fine in Ubuntu. 2. In order to use sensors, what kind of devices are you talking about (WeDos?; Arduino? Something else?). http://wiki.sugarlabs.org/go/Activities/TurtleArt#Sensors_Palette * keyboard * sound from microphone * voltage from sound input port * time * read color from camera * read color from canvas The OLPC XO can measure external inputs with its microphone jack: resistance: measurement range is 750 to 14k ohms, (OLPC XO1) and 2k ohms to open circuit (OLPC XO1.5) voltage: measurement range is DC 0.4V to 1.85V. (OLPC XO1) and 0.17V to 3.0V (OLPC XO1.5) http://wiki.sugarlabs.org/go/Activities/TurtleArt/Using_Turtle_Art_Sensors many examples 3. Do you have or know of a curriculum that addresses our project? We are building one. What topics would you like to brainstorm with us? I am going to build a Turing Machine in Turtle Art, using read pixel to read the state from the tape and the instructions from the program array. In a sort of TA pseudocode, Write tape Write program table Go to beginning of tape Repeat until state = halt read pixel #from tape arithmetic on state value and pixel (tape symbol) value; goto row of program array read pixel #from first column of program array subroutine: go to tape and write the same pixel color, then go back to program array move right read pixel, set that as new state #from second column move right read pixel #from third column go to current cell on tape move left or right on tape in response to value read with a bit more housekeeping code to keep from running off either end of the tape. Thanks. Gerald On Tue, Jun 7, 2011 at 7:37 AM, Walter Bender walter.ben...@gmail.comwrote: 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
Re: [IAEP] Turtles All The Way Out
On Mon, June 6, 2011 8:11 pm, John Gilmore wrote: I had to think about this some before having a useful response. Excellent questions, and very timely. I believe that Walter Bender wrote: 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 contend 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. Several programming languages have been successfully taught in third grade, including Logo, LISP, Smalltalk, BASIC and a few others. APL has been successfully taught as a math language rather than a programming language starting in first grade, with programming introduced in third grade. (APL is the only programming language that has times × and divide ÷ symbols that match first-grade arithmetic books, as does the XO keyboard.) All of the successful experiments that I know of on teaching programming in elementary school started with simple examples and free exploration, and then showed users how to make small modifications to start with, advancing gradually through various problems of interest and the relevant functions and features of the languages. There is an excellent tutorial sequence of problems on the front page of Etoys, and there are people working on creating a sequence of perhaps a hundred topics to introduce the rest of the language. We must do the same in Turtle Art. 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. Exactly so. See my Wiki page, The Undiscoverable, about this problem in Sugar generally, and the necessity of providing hints at appropriate points in lessons that require these features. http://wiki.sugarlabs.org/go/The_Undiscoverable I am about to give Turtle Art its own page, discussing the issues you raise, and suggesting a strategy to overcome them. Also http://booki.treehouse.su/discovering-discovery/ which should soon have a chapter on Turtle Art, and eventually others on other approaches to programming in Smalltalk, Python, and FORTH. 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. The sequence * Play with blocks and GUI * Square example (7 blocks with loop) * Play with example * Squares example (13 blocks with nested loops) * Play with example * Flower example (3 nested routines with 20, 7, and 6 blocks, each containing a loop) * Play with example does what you want. Start with moving, drawing lines, and turning. Then put move and turn together, and repeat four times. Then repeat that several times at angles that make up a full circle. Then do that in different sizes and colors. Allow sufficient time for exploration in between. Answer questions with well-chosen hints, rather than showing students exactly how something works. I have been working on various ideas for math and physics lessons based on Turtle Art, and I am about to work out a proper sequence of programming ideas covering many basic programming and Computer Science ideas, involving every block and other function in Turtle Art. I have mentioned elsewhere in this thread that I like Turtle Art because it exposes a central concept in programming and Computer Science, the parse tree, and because it allows us to build models of other CS concepts. (Note I'm working from memory of a several-year-old TurtleArt. Perhaps it's
Re: [IAEP] Turtles All The Way Out
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
Re: [IAEP] Turtles All The Way Out
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.comwrote: 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
Re: [IAEP] Turtles All The Way Out
On Tue, Jun 7, 2011 at 6:06 PM, Dr. Gerald Ardito gerald.ard...@gmail.comwrote: 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.comwrote: 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
Re: [IAEP] Turtles All The Way Out
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. Gerald On Tue, Jun 7, 2011 at 6:13 PM, Walter Bender walter.ben...@gmail.comwrote: 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.comwrote: 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
Re: [IAEP] Turtles All The Way Out
On Tue, Jun 7, 2011 at 6:15 PM, Dr. Gerald Ardito gerald.ard...@gmail.comwrote: 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.comwrote: 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.comwrote: 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
Re: [IAEP] Turtles All The Way Out
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.comwrote: 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.comwrote: 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.comwrote: 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
Re: [IAEP] Turtles All The Way Out
I had to think about this some before having a useful response. 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.) (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?) 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. 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. 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. 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
Re: [IAEP] Turtles All The Way Out
On Fri, May 20, 2011 3:11 pm, Walter Bender wrote: On Fri, May 20, 2011 at 2:28 PM, John Gilmore g...@toad.com wrote: Recently, I finished my dissertation on mobile development directly from mobile devices. Something like this might've been very useful, although I did target experienced developers, not beginners. When we get to wearables with glasses-mounted full-sized display devices and one-hand chord keyboards, absolutely. Or when soft keyboards on multitouch tablets are totally reliable. Mobile development would work great on mobile devices like the XO-1, XO-1.5, XO-1.75, and perhaps even the XO-3, if only we'd teach the kids a few simple paradigms like files, hierarchical file systems and text editors. See Introduction to the Command Line http://booki.flossmanuals.net/command-line/edit/ of which I am a co-author. I don't know where you get the idea that files, hierarchical file systems, and text editors are simple concepts. I would be willing to discuss introducing the Linux file system in middle school, but our issue is programming for third-graders, or even earlier. Preschoolers can grasp the ideas behind turtle art by acting the part of the turtle. Where would you have them begin? Sugar comes with a plain-text editor (written by a 14-year-old, BTW) and files (and even a hierarchical file system) that has a data store as its primary interface. The problem with mobile development on mobile devices is not one of religion, it is about physical affordances: small screen and no (or inadequate) keyboard. (Efforts to teach computers to compile or interpret large programs that aren't written in collections of files are doomed to niche uselessness, though it sure makes a fun research/masturbation topic. Language, John, our discussion of child programming must be discussable with the children, their parents, and their parents' churches and political parties. The archive of this list is public information. I spent years paid to write big programs in APL that way in the '70s -- those programs are all unportably dead today, and APL is a tiny niche.) I have an ISO/ANSI standard APL that occupies 29K, thus originally giving a 32K workspace on 8-bit computers with 64K memory. It could easily be expanded to run with any amount of memory. Ken Iverson successfully used IBM APL\360 to teach first-grade arithmetic on a 360 with Selectric terminals. I also have books on math and other subjects in APL, from arithmetic to calculus, cryptography, and computer design. These are not hard concepts. Kids learn them daily, but not from XOs. Kids of what age? Since OLPC can't seem to be dissuaded from this fundamental error, because it isn't one, the question for me is whether it can be influenced to minimize the amount of learning that kids go through which is unique to this useless programming model. The point is to maximize learning in minimum time or with minimum effort. There *is* usefulness in teaching kids how to write tiny programs that can never scale up to useful, portable, supportable programs. But once they get the basic concepts, they should be transitioned to industry best worst, actually (Did you ever hear of the programmer who claimed to have 20 years experience in COBOL, but it turned out he had two years experience repeated 10 times?) No industry has ever embraced best practices. practices pretty quickly, writing a real Hello World So Hello World in Turtle Art is unreal? Here is a complete APL Hello, World. program, with its output. 'Hello, World.' Hello, World. and a complete Turtle Art version PrintTextVariable Hello, World. which the activity will be happy to convert to Logo. Next you put a Python function call on a single block to print the text, and away you go. and then evolving it to be more useful. Precisely. I prefer to teach not only programming but computer science concepts in the early years. One of the great advantages of Turtle Art is that there is no parsing step to translate from linear text with bizarre punctuation rules to a tree structure. The children program directly in effectively preparsed tree structures, with no syntactic sugar, as the LISPers call it. Also, Walter has built stack primitives into Turtle Blocks, so we can teach stack discipline and the rudiments of FORTH in Turtle Art. He recently added a block to read the color at the turtle's location. I had mentioned to him some time ago that that was the only function missing for me to write a Turing machine in Turtle Art, using colors for cell states and elements in the transition table. I must do that sometime. Rather than getting stuck by e.g. trying to make substantial programs fit on one screen by moving tiles around visually. Strawman. Not the purpose of Turtle Blocks, and not something we would encourage anybody to do. At that point you start writing Python subroutines, and shortly after that you transfer completely to Python. Or Smalltalk. And from
Re: [IAEP] Turtles All The Way Out
Recently, I finished my dissertation on mobile development directly from mobile devices. Something like this might've been very useful, although I did target experienced developers, not beginners. Mobile development would work great on mobile devices like the XO-1, XO-1.5, XO-1.75, and perhaps even the XO-3, if only we'd teach the kids a few simple paradigms like files, hierarchical file systems and text editors. (Efforts to teach computers to compile or interpret large programs that aren't written in collections of files are doomed to niche uselessness, though it sure makes a fun research/masturbation topic. I spent years paid to write big programs in APL that way in the '70s -- those programs are all unportably dead today, and APL is a tiny niche.) These are not hard concepts. Kids learn them daily, but not from XOs. Since OLPC can't seem to be dissuaded from this fundamental error, the question for me is whether it can be influenced to minimize the amount of learning that kids go through which is unique to this useless programming model. There *is* usefulness in teaching kids how to write tiny programs that can never scale up to useful, portable, supportable programs. But once they get the basic concepts, they should be transitioned to industry best practices pretty quickly, writing a real Hello World and then evolving it to be more useful. Rather than getting stuck by e.g. trying to make substantial programs fit on one screen by moving tiles around visually. As in the model-view-controller paradigm, the kids need to learn that the view is not the model, but the model is a simply structured thing that lives behind the view. If you don't teach the abstract structures that the model is based on, the kids can't learn to make that separation. This is why they never learn to modify the real programs that hide behind the fluffy interfaces on their real XO computers. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Out
On Fri, May 20, 2011 at 2:28 PM, John Gilmore g...@toad.com wrote: separation. This is why they never learn to modify the real programs that hide behind the fluffy interfaces on their real XO computers. I hope to show you a system where the real program *is* the fluffy interface (and vice versa). I'm not at that point yet, but you've correctly extracted the point of this particular research program. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Out
On Fri, May 20, 2011 at 2:28 PM, John Gilmore g...@toad.com wrote: Recently, I finished my dissertation on mobile development directly from mobile devices. Something like this might've been very useful, although I did target experienced developers, not beginners. Mobile development would work great on mobile devices like the XO-1, XO-1.5, XO-1.75, and perhaps even the XO-3, if only we'd teach the kids a few simple paradigms like files, hierarchical file systems and text editors. Sugar comes with a plain-text editor (written by a 14-year-old, BTW) and files (and even a hierarchical file system) that has a data store as its primary interface. The problem with mobile development on mobile devices is not one of religion, it is about physical affordances: small screen and no (or inadequate) keyboard. (Efforts to teach computers to compile or interpret large programs that aren't written in collections of files are doomed to niche uselessness, though it sure makes a fun research/masturbation topic. I spent years paid to write big programs in APL that way in the '70s -- those programs are all unportably dead today, and APL is a tiny niche.) These are not hard concepts. Kids learn them daily, but not from XOs. Since OLPC can't seem to be dissuaded from this fundamental error, the question for me is whether it can be influenced to minimize the amount of learning that kids go through which is unique to this useless programming model. There *is* usefulness in teaching kids how to write tiny programs that can never scale up to useful, portable, supportable programs. But once they get the basic concepts, they should be transitioned to industry best practices pretty quickly, writing a real Hello World and then evolving it to be more useful. Rather than getting stuck by e.g. trying to make substantial programs fit on one screen by moving tiles around visually. As in the model-view-controller paradigm, the kids need to learn that the view is not the model, but the model is a simply structured thing that lives behind the view. If you don't teach the abstract structures that the model is based on, the kids can't learn to make that separation. This is why they never learn to modify the real programs that hide behind the fluffy interfaces on their real XO computers. 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. When I talked about Turtles All the Way Down at Libre Planet two-years ago, I wasn't suggesting that we use fluffy interfaces all the way down, but that we invite modifications all the way down by providing scaffolding and encouragement. Step One is to give them the freedom to make changes; Step Two is to give them the context in which they can actually start doing it. Sure, there will always be the handful of kids who will jump right into Emacs and C, but most won't. Maybe we can encourage a few more to do something of substance but giving them some scaffolding. 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). -walter John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Turtles All The Way Out
Actually, I said I made up the term 'Object-oriented', and I did not have C++ in mind. Cheers, Alan From: moku...@earthtreasury.org moku...@earthtreasury.org To: Walter Bender walter.ben...@gmail.com Cc: Lucian Branescu lucian.brane...@gmail.com; IAEP SugarLabs i...@lists.sugarlabs.org; OLPC Devel devel@lists.laptop.org; John Gilmore g...@toad.com Sent: Fri, May 20, 2011 5:51:08 PM Subject: Re: [IAEP] Turtles All The Way Out On Fri, May 20, 2011 3:11 pm, Walter Bender wrote: On Fri, May 20, 2011 at 2:28 PM, John Gilmore g...@toad.com wrote: Recently, I finished my dissertation on mobile development directly from mobile devices. Something like this might've been very useful, although I did target experienced developers, not beginners. When we get to wearables with glasses-mounted full-sized display devices and one-hand chord keyboards, absolutely. Or when soft keyboards on multitouch tablets are totally reliable. Mobile development would work great on mobile devices like the XO-1, XO-1.5, XO-1.75, and perhaps even the XO-3, if only we'd teach the kids a few simple paradigms like files, hierarchical file systems and text editors. See Introduction to the Command Line http://booki.flossmanuals.net/command-line/edit/ of which I am a co-author. I don't know where you get the idea that files, hierarchical file systems, and text editors are simple concepts. I would be willing to discuss introducing the Linux file system in middle school, but our issue is programming for third-graders, or even earlier. Preschoolers can grasp the ideas behind turtle art by acting the part of the turtle. Where would you have them begin? Sugar comes with a plain-text editor (written by a 14-year-old, BTW) and files (and even a hierarchical file system) that has a data store as its primary interface. The problem with mobile development on mobile devices is not one of religion, it is about physical affordances: small screen and no (or inadequate) keyboard. (Efforts to teach computers to compile or interpret large programs that aren't written in collections of files are doomed to niche uselessness, though it sure makes a fun research/masturbation topic. Language, John, our discussion of child programming must be discussable with the children, their parents, and their parents' churches and political parties. The archive of this list is public information. I spent years paid to write big programs in APL that way in the '70s -- those programs are all unportably dead today, and APL is a tiny niche.) I have an ISO/ANSI standard APL that occupies 29K, thus originally giving a 32K workspace on 8-bit computers with 64K memory. It could easily be expanded to run with any amount of memory. Ken Iverson successfully used IBM APL\360 to teach first-grade arithmetic on a 360 with Selectric terminals. I also have books on math and other subjects in APL, from arithmetic to calculus, cryptography, and computer design. These are not hard concepts. Kids learn them daily, but not from XOs. Kids of what age? Since OLPC can't seem to be dissuaded from this fundamental error, because it isn't one, the question for me is whether it can be influenced to minimize the amount of learning that kids go through which is unique to this useless programming model. The point is to maximize learning in minimum time or with minimum effort. There *is* usefulness in teaching kids how to write tiny programs that can never scale up to useful, portable, supportable programs. But once they get the basic concepts, they should be transitioned to industry best worst, actually (Did you ever hear of the programmer who claimed to have 20 years experience in COBOL, but it turned out he had two years experience repeated 10 times?) No industry has ever embraced best practices. practices pretty quickly, writing a real Hello World So Hello World in Turtle Art is unreal? Here is a complete APL Hello, World. program, with its output. 'Hello, World.' Hello, World. and a complete Turtle Art version PrintTextVariable Hello, World. which the activity will be happy to convert to Logo. Next you put a Python function call on a single block to print the text, and away you go. and then evolving it to be more useful. Precisely. I prefer to teach not only programming but computer science concepts in the early years. One of the great advantages of Turtle Art is that there is no parsing step to translate from linear text with bizarre punctuation rules to a tree structure. The children program directly in effectively preparsed tree structures, with no syntactic sugar, as the LISPers call it. Also, Walter has built stack primitives into Turtle Blocks, so we can teach stack discipline and the rudiments of FORTH in Turtle Art. He recently added a block to read the color at the turtle's location. I had mentioned to him some time ago that that was the only function missing for me to write
