FYI: PataPata postmortem link
Just as an FYI, as a way to wind up the PataPata project (or at least one phase of it), I wrote a lengthy postmortem critique of the PataPata project to date, plus ideas for where to go from here. You can read the critique by following this link: "PataPata critique: the good, the bad, the ugly" http://sourceforge.net/mailarchive/forum.php?thread_id=31111569&forum_id=48729 Comments welcome. For reference, the PataPata project is/was """an experiment to support educational constructivism on the Python platform, inspired by "Squeak" and "Self", but going beyond those in a Pythonic way.""" From the introduction: """It's been about three months from my last post to the PataPata list as well as my last major change to the system. I have been thinking about the system in the intervening time, and feel ready to produce a critique of it as an experiment (sort of as a, sadly, "postmortem" report). Others are welcome to chime in. This critique covers various good, bad, and ugly results from this experiment, and then outlines some thoughts on where to go next. This note marks the end of this phase of the PataPata experiment. I am uncertain if this project on SourceForge will see more development, but I am certain if there is more development on this particular SourceForge project, it will likely be in a radically different direction than the work published here to date. """ === By the way, my decision to write a critique of PataPata was inspired in part by this paper by Drew McDermott, "Artificial Intelligence meets Natural Stupidity". http://portal.acm.org/citation.cfm?id=1045340 [fee based link] The core of the paper is here: http://www.everything2.com/index.pl?node_id=1406540 From there: "McDermott explains how all research should be based on actual implementations, and be a thorough report on them. What is needed is a very clear picture of what was tried, what worked, what didn't, why didn't that work. And there must be a working program that later researchers can play with. Later research can build on these partial solutions, and report the exact improvements made since the previous version, the improvement in performance, etc. As McDermott states: The standard for such research should be a partial success, but AI as a field is starving for a few carefully documented failures. Anyone can think of several theses that could be improved stylistically and substantively by being rephrased as reports on failures. I can learn more by just being told why a technique won't work than by being made to read between the lines." Thanks again to people here for your previous feedback on the project. --Paul Fernhout
The email message referenced in the PataPata SourceForge email archive I linked to is somehow cut off about two-thirds of the way through. Here is a link to a complete version I just put up on the web site. Sorry about any inconvenience. PataPata critique: the good, the bad, the ugly http://patapata.sourceforge.net/critique.html --Paul Fernhout Paul D. Fernhout wrote:
Just as an FYI, as a way to wind up the PataPata project (or at least one phase of it), I wrote a lengthy postmortem critique of the PataPata project to date, plus ideas for where to go from here. You can read the critique by following this link:
"PataPata critique: the good, the bad, the ugly" http://sourceforge.net/mailarchive/forum.php?thread_id=31111569&forum_id=48729
Comments welcome.
Paul D. Fernhout wrote:
For reference, the PataPata project is/was """an experiment to support educational constructivism on the Python platform, inspired by "Squeak" and "Self", but going beyond those in a Pythonic way."""
Was PataPata an experiment in education or an experiment in technology?? My own reaction was a strong desire to take it apart to see what made it tick, but little interest in using it as intended - or said better, its intent was never clear to me. Certainly not its *educational* intent.. Nothing about that is made clearer by reading your self-critique. I think that the real introspection that is necessary in order for you to better apply your technical expertise to the matter of education would be in regard to some of the underlying assumption you are making about "educational constructivism", particularly as that relates to the use of technology, and more particularly as it relates to use of the GUI.. IOW, I think the real issues are at the level of your axioms, not your implementation Sure there is a strong school-of-thought that would support your axioms. What that school-of-thought seems to rally around, it sometimes seems to me, is hostility to the notion that devotion to these axioms needs to re-examined every few decades. That is the self-critique I would like to be reading, anyway. Art
Arthur- Fair enough criticism of the critique, and thanks for the perspective. You made a very good point I will need to meditate on. Thank you. Sadly, nothing about PataPata experiment really progressed far enough in terms of a user base to, in even just an "action research" experimental way, even begin to resolve the issue you raise. I'll have to muse on how one would even begin to construct an experiment to evaluate this axiom. --Paul Fernhout Arthur wrote:
Paul D. Fernhout wrote:
For reference, the PataPata project is/was """an experiment to support educational constructivism on the Python platform, inspired by "Squeak" and "Self", but going beyond those in a Pythonic way."""
Was PataPata an experiment in education or an experiment in technology??
My own reaction was a strong desire to take it apart to see what made it tick, but little interest in using it as intended - or said better, its intent was never clear to me. Certainly not its *educational* intent..
Nothing about that is made clearer by reading your self-critique.
I think that the real introspection that is necessary in order for you to better apply your technical expertise to the matter of education would be in regard to some of the underlying assumption you are making about "educational constructivism", particularly as that relates to the use of technology, and more particularly as it relates to use of the GUI..
IOW, I think the real issues are at the level of your axioms, not your implementation
Sure there is a strong school-of-thought that would support your axioms. What that school-of-thought seems to rally around, it sometimes seems to me, is hostility to the notion that devotion to these axioms needs to re-examined every few decades.
That is the self-critique I would like to be reading, anyway.
Art
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Paul D. Fernhout wrote:
Just as an FYI, as a way to wind up the PataPata project (or at least one phase of it), I wrote a lengthy postmortem critique of the PataPata project to date, plus ideas for where to go from here. You can read the critique by following this link:
"PataPata critique: the good, the bad, the ugly" http://sourceforge.net/mailarchive/forum.php?thread_id=31111569&forum_id=48729
Comments welcome.
Thanks for putting this together; it's useful to know how this went, as it was a fairly ambitious rethinking of Python development. There's some similar issues being considered for OLPC. Specifically the laptop has a "view source" key, which (unsurprisingly) lets you view the source of what you are doing. What that means is application (aka "Activity") specific, but a general Python solution is called for. Of course it's a little hard to say what that actually should be. Just a text editor? Not too exciting. Really there should be a view of the process. And some way to manipulate the in-process objects and source. One thing I was unsure of -- and I think your postmortem confirmed -- is whether it's really feasible to generally edit objects in-process in a persistent way. I'm inclined not to go so far, perhaps simply relying on UI hints to indicate when the change is likely to be persistent. It's fairly easy to edit a function definition persistently, for instance, or add a function definition. You can still explore and poke around in the process any way you want, but you don't have complete power. Of course, at some point you need complete power, which means editing the source in ways that can only be meaningful when you restart the process from scratch. I'm not sure how or where to make that break. OTOH, emphasizing clean/fast/easy restarts might be more general and easier to implement than in-process persistent editing. I'm also not sure what to build on, or what to use. It's interesting that you felt out-of-process interaction was successful. This fits with my own intuition that in-process stuff can be dangerous and fragile. But I'm not that familiar with the details of how the interprocess communication should happen; perhaps IDLE is a good place to start looking. Perhaps IDLE is a good place to start the development? I don't believe Tk will be available on the laptops, only GTK, and probably not wx either, so that limits the possibility of reusing most UI, though other bits of code might be fine. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
Hi, On Nov 27, 2006, at 10:14 AM, Ian Bicking wrote:
There's some similar issues being considered for OLPC. Specifically the laptop has a "view source" key, which (unsurprisingly) lets you view the source of what you are doing. What that means is application (aka "Activity") specific, but a general Python solution is called for.
Of course it's a little hard to say what that actually should be. Just a text editor? Not too exciting. Really there should be a view of the process. And some way to manipulate the in-process objects and source. One thing I was unsure of -- and I think your postmortem confirmed -- is whether it's really feasible to generally edit objects in- process in a persistent way. I'm inclined not to go so far, perhaps simply relying on UI hints to indicate when the change is likely to be persistent. It's fairly easy to edit a function definition persistently, for instance, or add a function definition. You can still explore and poke around in the process any way you want, but you don't have complete power.
Sounds a lot like a LISP Machine.... Have you looked into those for UI ideas? --- Rob Malouf <rmalouf@mail.sdsu.edu> Department of Linguistics and Asian/Middle Eastern Languages San Diego State University
Ian- Thanks for the comment. I think the issue you raise is a really difficult one to resolve. If I understand the general issue correctly, when you are looking at a GUI interface with underlying processes, and a person wants to "see the code", the question is what to show them, and also whether to show it to them in such a way as they can modify either what they see right then, or what they might see if the restarted the program. One thing I had sometimes dreamed about is mapping every pixel on the screen with a programming or debugging equivalent of a "Z-Buffer". But in this, call it perhaps an "S-Buffer", instead of storing Z-depth from a pixel on a polygon, you could associate a stack trace with every pixel from the process that last wrote to that pixel (you might even store the stacks of everyone who wrote to that pixel). So, in that way you would have a somewhere logical to begin to explore the system related to constructing each aspect of the current view. If you see a button on a screen, mouse over to it, hit a key, and immediately you are in the debugger with a stack trace related to the code that drew the button, which presumably would link to the button itself. You would need pretty much the entire stack since otherwise you would just end up with references to the polygon drawing routines. :-) Possibly not feasible with today's technology though -- you might need several K per pixel at least, and with a megapixel display, that might mean gigabytes just for that storage. Might be possible in a few years though. Or might be feasible sooner for beginners if you restricted the window to, say, a 200 X 200 size, or if you could do something clever related to not storing independent copies of each stack trace, since whole areas of pixels would likely be drawn by essentially the same common routines with the same underlying stack. Perhaps, considering that overlap, if you skipped the last one or two specific frames on the stack, you might be able to store such a "S-Buffer" with little more than an extra 10 megabytes or so for 32 bit pointer for each pixel of a megabit display, plus maybe just a few megabytes for the really relevant stack? Something someone in academia might want to explore, perhaps as a student project, possibly. Of course, if you really wanted to do it right, you should save the state of the virtual machine in it's entirety when writing each pixel. So that is probably a few megabytes at least per pixel, or probably a few terabytes per display. Now I now what I'll be doing with all that memory the computer I buy in 2020 will have; storing a million similar copies off the same virtual machine. :-) Again though, with clever ideas like compression, storing checkpoints (like OCaml does) or using other approaches to VM design (the Pointrel System I wrote has a data storage approach in some versions which only adds data, never changes or erases it), it might be possible to reduce the memory demand for such a "complete VM state saving S-Buffer" down to only dozens or hundreds of megabytes per display, which is within reach even now. Even if this worked, you might still find exploring the system awkward if the system created objects in one place, but displayed them at another time in a refresh, as most systems do. You would still need then to work backward to figure out how the particular object on the screen got initialized. So maybe all you really need that is ultimately useful is an association of a graphical object doing th drawing with each pixel on the screen? And essentially, that is what PataPata does (and many other drawing-composition-oriented programs as well); it maps from a pixel on the screen back to a GUI widget, and then presents that widget in a browser. Anyway, I think perhaps there are some genral ideas to explore here. Whether changes to anything you explored by picking a pixel from the screen were useful to modifying what you saw right then and there would have a lot to do with the underlying programming model. In the case of conventional Python GUIs, where you have a builder method that assembles all the widgets, it would really take a restart of the GUI (or at least the modified window) to map back from source to display. And any changes just made to widgets would not likely be easily saved with that model -- unless you pursued writing out object to source in some fashion similar to what PataPata tried. The notion of a Smalltalk image (a saved binary file representing the current state of a world of object) seems a much easier approach to support this kind of dynamic interface redesign, and I think that is one of the reasons I feel more productive programming GUIs in Smalltalk than Python; I rarely have to restart a complex Smalltalk application the way I often have to do with Python ones (unless you use various tricks, some of which I have posted on before to the Jython list). While I did end up doing things "out of process" a lot in terms of editing the source file as text, I think the reasons I did it on further reflection could have had more to do with my confidence about the system then anything else. I was often making changes to key GUI components or other core implementation things (including file writing). If I was working as a "user" level instead of a "maintainer" level, I think the "in process" editing of windows using the hierarchical browser might have been a lot more satisfactory and appealing. But that remains speculation; still I think when I used the inspector to change things, I probably was thinking more like I was testing the system from a "user" standpoint. Of course, the whole point of something like PataPata is to blur the line of "user" and "maintainer", so the issue is never that simple. Thanks again for your conceptual help with key ideas in the project like using metaclasses to build prototypes; that part of going from source to prototypes I was very pleased with. :-) --Paul Fernhout Ian Bicking wrote:
Paul D. Fernhout wrote:
Just as an FYI, as a way to wind up the PataPata project (or at least one phase of it), I wrote a lengthy postmortem critique of the PataPata project to date, plus ideas for where to go from here. You can read the critique by following this link:
"PataPata critique: the good, the bad, the ugly" http://sourceforge.net/mailarchive/forum.php?thread_id=31111569&forum_id=48729
Comments welcome.
Thanks for putting this together; it's useful to know how this went, as it was a fairly ambitious rethinking of Python development.
There's some similar issues being considered for OLPC. Specifically the laptop has a "view source" key, which (unsurprisingly) lets you view the source of what you are doing. What that means is application (aka "Activity") specific, but a general Python solution is called for.
Of course it's a little hard to say what that actually should be. Just a text editor? Not too exciting. Really there should be a view of the process. And some way to manipulate the in-process objects and source. One thing I was unsure of -- and I think your postmortem confirmed -- is whether it's really feasible to generally edit objects in-process in a persistent way. I'm inclined not to go so far, perhaps simply relying on UI hints to indicate when the change is likely to be persistent. It's fairly easy to edit a function definition persistently, for instance, or add a function definition. You can still explore and poke around in the process any way you want, but you don't have complete power.
Of course, at some point you need complete power, which means editing the source in ways that can only be meaningful when you restart the process from scratch. I'm not sure how or where to make that break. OTOH, emphasizing clean/fast/easy restarts might be more general and easier to implement than in-process persistent editing.
I'm also not sure what to build on, or what to use. It's interesting that you felt out-of-process interaction was successful. This fits with my own intuition that in-process stuff can be dangerous and fragile. But I'm not that familiar with the details of how the interprocess communication should happen; perhaps IDLE is a good place to start looking. Perhaps IDLE is a good place to start the development? I don't believe Tk will be available on the laptops, only GTK, and probably not wx either, so that limits the possibility of reusing most UI, though other bits of code might be fine.
Paul D. Fernhout wrote:
Ian-
Thanks for the comment.
I think the issue you raise is a really difficult one to resolve. If I understand the general issue correctly, when you are looking at a GUI interface with underlying processes, and a person wants to "see the code", the question is what to show them, and also whether to show it to them in such a way as they can modify either what they see right then, or what they might see if the restarted the program.
One thing I had sometimes dreamed about is mapping every pixel on the screen with a programming or debugging equivalent of a "Z-Buffer". But in this, call it perhaps an "S-Buffer", instead of storing Z-depth from a pixel on a polygon, you could associate a stack trace with every pixel from the process that last wrote to that pixel (you might even store the stacks of everyone who wrote to that pixel).
Of course that takes a lot of space, and OLPC is a considerable step backwards in terms of resources. With 128Mb of RAM (and not really any feasible swap) we have to be very conservative. This also can't have any overhead if a child isn't using it. My initial thought was more like a "view source" that showed the "main" file -- which might be automatically detectable, or maybe we'd just have the activity declare what its main file is. Then you could essentially enter a stepped mode, where the next event would be captured and you'd see execution at that point. OTOH, a "mouse-in" event is often pretty boring, so there might be different kinds of events you can catch. Also, we can just look at events until we see one that actually points to Python code (with the assumption that all C code is totally opaque -- which in practice it is). That will help you see why the program acts like it does, but not how it got to be how it is. Simple/safe restarting might make that even more complicated -- if we try to get activities to safely shut down and restart without losing state or information, then a lot of state is going to essentially appear from nowhere (like from a pickle). And that state might be "corrupt" in some fashion, if you are preserving buggy state, or you are preserving state with no longer matches the code (if you are restarting to see edits). Ugh; I hate persistence. OK, so now I realize we need to think about simple ad hoc persistence. And that persistence has to be transparent, otherwise it's not possible to debug or handle upgrades. Well, there should always be an option to ditch anything that has persisted and start from scratch. Sigh... this opens up enough issues that I have to think about it some more. Serialization is going to be a big deal. Oh, but in conclusion -- restarting with saved sessions makes it even harder to figure out why the state (and UI) gets set up the way it does, and it wasn't easy to begin with. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
Ian- Yep, that sounds about right to me -- I like how you phrase "That will help you see why the program acts like it does, but not how it got to be how it is.". And that is why modifying complex systems like event driven GUIs of significant size is non-trivial, and involves using some analogue of all the Smalltalk-inspired tools of Inspector, Browser, Debugger, and Workspace, no matter how much we how some great tool could make it easier, or how approachable we try to make the experience for beginners. There is a lot going on under the hood of a modern application (or in its support libraries at least) and making it easier to understand in detail might require an entire paradigm shift (perhaps functional programming or even logical AI programming?). --Paul Fernhout Ian Bicking wrote:
Paul D. Fernhout wrote:
Ian-
Thanks for the comment.
I think the issue you raise is a really difficult one to resolve. If I understand the general issue correctly, when you are looking at a GUI interface with underlying processes, and a person wants to "see the code", the question is what to show them, and also whether to show it to them in such a way as they can modify either what they see right then, or what they might see if the restarted the program.
One thing I had sometimes dreamed about is mapping every pixel on the screen with a programming or debugging equivalent of a "Z-Buffer". But in this, call it perhaps an "S-Buffer", instead of storing Z-depth from a pixel on a polygon, you could associate a stack trace with every pixel from the process that last wrote to that pixel (you might even store the stacks of everyone who wrote to that pixel).
Of course that takes a lot of space, and OLPC is a considerable step backwards in terms of resources. With 128Mb of RAM (and not really any feasible swap) we have to be very conservative. This also can't have any overhead if a child isn't using it.
My initial thought was more like a "view source" that showed the "main" file -- which might be automatically detectable, or maybe we'd just have the activity declare what its main file is. Then you could essentially enter a stepped mode, where the next event would be captured and you'd see execution at that point. OTOH, a "mouse-in" event is often pretty boring, so there might be different kinds of events you can catch. Also, we can just look at events until we see one that actually points to Python code (with the assumption that all C code is totally opaque -- which in practice it is).
That will help you see why the program acts like it does, but not how it got to be how it is. Simple/safe restarting might make that even more complicated -- if we try to get activities to safely shut down and restart without losing state or information, then a lot of state is going to essentially appear from nowhere (like from a pickle). And that state might be "corrupt" in some fashion, if you are preserving buggy state, or you are preserving state with no longer matches the code (if you are restarting to see edits). Ugh; I hate persistence.
OK, so now I realize we need to think about simple ad hoc persistence. And that persistence has to be transparent, otherwise it's not possible to debug or handle upgrades. Well, there should always be an option to ditch anything that has persisted and start from scratch.
Sigh... this opens up enough issues that I have to think about it some more. Serialization is going to be a big deal. Oh, but in conclusion -- restarting with saved sessions makes it even harder to figure out why the state (and UI) gets set up the way it does, and it wasn't easy to begin with.
Ian Bicking wrote:
Of course that takes a lot of space, and OLPC is a considerable step backwards in terms of resources. With 128Mb of RAM (and not really any feasible swap) we have to be very conservative. This also can't have any overhead if a child isn't using it.
Sure is difficult for us tech mortals to understand where these issues intersect with the intent of OLPC. As a point of real-world reference, I have communicated a bit with my son - working now in the South Pacific equivalent of the bush, for the U.S. Peace Corps - about OLPC, i.e. the availablility of inexpensive laptops that can used in an environment without ready access to electicity. He tells me books are difficult to access, and that he could see it as a great advantage to be able to retrieve and distribute books and other text information electronically. Sounds logical, and the kind of thing I would expect OLPC to be focusing upon. What are we talking about here? I know, why be nasty..... but I smell a generally decent idea being hijacked by the absolutely unproven - as in the only proof that does exist is in the negataive - radical electronic constructivists. And I suspect the influence of my usual suspects (suspect) is at the root. Too bad, really. I have "oops" consistently here lately, and am certainly as oops prone as anyone else, at least. If I am oopings here again, i apologize in advance. But I also get it right often enough, going by smell. Art
My initial thought was more like a "view source" that showed the "main" file -- which might be automatically detectable, or maybe we'd just have the activity declare what its main file is. Then you could essentially enter a stepped mode, where the next event would be captured and you'd see execution at that point. OTOH, a "mouse-in" event is often pretty boring, so there might be different kinds of events you can catch. Also, we can just look at events until we see one that actually points to Python code (with the assumption that all C code is totally opaque -- which in practice it is).
That will help you see why the program acts like it does, but not how it got to be how it is. Simple/safe restarting might make that even more complicated -- if we try to get activities to safely shut down and restart without losing state or information, then a lot of state is going to essentially appear from nowhere (like from a pickle). And that state might be "corrupt" in some fashion, if you are preserving buggy state, or you are preserving state with no longer matches the code (if you are restarting to see edits). Ugh; I hate persistence.
OK, so now I realize we need to think about simple ad hoc persistence. And that persistence has to be transparent, otherwise it's not possible to debug or handle upgrades. Well, there should always be an option to ditch anything that has persisted and start from scratch.
Sigh... this opens up enough issues that I have to think about it some more. Serialization is going to be a big deal. Oh, but in conclusion -- restarting with saved sessions makes it even harder to figure out why the state (and UI) gets set up the way it does, and it wasn't easy to begin with.
Arthur wrote:
What are we talking about here?
I know, why be nasty.....
Certainly not intending to insult Ian, whose reputation as a leader in the Python community has been earned form the ground up, by Good Works, in the best tradition of an Open source community.... And maybe I simply *don't* understand.... But.... reading the lines, and between the lines, I fear not only that OLPC is turning into a toy, but a toy for the wrong follks, folks who have enough toys, rooms full of them, lost in their toys, blinking and whizzing hynoptic. Art
On Nov 29, 2006, at 13:00 , Arthur wrote:
I fear not only that OLPC is turning into a toy, but a toy for the wrong follks, folks who have enough toys, rooms full of them, lost in their toys, blinking and whizzing hynoptic.
Would you agree that the software (and not the greenish toy-like hardware) would make all the difference between that little machine being a toy and it being a serious platform for education? Why, then, are so few folks working on actual educational software for it? So far, you can count the specifically educational activities on the OLPC on one hand. Even if you lost most fingers. - Bert -
Bert Freudenberg wrote:
On Nov 29, 2006, at 13:00 , Arthur wrote:
I fear not only that OLPC is turning into a toy, but a toy for the wrong follks, folks who have enough toys, rooms full of them, lost in their toys, blinking and whizzing hynoptic.
Would you agree that the software (and not the greenish toy-like hardware) would make all the difference between that little machine being a toy and it being a serious platform for education? Why, then, are so few folks working on actual educational software for it? So far, you can count the specifically educational activities on the OLPC on one hand. Even if you lost most fingers.
- Bert -
Not sure what are saying. Just checked my facts: Squeak, and Scratch on top of Squeak seemed to be the done deal centerpieces. You wouldn't be implying - God forbid - that this is not state of the art, best practices, educational software. There is a team, and that team has a point of view: """ Educational Software The responsibilities of this group include selecting suitable educational software, (with an understanding of memory consumption of the software). Ebook and book authoring technology belongs here. Other issues include teacher preparation, migration of exisiting content, a framework for new content development, school-server technologies, a "Kids Corps" for maintenance. /Who:/ Walter Bender, David Cavallo, Seymour Papert <http://wiki.laptop.org/go/Seymour_Papert>, Brian Smith, Alan Kay <http://wiki.laptop.org/go/Alan_Kay>, K12LTSP(?), Mitchel Resnick, Roseli de Deus Lopes There is also a need for basic tools for programming and authoring. LOGO <http://wiki.laptop.org/go/LOGO>, OpenOffice, Dia, TuxPaint, etc. all should be considered. However, let's keep in mind that there is a difference between Edutainment and and Playful Learning. And we want Playful Learning instead of Edutainment <http://www.media.mit.edu/%7Emres/papers/edutainment.pdf>. Also, we don't want kids to be punished by rewards <http://www.alfiekohn.org/teaching/pbracwak.htm>. Some understanding of constructionist <http://wiki.laptop.org/go/Constructionist> educational philosophy will be useful for developers. """ I don't argue the merits of constructivitist educational philosophy. And I don't like punishment, much less punishment by rewards. Just that I see these matters as having next to nothing to do with electronics. More than nothing to do with electronics. That the Wizards think they can construct this reality electronically is not only absurd, in my view, but an absolute - almost tragic - distraction from more coherent and human to human based efforts toward these espoused ends. Which I might see in the end to have maybe a 4% electronic component. I guess as I grow up I am less and less impressed by the expression of good intentions. Great intentions tend to have great effects almost exclusively in the hands of less than great egos - is what life experience seems have informed me. Not sure those kind of folks are well represented by the team assembled here. Certainly, they would not be noticed, or have influence if they were. Its all just more of the same. The non-electronic component, beating the best of intentions. Other than what Alan Kay, and his posse, says he has accomplished in the field of education, what has Alan Kay demostrably accomplished in the field of education. How many days has he spent in a classroom? He has gotten to the top of a field he has never even entered. Gotten there electronically. True wizardry, to be sure. This team is quite silly, when you look at it, deconstructed from my perspective at least. Art .
On Nov 29, 2006, at 14:39 , Arthur wrote:
Bert Freudenberg wrote:
On Nov 29, 2006, at 13:00 , Arthur wrote:
I fear not only that OLPC is turning into a toy, but a toy for the
wrong follks, folks who have enough toys, rooms full of them, lost in their toys, blinking and whizzing hynoptic.
Would you agree that the software (and not the greenish toy-like hardware) would make all the difference between that little machine being a toy and it being a serious platform for education? Why, then, are so few folks working on actual educational software for it? So far, you can count the specifically educational activities on the OLPC on one hand. Even if you lost most fingers.
- Bert -
Not sure what are saying. Just checked my facts:
Squeak, and Scratch on top of Squeak seemed to be the done deal centerpieces.
Squeak (actually, Etoys) is there, and it is indeed the only educational activity I can see at the moment. Which prompted my message - I can imagine a lot of people with different ideas, but why are they so silent? Why don't they create a project on dev.laptop.org and start hacking? You surely would not want to leave the territory to us Etoys folks, would you? Haven't heard of Scratch being on the machine, there certainly is no specific OLPC Scratch activity, yet.
You wouldn't be implying - God forbid - that this is not state of the art, best practices, educational software.
I was implying that this is edu-sig, and since Python is on the laptop (actually as the major language, which is *not* Squeak), why isn't there anyone else contributing? It's not like OLPC was a closed project. At the current state of affairs you could get *anything* onto it. So are you dismissing the whole idea just because the lauded head honchos are constructionists? Contribute your own!
Just that I see these matters as having next to nothing to do with electronics. More than nothing to do with electronics.
Granted. Still, you are an electronic mailing list discussing educational topics as applied to an electronic device - the idea does not seem too far-fetched to me.
That the Wizards think they can construct this reality electronically is not only absurd, in my view, but an absolute - almost tragic - distraction from more coherent and human to human based efforts toward these espoused ends. Which I might see in the end to have maybe a 4% electronic component.
Whatever human-to-human based efforts you (or anyone) are pursuing, by all means, continue. As has been pointed out elsewhere, this is not a zero-sum game. Virtually nobody involved in the OLPC project would instead be going to Brazil and become a teacher. So why not let everyone do what they do best, and enjoy doing? - Bert -
On 11/29/06, Bert Freudenberg <bert@freudenbergs.de> wrote:
On Nov 29, 2006, at 13:00 , Arthur wrote:
I fear not only that OLPC is turning into a toy, but a toy for the wrong follks, folks who have enough toys, rooms full of them, lost in their toys, blinking and whizzing hynoptic.
Would you agree that the software (and not the greenish toy-like hardware) would make all the difference between that little machine being a toy and it being a serious platform for education? Why, then, are so few folks working on actual educational software for it? So far, you can count the specifically educational activities on the OLPC on one hand. Even if you lost most fingers.
I would point out that writing educational software for people who don't have computers isn't very useful either, and that once kids have computers (on a common, free platform) there's a lot more incentive to write educational software for them. --Tom
On Nov 29, 2006, at 16:06 , Tom Hoffman wrote:
On 11/29/06, Bert Freudenberg <bert@freudenbergs.de> wrote:
On Nov 29, 2006, at 13:00 , Arthur wrote:
I fear not only that OLPC is turning into a toy, but a toy for the wrong follks, folks who have enough toys, rooms full of them, lost in their toys, blinking and whizzing hynoptic.
Would you agree that the software (and not the greenish toy-like hardware) would make all the difference between that little machine being a toy and it being a serious platform for education? Why, then, are so few folks working on actual educational software for it? So far, you can count the specifically educational activities on the OLPC on one hand. Even if you lost most fingers.
I would point out that writing educational software for people who don't have computers isn't very useful either, and that once kids have computers (on a common, free platform) there's a lot more incentive to write educational software for them.
Exactly my reasoning - OLPC is going to be a common, free platform, so it should be plenty of incentive. Yet, little is happening. - Bert -
Bert Freudenberg wrote:
On Nov 29, 2006, at 16:06 , Tom Hoffman wrote:
I would point out that writing educational software for people who don't have computers isn't very useful either, and that once kids have computers (on a common, free platform) there's a lot more incentive to write educational software for them.
Exactly my reasoning - OLPC is going to be a common, free platform, so it should be plenty of incentive. Yet, little is happening.
Two points: One from Paul Fernhout, who just spent months on trying to make something happen: 1) """ Over the years, what I have discovered about "educational software" is that most of it is junk, and the really useful things to connect kids with are the open-ended packages which provide an avenue for their creativity and sense of mastery over aspects of the real or digital world -- so, for example, learning to write with a word processor is much better than playing some silly flash-words game, and using Photoshop or the GIMP is probably much better than using some silly math-blaster game or even the award winning Oregon Trail (which is pretty good as those things go). """ 2) What is happening is what is happening. And if the platform is indeed open enough, the official OLPC hierarchy is not relevenat. What belongs on the machines will find its way onto the machines. The best thing that the hierarchy can do is leave enough room. If I were going to contribute, I am all for help in an understanding of the memory constraints in which I need to work. My philosophy of rewards and punishment is nobody's business. I am not a child. Art
On Nov 29, 2006, at 10:41 AM, Arthur wrote:
Over the years, what I have discovered about "educational software" is that most of it is junk, and the really useful things to connect kids with are the open-ended packages which provide an avenue for their creativity and sense of mastery over aspects of the real or digital world -- so, for example, learning to write with a word processor is much better than playing some silly flash-words game, and using Photoshop or the GIMP is probably much better than using some silly math-blaster game or even the award winning Oregon Trail (which is pretty good as those things go). """
I definitely have to agree with Arthur on this point. I'm working on some "educational software" at the moment, but it's really a simple development environment for people learning Python. I.e. an open- ended tool, not a product that teaches. I've been pondering the question of what is good educational software full time for half a dozen years now, and I still don't know how to answer it. Furthermore, Bert's question about why aren't people writing for OLPC right now when it is open software, I might ask the same about my tools, which are freely available with an MIT license at http:// stratotools.python-hosting.com. I'm giving it away for free, why isn't anybody using it? But that's not a fair question. There's so much free stuff out there now, it is really up to the developer to sell their platform. But I presume your question was rhetorical, and for the purpose of selling your platform? -Winston ______________________________________________________________ Stratolab - http://www.stratolab.com - (646) 827-2242 learning by creating - video game courses for kids in new york
Winston Wolff wrote:
On Nov 29, 2006, at 10:41 AM, Arthur wrote:
Over the years, what I have discovered about "educational software" is that most of it is junk, and the really useful things to connect kids with are the open-ended packages which provide an avenue for their creativity and sense of mastery over aspects of the real or digital world -- so, for example, learning to write with a word processor is much better than playing some silly flash-words game, and using Photoshop or the GIMP is probably much better than using some silly math-blaster game or even the award winning Oregon Trail (which is pretty good as those things go). """
I definitely have to agree with Arthur on this point.
Hi Winston - Nice to hear from someone with whom I would enjoy having lunch, and did ;) For the record I was simply quoting Paul Fernhout. Who is a Smalltalker (is it OK to say that, Paul?), working in the area of "educational software" for a lot longer, and with a lot more technical sophistication under his belt than have I. You can tell it ain't me writing. He spells well ;) Art
Winston Wolff wrote:
There's so much free stuff out there now, it is really up to the developer to sell their platform. But I presume your question was rhetorical, and for the purpose of selling your platform?
The market seems to respond best, at the moment, to audacity. Having met you, I think you are at disadvantage. Not your style. Hopefully, it's just a matter of time before that changes. (boy, I said that a lot more politely than I feel) Art.
On Dec 3, 2006, at 20:34 , Winston Wolff wrote:
On Nov 29, 2006, at 10:41 AM, Arthur wrote:
Over the years, what I have discovered about "educational software" is that most of it is junk, and the really useful things to connect kids with are the open-ended packages which provide an avenue for their creativity and sense of mastery over aspects of the real or digital world -- so, for example, learning to write with a word processor is much better than playing some silly flash-words game, and using Photoshop or the GIMP is probably much better than using some silly math-blaster game or even the award winning Oregon Trail (which is pretty good as those things go). """
I definitely have to agree with Arthur on this point. I'm working on some "educational software" at the moment, but it's really a simple development environment for people learning Python. I.e. an open-ended tool, not a product that teaches. I've been pondering the question of what is good educational software full time for half a dozen years now, and I still don't know how to answer it.
I think Paul (quoted by Arthur above) touched a really good point. Most so-called "educational" (or worse, "edutainment") software is stupid to a degree that one might consider harmful. Tools that can be used creatively are much more important. And although programming is creative by definition and should definitely be possible on the OLPC laptop, I think learning to program is not the most important creative activity, there could be a lot more. For example, the ebook- reader is going to be a wiki, allowing to annotate and discuss books. Also, a wiki-like journal is at the core of the user model.
Furthermore, Bert's question about why aren't people writing for OLPC right now when it is open software, I might ask the same about my tools, which are freely available with an MIT license at http:// stratotools.python-hosting.com. I'm giving it away for free, why isn't anybody using it? But that's not a fair question. There's so much free stuff out there now, it is really up to the developer to sell their platform. But I presume your question was rhetorical, and for the purpose of selling your platform?
Not really, it was an honest question (and it's not "my" platform anyway, I am simply hacking in one of the OLPC projects). Free stuff being available does not quite suffice, it would have to be brought into a form fitting the target. But that should still be much less effort that writing completely new things. - Bert -
On 29-Nov-06, at 4:45 AM, Bert Freudenberg wrote:
Would you agree that the software (and not the greenish toy-like hardware) would make all the difference between that little machine being a toy and it being a serious platform for education? Why, then, are so few folks working on actual educational software for it? So far, you can count the specifically educational activities on the OLPC on one hand. Even if you lost most fingers.
I'd love to write software for the OLPC, but I don't have one available. The virtual version is distributed as a VMWare image, which is great as far as it goes. The VMWare player hasn't been ported to my computer yet (Mac Intel) and the image doesn't load in Parallels (the VM I use for running Windows for testing). I've signed up for the beta program with VMWare, but haven't heard back from them. So unless I want to spend several hundred dollars on a computer to run a simulation of the $100 laptop, I'm out of the running. I'm sure when the simulator (and the real thing) get into more hands you will start to see more software for it. --Dethe Young children play in a way that is strikingly similar to the way scientists work --Busytown News
On 11/30/06, Dethe Elza <delza@livingcode.org> wrote:
On 29-Nov-06, at 4:45 AM, Bert Freudenberg wrote:
I'd love to write software for the OLPC, but I don't have one available. The virtual version is distributed as a VMWare image, which is great as far as it goes. The VMWare player hasn't been ported to my computer yet (Mac Intel) and the image doesn't load in Parallels (the VM I use for running Windows for testing). I've signed up for the beta program with VMWare, but haven't heard back from them. So unless I want to spend several hundred dollars on a computer to run a simulation of the $100 laptop, I'm out of the running.
Actually, the OLPC provides a standard disk image you can use with qemu. I packaged one of those up last week as a vmware appliance and posted it to my blog, which has subsequently been downloaded an zillion times, since it suddenly made it easy for average Windows users to have a crack at it. So yeah, on one hand, you could say the OLPC folks could be doing a better job of marketing (like reaching out to those Windows users themselves), but on the other hand, the main criticism of the project is probably that it is all hype and marketing, so either way, they lose ;-). No matter how you slice it though, it does seem to be more tricky to get an emulator for it running on the Mac. qemu should work, albiet more slowly than Parallels. The main wiki page for OLPC emulation is here: http://wiki.laptop.org/go/OS_images_for_emulation --Tom
On 30-Nov-06, at 5:39 PM, Tom Hoffman wrote:
Actually, the OLPC provides a standard disk image you can use with qemu. I packaged one of those up last week as a vmware appliance and posted it to my blog, which has subsequently been downloaded an zillion times, since it suddenly made it easy for average Windows users to have a crack at it.
And OS X users too...
So yeah, on one hand, you could say the OLPC folks could be doing a better job of marketing (like reaching out to those Windows users themselves), but on the other hand, the main criticism of the project is probably that it is all hype and marketing, so either way, they lose ;-).
At least they're not in Kathy Sierra's "Zone of Mediocrity." As long as folks either love 'em or hate 'em, then chances are they're doing something important.
No matter how you slice it though, it does seem to be more tricky to get an emulator for it running on the Mac. qemu should work, albiet more slowly than Parallels.
Qool. I haven't looked into running other emulators in a while.
The main wiki page for OLPC emulation is here:
Alright. I didn't know about that. I had seen a blog post (maybe yours, can't remember off-hand) that linked to images for VMWare. But the page you link to above has instructions for getting it running under Parallels, so I'll see if I can't get that working. Thanks for the pointers! --Dethe "...coding isn't the poor handmaiden of design or analysis. Coding is where your fuzzy, comfortable ideas awaken in the harsh dawn of reality. It is where you learn what your computer can do. If you stop coding, you stop learning." Kent Beck, Smalltalk Best Practice Patterns
On Dec 1, 2006, at 3:23 , Dethe Elza wrote:
The main wiki page for OLPC emulation is here:
Alright. I didn't know about that. I had seen a blog post (maybe yours, can't remember off-hand) that linked to images for VMWare. But the page you link to above has instructions for getting it running under Parallels, so I'll see if I can't get that working.
Yes, I added those instructions (/me hugs his mac). But actually, those images are just for trying the official builds. Also, note that there is a bug so currently the images run at 640x480 (http://dev.laptop.org/ticket/504). For developing your own stuff, it's much easier to use "sugar- jhbuild" on a regular Linux machine (or Parallels install, as I do): http://wiki.laptop.org/go/Sugar If you have any problems getting started, it's best to hop by on IRC, #olpc and #sugar on irc.freenode.net. - Bert -
Arthur wrote:
As a point of real-world reference, I have communicated a bit with my son - working now in the South Pacific equivalent of the bush, for the U.S. Peace Corps - about OLPC, i.e. the availablility of inexpensive laptops that can used in an environment without ready access to electicity.
He tells me books are difficult to access, and that he could see it as a great advantage to be able to retrieve and distribute books and other text information electronically. Sounds logical, and the kind of thing I would expect OLPC to be focusing upon.
What are we talking about here?
I think availability of non-programming information on the laptop is really important too. But Arthur, this is the Python Edu-SIG, what do you expect me to write about here? -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
From: Ian Bicking
I think availability of non-programming information on the laptop is really important too. But Arthur, this is the Python Edu-SIG, what do you expect me to write about here?
Whatever you like. You've earned that. But in my way, and by my own assessment, so have I. Art
participants (9)
-
ajsiegelīŧ optonline.net -
Arthur
-
Bert Freudenberg -
Dethe Elza -
Ian Bicking -
Paul D. Fernhout -
Rob Malouf -
Tom Hoffman -
Winston Wolff