Re: [Edu-sig] Programming in High School
David MacQuigg wrote: What ever happened to the original enthusiasm with Computer Programming for Everyone? If everyone with a high school diploma knew how to write a simple program, not only would we be more productive, but we would understand the world better. Instead of loose talk and isolated numbers, the news would show us charts. The general public, not just experts, would have seen the very obvious bubble growing in the housing market, and could see now where we are on the down side. What if the average real estate agent could show me the price trends on property similar to what I am looking at. Instead, I have to dig out the data myself, and plot it in Excel. Then when I show her the result, she still doesn't see the significance. Many years ago someone said (probably Kirby, and probably on this list) essentially that while computing is taught in school as if it were a subset of schoolish math, it's really more true that schoolish math is a subset of computing. Obviously, real knock-your-socks-off math subsumes *everything*, as in physics is a subset of math in a way, but that is not the case either in most K-12 schools. And even then, the lines between computing and math are starting to blur, as even modern physicists now spend a lot of time with their computer simulations that their base equations. So, I feel from a practical point of view, computing should be introduced as early as possible in education (perhaps after, say age seven and kids get the real world at an intuitive level), and learning to do schoolish math (including algebra, trigonometry, logical proofs of correctness, and so on) should flow from that. And, for example, you can then link things like physics, chemistry, and biology (and even English and history) into a computer base curriculum using simulation and data acquisition. On the larger issue: David MacQuigg also wrote: At 06:52 PM 12/8/2008 -0800, Guido van Rossum wrote: On Mon, Dec 8, 2008 at 5:10 PM, David MacQuigg [EMAIL PROTECTED] wrote: At 03:30 PM 12/8/2008 -0800, michel paul wrote: I think part of the problem in the past has been the misunderstanding about tech jobs getting outsourced. I've heard people say there's no point in becoming a programmer, because all the jobs are going overseas. It's really kind of silly. Stated that way, it does seem circular. I've heard it stated more convincingly by an EE prof to a class of undergrads. If you go into engineering, you will be facing layoffs. Imagine the effect of that expectation on smart students who see their buddies going into law or medicine, and getting more pay and more respect than engineers. It's no wonder there are almost no US students in our graduate classes. I've thought about what I would have said to those students. It would be more like If money is your major motivation, find another profession. If technology is in your blood, stay with it. Learn everything you can. The money will come out OK. I read this as: Engineering is something where mediocrity doesn't pay. Doctors and lawyers are like cobblers, their output is limited by the number of hours they can work, so there is room for good solid workers who aren't particularly innovative. Engineering at its best is not like that at all. It's a field whose main *point* is to make manual labor redundant. Good engineers do their work because it's their passion. The rest... Well they can always try to earn a living cranking out Java code. ;-) I'm a bit uncomfortable with the idea that engineering is a field where only the brightest should feel comfortable. There is plenty of need for good solid workers, and I would like to see our schools and our economy support that. If we outsource the grunt work, and hope to keep just the top geniuses employed, eventually we lose the top also. I remember in the 80's thinking the Japanese could never catch up with us in circuit design. They just didn't have the creative spark. It wasn't in their culture. On this general topic of the cultural context of engineering education, here a few ideas about historical trends, and one speculation based on projecting things forward a couple decades from what Guido said elsewhere. After WWII, the USA was the only significant manufacturing power. Europe and much of Aisa were either in rubble, social turmoil, or both. The Southern hemisphere still had little infrastructure too. So, it could be expected that the manufacturing base in the USA would grow as it made stuff for the world, and like China today, this would be a good position to be in, having the world depending on it for stuff. But over the decades, this unusual situation has shifted, and while the USA still sells a lot of manufactured goods, as the world has rebuilt in some places and developed industrially in others, a more normal situation is reestablishing itself. Culturally, it is true that different places have different strengths and weaknesses,
Re: [Edu-sig] OLPC G1G1 sales start today
haven't noticed, like most people. In a message of Mon, 12 Nov 2007 18:48:33 EST, Paul D. Fernhout writes: Paul D. Fernhout wrote: And I really should not be using developed / developing as they are loaded terms (even though the OLPC project uses them too), since there is a lot the USA can learn from other countries, including poor ones, some of whom rank higher in overall happiness in various surveys -- here's a different one: http://worlddatabaseofhappiness.eur.nl/ ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] OLPC G1G1 sales start today
Michael Tobis wrote: I think this limited time only idea defeats the purpose of the whole software environment. Why should I buy a community building tool that will not be available to potential members of my local community? A very good point. And you can find lots of people who agree the OLPC distribution model is problematical for various reasons, for one example: http://www.olpcnews.com/sales_talk/countries/negroponte_change_olpc_distribution_.html But as I see it, this is not about the OLPC XO-1 as an innovation by itself. For me, this is about experimenting with doing education with lightweight portable dynabooks http://en.wikipedia.org/wiki/Dynabook running GNU/Linux supporting dynamic languages (like Python) with wireless connectivity, which don't break when you drop them or use them outdoors around a little bit of water or heat or dust. That's the big picture, long term. I've bought several portable devices (with hopes of running Python software on some of them) -- none have had the (projected) robustness of the OLPC. The robust alternatives I could buy still seem to be in the thousands of dollars, for example: http://en.wikipedia.org/wiki/Toughbook Still, it is possible the XO-1 won't live up to the hype of toughness. And if it doesn't, in my eyes it will have been a failure, because I think that is the most important aspect of it -- reasonably performing GNU/Linux and Python in a tough but cheap enclosure. The software can be fixed up, and I expect will improve over time like it did for the Zaurus SL-5500 or Nokia N800. If the hardware has problems, then you're stuck. Here is a related article with a video clip of earlier (prototype) OLPC's with problems: http://www.youtube.com/watch?v=Fm9bTrpjTZ0 http://www.olpcnews.com/countries/nigeria/olpnc_galadima_school_interview.html From there: On walking around school I saw kids that had laptops with spoiled screens, torn off ears, and defect batteries one kid even told me that his laptop had been stolen. There are teachers for whom the idea of using the laptops in learning is not yet natural, and there are challenges regarding how to digitalize the curriculum the kids must go through during primary school. I found that clip a little heartbreaking as at the end the child puts his hand across the apparently defective laptop screen, me thinking -- is he wonderingly if perhaps there goes his chance at a hopefully better education? Probably need at least 1.2 laptops per child to account for spares. :-( Still, even if only a few people can only get a few now, the general principles related to dynabooks will become more and more ubiquitous as years go by. And they are already happening -- one can get a Nokia N800 for a similar price (although it isn't quite as robust, and it is harder on the eyes). This has been an ongoing trend for many years. With a couple decades this trend might even culminate in devices equivalent to the OLPC XO-1 given away for free on the back of cereal boxes. :-) Electronics goes organic http://www.my-esm.com/digest/showArticle.jhtml?articleID=199700530 But even if that seems to hard to believe, it's not much of a stretch to imagine in ten years buying the equivalent of the OLPC XO-1 used on ebay is only going to cost in the tens of dollars. At that price, almost everyone in the world can afford one (or someone can afford to buy them one if they can't themselves). We are seeing the continued emergence of Pierre Teilhard de Chardin's noosphere. http://en.wikipedia.org/wiki/Noosphere Whether that will be seen as good or bad for most remains to be seen. So, I see the XO-1 as mostly a funky vehicle for this kind of dynabook experimentation. But I expect in two or three years this OLPC XO-1 will be obsolete (if it isn't already. :-) Though on the other hand the Newton MP2100 has held its value for almost a decade, and probably still exceeds the OLPC XO-1 in good power management and ease of use -- although that is mostly software related, for example the Newton may sleep 100 times during the time it take you to draw a line across its screen. I could write a lot on OLPC failings based on the Newton's successes (OLPC didn't use an ARM processor like the Newton, color maybe wasn't essential and if it was, it could have been done the usual way, http://wiki.laptop.org/go/Image:Blurry-develop.png the Newton OS and GUI really did get out of your way most of the time and worked well in a mobile setting). I could even point out at length how the OLPC project duplicates some of the Newton's mistakes (making it hard for developers to use existing code or develop using existing desktop equipment, as OLPC could have made Sugar optional add-ons to Gnome instead of essentially replacing Gnome, etc.), http://www.osnews.com/story.php/16582/The-OLPC-Sugar-Interface-Dont-Do-it/ Still, I think there are also a lot of good points about the general OLPC concept anyway (and even about Sugar's aspirations). I also admire the way it was
Re: [Edu-sig] OLPC G1G1 sales start today
Paul D. Fernhout wrote: For a more typical home user, especially one who does not already know and like GNU/Linux, I'm not sure if it would meet expectations in the developing world as other than either as special purpose device (like used as an ebook reader or robot controller) or alternatively, for a family who buys several, as a family activity to use some of the built in connectivist software (either what is there now or what might be speculatively available in the future). That should have read in the developed world, meaning like the USA. And I really should not be using developed / developing as they are loaded terms (even though the OLPC project uses them too), since there is a lot the USA can learn from other countries, including poor ones, some of whom rank higher in overall happiness in various surveys -- here's a different one: http://worlddatabaseofhappiness.eur.nl/ On using Java/Jython and the OLPC: Pepper on the OLPC http://www.pepper.com/linux/olpc.html A technology preview of a special version of the Pepper environment is now available for the One Laptop Per Child (OLPC) XO laptop. This version of Pepper for OLPC runs on the XO laptop and replaces the standard Sugar environment while retaining the XO's Fedora-based Linux distribution. ... The Pepper environment is written primarily in Java, though it includes open source components like Mozilla and Java that are written in C or C++. The Pepper application framework supports Java, C, C++, XUL, HTML, etc. We're also working on adding Python support soon. ... We'll be making the source code for the Pepper for OLPC environment available soon. We're planning to release it under an LGPL license. We'll also be sponsoring an open source community to maintain the Pepper for OLPC environment. Using Pepper (if it is indeed released under the LGPL as announced above), which is an environment built in Java and including JVM 1.5, I hope I can run Jython on the OLPC. I'll have to try it and see. Maybe the Pepper people do not know about Jython? Of course, software written there in Jython is not going to run on the regular OLPC environment (which is CPython+pyGTK). An informative pro-OLPC post at Slashdot: Worth Careful consideration http://hardware.slashdot.org/comments.pl?sid=357665cid=21325111 An excerpt: While you can certainly waste time and goof off on the web, there is also a wealth of instructional material, learning material, free encyclopedias, and help of all kinds to be had on message boards. Children could learn, for example, methods of improving local sanitation, agricultural techniques, and health information which could end up saving the developed world millions or billions of dollars in humanitarian aid. They could also learn other languages which could open up entire worlds to them. Even if they didn't have the internet, they could learn how to program, how to compute, make art, photographs, drawings, and a whole bunch of other stuff with it. Not to mention the fun factor. It's not an educational panacea but it WILL change the world. And as another slashdot poster says, you can't buy that many paper textbooks for $200, especially compared to what you can cram into 1GB of Flash (or even more if you get the files from local servers and delete old ones). And paper books have their own problems in areas of high humidity (mold, chewed by rodents, fade in the sun, etc.). I think a lot of the economics that governments are considering for deploying OLPC have more to do with replacing plain old paper textbooks with a single laptop than any of the issues of connectivity or simulation or learning to program which are more the sorts of things we think about for computers in, say, the USA or Europe, where we pretty much take purchasing textbooks and access to local libraries of tens of thousands of printed books for granted. Still, even for USA schools, OLPCs may make sense if they save money on textbooks. So, USA school districts could save money of textbooks (if they were free, as in here:) Global Text Project – Wiki Textbooks http://slashdot.org/article.pl?sid=06/09/05/230201 http://globaltext.org/ (or even just at direct author royalty cost) and kids get Python and educational simulations thrown in as a bonus. Plus, they get a lighter load and less back pain. Heavy backpacks lead to early strain and pain for schoolkids http://cnnstudentnews.cnn.com/2001/fyi/teachers.ednews/02/13/backpack.pain.ap/ Anyway, as an ebook reader alone the OLPC might be worth the US$425 cost, which is only a $100 more than what a Sony Reader costs with an extra waterproof cover, and that amount is less than the more flexible (but heavier) iRex Iliad. See: http://www.mobileread.com/forums/showthread.php?t=5664 I think key to happiness with the OLPC in the USA is reduced expectations. Consider that for $425, you get an OLPC ebook reader than runs Python, and then some kid somewhere else with limited access to books gets one too
[Edu-sig] Software Engineering with Python for Scientist and Engineers
This project was one funded by the Python Software Foundation: Software Engineering with Python for Scientist and Engineers. http://www.swc.scipy.org http://www.python.org/psf/grants/report-2006-10/ Seems like an interesting source of material for teaching people using Python and Jython in a larger science and engineering context. Seems to cover (Briefly) a lot of ground, including things like version control which aren't strictly just Python but are important anyway in Python programming in practice. Plus it is free and open source and so possible to change. From that page: Overview Many scientists and engineers spend much of their lives programming, but only a handful have ever been taught how to do this well. As a result, they spend their time wrestling with software, instead of doing research, but have no idea how reliable or efficient their programs are. This course is an intensive introduction to basic software development practices for scientists and engineers that can reduce the time they spend programming by 20-25%. All of the material is open source: it may be used freely by anyone for educational or commercial purposes, and research groups in academia and industry are actively encouraged to adapt it to their needs. Does anyone here have any comment on it or used it in teaching or self-education? I looked in the edusig archives and did not find a mention of it here before, which I found surprising. Maybe I just missed it? --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Ditch self?
Dethe- Thanks; that was very helpful in improving my understanding of Python in practice. --Paul Fernhout Dethe Elza wrote: Paul, to assign a function to an instance object (rather than a class) as a new method, use the new module: = start module prototype.py == ''' Example of adding methods to an instance object and a class ''' import new class Foo(object): def bar(self): print 'bar', self.__class__ # outside of class Foo, define some functions to turn into methods: def baz(self): print 'baz', self.__class__ def foobar(self): print 'foobar', self.__class__ # make some instances a = Foo() b = Foo() # make baz a method of Foo, both a and b should be able to call it Foo.baz = baz print 'baz:', Foo.baz a.baz() b.baz() # make foobar a method of a, calling b.foobar should fail a.foobar = new.instancemethod(foobar, a, a.__class__) print 'foobar:', a.foobar a.foobar() b.foobar() # fails = end of module == and when you run it: $ python prototype_based.py baz: unbound method Foo.baz baz class '__main__.Foo' baz class '__main__.Foo' foobar: bound method Foo.foobar of __main__.Foo object at 0x75990 foobar class '__main__.Foo' Traceback (most recent call last): File prototype_based.py, line 42, in module b.foobar() # fails AttributeError: 'Foo' object has no attribute 'foobar' More info: http://docs.python.org/lib/module-new.html HTH --Dethe ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Ditch self?
kirby urner wrote: Since you've rejoined, To be clear, I never left. Just been listening and learning and focusing my writing on other stuff (even towards a new PataPata version focused mainly on Jython). I promise to keep quiet until you leave, which may be never. I know you posted similar things in your interactions here with Art, but I personally hope you continue to post your interesting thoughts on edusig, whether we agree on everything or not or whether another topic comes of here of immediate interest to me. As I said, I am focusing mainly on other things right now, but this issue of self in declarations was just one I have wrestled with in the context of trying (and perhaps failing) to make Python easier to use and learn (and I appreciated Dethe's help in coming up with an implementation alternative). By the way, on rereading my post, I realize I should make clear, while I feel self in function declarations may be superfluous as a matter of opinion (given the typical indentation of the declaration of such functions inside the scope of a class definition), I like the explicit use of self within the body of a function (unlike the common standard practice in, say, Java or the language Self where it can be frequently omitted); the two issues are different ones; I should have been clearer on the distinction, and as I realize now I think your post was likely more focused on the issue of self in the body of a function as opposed to the declaration, and in that area I think you, Guido, and I (as well as Smalltalk's designers) all agree on the value of an explicit self. All the best. --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Ditch self?
Kirby- Whitespace clearly removes redundant clutter (either braces or begin/end); all complex human-edited programs need to be indented for readability anyway. The redundant self in Python method/function definitions mainly adds clutter IMHO, and so is a wart IMHO (even as it is sometimes changed when used in class methods, and so on). Smalltalk managed to get by with self being implicit, and that language definitely has people reading code sometimes with the kind of self projection you mention. Conceptually, I feel that since globals are not passed in explicitly into functions, self should not be either. The word self not a global of course, and nor it is reserved in Python (unlike Smalltalk), but it still feels to me that self is more a part of an active function's namespace more than it is a calling parameter IMHO. But I can also see the arguments to have it be explicit, including the ones you mention. I specially like the Unicode name change one for people coding in a language other than English, but even then, there are so many other English words you can't change in Python statements, so does it really get you very far to be able to change only self? It seems like a deeper multi-language paradigm for programming is needed to address that specific issue, and that is something, say, the OLPC project is struggling with in terms of viewing source code written mostly in English. I do know that in supporting prototypes under Python in PataPata, I did wrestle with issues where assigning new functions into slots used as methods was more complex than I naively would have expected. === EXAMPLE For example, when copying a method from one prototype to another, I ended up with this complex code, both for assignment and calling, using an indirect PrototypeMethod class as a wrapper for functions: class PrototypeClass(object): ... def __setattr__(self, name, value): ... if callable(value): if isinstance(value, PrototypeMethod): if value.prototypeHoldingTheFunction != self: wrappedMethod = PrototypeMethod(self, value.function, value.source) value = wrappedMethod else: value = PrototypeMethod(self, value) ... class PrototypeMethod: ... def __call__(self, *args, **kwargs): return self.function(self.prototypeHoldingTheFunction, *args, **kwargs) This was rather than a more simple assign of Python functions. There was an issue in that the method function was already bound to the specific prototype instance, rather than being a more generic function as self in the parameter list might imply. Maybe someone who knows more about Python internals than I could have done this more simply without introducing these extra classes? Clearly this works: $ python Python 2.4.4 (#2, Apr 5 2007, 20:11:18) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 Type help, copyright, credits or license for more information. class Foo: ... def bar(self): ... print hello ... Foo().bar() hello def test(self): ... print hello 2 ... test(None) hello 2 Foo.bar = test Foo().bar() hello 2 y = Foo() y.bar = Foo().bar y.bar() hello 2 But this additional code does not work: x = Foo() x.bar bound method Foo.test of __main__.Foo instance at 0xf7ce72ec test function test at 0xf7ce0bc4 x.bar = test x.bar() Traceback (most recent call last): File stdin, line 1, in ? TypeError: test() takes exactly 1 argument (0 given) And it is this second case which I was concerned about in prototypes. Clearly the two functions are different. One if a function; the other is a bound method. It seems to me that if self is indeed the same in both functions that the assign of test to the Foo instance should work the same way the assign of test to the Foo class does. But it does not, because the assignment to the instance needs to be with a function which already has self bound to the specific instance. So, I feel like there is a conceptual mismatch here. But maybe I am just not looking at it the right way? I certainly understated why, to pass function pointers using x.bar to objects which call them, that self needs to be bound. Although I have some problems with even this, since the function pointer is bound so tightly that if you completely replace it in the class or instance, the previously bound version is used, not the new one (unless you just replace code internal to the function). A common place where this issue comes up is if you build a GUI which has methods linked to button events, and you want to modify or reload the class on the fly and have the button activate the new code, not the old code; you can do it, but it is non-obvious how to do it and involves mucking about with the internals of functions (as has been discussed here before). I'd rather see actionPerformed=x.foo bind foo more lightly, so that the actual function was looked up at dispatch time rather than at
Re: [Edu-sig] Politics and Python in Education (meta on list charter)
Peter Bowyer wrote: In the context of deploying Python as a teaching aid (or the language for a Computer Science course) I don't give a damn about what education *should* be. I want to hear the approaches others are finding successful, I want to hear what people are doing/planning to do and their ideas. I don't want a load of theoretical talk - I'll join another mailing list for that. OK, let's talk specifics of a CP4E-like project and its limitations. Consider one that is mentioned in the CP4E proposal (though somewhat dismissively) -- DrScheme, or as it is now, Teach Scheme: http://www.python.org/doc/essays/cp4e.html Teach Scheme is IMHO (arguably) currently the most successful worldwide project to bring a dynamic computer programming language into the classroom. [OLPC (carrying Python) might someday soon eclipse it, but that still remains to be seen. Same with the Shuttleworth Foundation's noble effort. ] The Scheme effort is more advanced and organized with more integrated pedagogical content about teaching programming than Python/CP4E. See for example: How to Design Programs: An Introduction to Computing and Programming http://www.htdp.org/2003-09-26/ [Free Scheme book, problem sets, solutions, teachpacks, etc.] It has an IDE built specifically both for learning programming and for advanced development supporting multiple language levels. http://www.plt-scheme.org/software/drscheme/tour/ And, unlike how they are described way back when in the CP4E proposal as The focus of TeachScheme is on a relatively narrow audience--college students..., at least now the Schemers say Teach Scheme is Specially designed for high schools, see: http://community.schemewiki.org/?teach-scheme http://teach-scheme.org/Talks/ts-proj-anim.pdf Consider the preface to their book _How to Design Programs_: http://www.htdp.org/2003-09-26/Book/curriculum-Z-H-2.html Our claim that everyone programs or should learn to program might appear strange considering that, at first glance, fewer and fewer people seem to program these days. Instead, the majority of people use application packages, which don't seem to require any programming. Even programmers use ``program generators,'' packages that create programs from, say, business rules. So why should anyone learn to program? The answer consists of two parts. First, it is indeed true that traditional forms of programming are useful for just a few people. But, programming as we the authors understand it is useful for everyone: the administrative secretary who uses spreadsheets as well as the high-tech programmer. In other words, we have a broader notion of programming in mind than the traditional one. We explain our notion in a moment. Second, we teach our idea of programming with a technology that is based on the principle of minimal intrusion. Hence our notion of programming teaches problem-analysis and problem-solving skills without imposing the overhead of traditional programming notations and tools. ... No one can predict what kind of application packages will exist five or ten years from now. But application packages will continue to require some form of programming. To prepare students for these kinds of programming activities, schools can either force them to study algebra, which is the mathematical foundation of programming, or expose them to some form of programming. Using modern programming languages and environments, schools can do the latter, they can do it effectively, and they can make algebra fun. Sound familiar? Great minds think alike in some respects. :-) The Teach Scheme project even offers free summer workshops to teachers: http://www.teach-scheme.org/Workshops/ But, notice on that free workshop page the first *hint* of a systemic school-related educational politics problem on that page, where they write: We also welcome high school teachers who cover at least one of computer science, mathematics, and the physical sciences. We ask that you first contact your school to determine whether they will allow you to make curricular changes based on the summer course. You should find out what obstacles you will face from your school if you decide to adopt this curriculum. Odd, isn't that? Here is wonderful content and software implementing some of the core goals of CP4E, all for free to the end user, labeled by the authors as specially designed for high schools, with presumably High School teachers so interested in using it they are willing to take the time to attend a week-long summer workshop so they can help their students learn using the best tools for their own unique situation, and yet, this group throws out a wet blanket warning to put out the fire in those teachers' eyes? Surprising, or is it? I can only speculate on the ocean of tears motivating that warning. So, for all that high quality free content, those specialized teaching tools, those person-years of dedicated work, and so on, (pursuing a lot of the CP4E mission but in
Re: [Edu-sig] Politics and Python in Education (meta on list charter)
Guido- The change to edusig's charter by you as BDFL seems to be a fait accompli, so the redirect to meta-sig seems to be a waste of time, so I'm going to drop this topic after this last post (I need to get back to writing software in Python. :-) As closure, someone with more perspective on this discussion than I told me offlist they think it is *hilarious* that this sudden ban on political discussion on edusig has come about in proximal response to Kirby originally posting (in part): In the USA, most schools erect an artificial wall between mathematics and any discipline involving computer programming. To question this wall is considered heresy. One is branded a radical for even calling attention to its existence. Instead of using the Python or any other kid-friendly language to develop ideas about rational and complex numbers, vectors, sets, primes versus composites, important algorithms of mathematics, our children are enslaved to a dark ages regime that permits only calculators, probably by Texas Instruments. Programming is considered irrelevant to mathematics learning. Open source software is scarcely whispered about. The use of Python or other programming languages is either strictly forbidden or strongly discouraged within primary and secondary school mathematics classes. We'll see how well censorship works here too. All the best. --Paul Fernhout I just wake up in the morning and tell myself, 'There's been a military coup'. And then it all makes sense. -- a US State Department official http://www.guardian.co.uk/usa/story/0,12271,1045302,00.html Guido van Rossum wrote: I'm just speaking for the majority of list members who are tired of your and Kirby's (and it the past Arthur's) rants. I really don't care about arguments proving that the list charter is what you want it to be. Most people want it to be something else. Check the recent discussions. Almost nobody has spoken in defense of you or Kirby, many responded with an enthusiastic +1 to my original proposal to ban politics. --Guido On 7/18/07, Paul D. Fernhout [EMAIL PROTECTED] wrote: Guido- I've been on this list continuously since about the second day (2/3/2000) -- a little over seven years. I'll admit I was so turned off by Kirby's comments after my initial posts (on bringing good ideas from Squeak into Python, the technical topic I still like the most, and continue to work towards). I went into lurk mode for about five years, mostly until the issue of Python drawing from Squeak resurfaced from others. I've since come to appreciate Kirby's unique charm. :-) Remember when you sent out this in your email of 2/2/2000 entitled: Special Interest Group: Python in Education? It read in part: I don't have a fixed idea about what the charter of the SIG should be; I'd like to see discussion of CP4E, but also of other issues related to Python and education, and I'd like to include all levels of education (from grade school to college level as well as adult education), as long as people are interested in learning or teaching Python. That can be read a lot of ways. If you intended something more specific you should have said so then. Remember the start of very *first* reply by someone else (to the CCs, not to the list) and the related thread? The very first reply by someone else (not me) started with: the only way you can succeed is to have choice in education and without competition, the current public education monopoly will crush you. they are just to paranoid about virtual classrooms and the nea and aft are like stalin in their efforts to block every and any attempt to do this in k to 18, ... And went on from there. And then the start of the *second* reply by someone else (also to the CCs and not to the list): While I may not be quite as cynical as Mr. [Name omitted] I must admit that I have seen some of the attitudes that he describes. While one would think that you would find progressive out front thinkers in the field of education, unfortunately they seem to be the exception to the rule. Instead they are offen territorial, politically motivated and especially uncomfortable with change of any kind. They give lip service to out of the box thinking but rarely reward it. Didn't those two initial replies to the CC list give you some inkling of what you were getting yourself into with CP4E? Or the whole reason why DARPA would think it was so essential as to be worth funding your proposal to solve a serious problem in the USA affecting the entire nation's security and prosperity? Or perhaps the world's security and prosperity, for that matter, in the face of a likely technological singularity? http://en.wikipedia.org/wiki/Technological_singularity Look, if you suddenly pop up after five months of silence on this list to present an admitted strawman proposal (like you did) http://mail.python.org/pipermail/edu-sig/2007-July/008073.html which is to actually *change* the evolved
Re: [Edu-sig] Politics and Python in Education
Anna Ravenscroft wrote: Still, I could essentially see Guido's point, because some conventional school staff who otherwise like Python may face issues posting to a list talking about the future of education (which may appear to threaten their job), so perhaps ultimately a solution would be to have one list for python in mainstream education and another list for python for alternative or future education. Or how about one list on educational politics and one on python in education. Oh wait - there ARE already lists on educational politics... how about those who want to discuss that, go to those lists and discuss it there?! And use this list to specifically discuss python in education? I think your analogy (and by extension Guido's strawman proposal) is flawed, because a key aspect of *design* is to see how values and priorities (which is the core of politics) lead to new and interesting structures for software and content and hardware. In a Python CP4E context I see this as including any or all of: * changes to Python itself (e.g. edit and continue support in the core and in IDLE), or * new libraries for Python (e.g. PataPata), or * new application based on Python (e.g. constructivist educational simulations, including perhaps, though he might have disagreed, the late Arthur Siegel's PyGeo :-), or http://pygeo.sourceforge.net/index.html * new curricula or other smaller educational materials (e.g. the Shuttleworth Foundation's steps in that direction), or * even new hardware which is Python-powered (e.g. OLPC, or even Lego Mindstorms NXT robotics, which I just got two of and was yesterday looking up references to using Python to program). To talk about creating such software or hardware or content without a sense of priorities and values would be analogous to going to an architect, asking them to design you a custom house and, and then saying, well, you're an architect, just design us something, we are busy people and have no time to talk about values or priorities. Although I guess even there a clever architect would learn one thing about such people's values and priorities. :-) For a personal example, to show these issues are not just talk, consider the literally person-months I spent building the PataPata experiment http://patapata.sourceforge.net/ to bring some Squeak-like constructivist ideas more directly into a Python-powered IDE, and which I discussed on this list. Maybe not a huge success, but a big investment of my limited time in the free Python realm and I learned a few things from it (including the importance of naming objects if you wished to share them, a departure from the Self prototype programming ideal using unnamed pointers to parent objects). http://patapata.sourceforge.net/critique.html Ultimately, PataPata was of very marginal interest here. Other people can talk about how Squeak has ideas that might work in Python, but when things got going, the talk was just talk. Ideally, from my point of view, people here would have discussed how these priorities and values of learned-centered technologies such as PataPata was a step towards could be translated into even more Python-related software, stuff beyond PataPata and even better. People could go beyond what I reference, and go beyond my own self critique, and as experienced educators suggest even better ideas for new technology related to Python (e.g. the students are always saying if only we had X Y or Z for Python they'd be using it so much more for the things they want to do -- like the reasons a homeschooled kid chose DarkBasic instead of Python, as mentioned on the Math Forum Kirby posts to). http://mathforum.org/kb/message.jspa?messageID=5812048tstart=0 But that doesn't happen here much, in large part I'd speculate since most educators here are teachers, and the authoritarian context most teachers work in is unfortunately very limiting both as to free time and as to possible horizons, at least in the USA. Again, for example, consider my relative who could be fired if she installed Python on her classroom computer, and who would not have enough free time to go through the bureaucratic hoops to get Python installed district wide, let alone then have time to learn how to use it). That all to me is tremendously disappointing, especially as: CP4E != CP4MainstreamSchools in my thinking (even if mainstream schools are part of Everyone). It's no big surprise the US military (of all US institutions including the Department of Education) initially funded CP4E, because, in the USA, historically the military has had the most difficulties dealing with lack of education among recruits, see for example: http://www.johntaylorgatto.com/chapters/3b.htm Back in 1952 the Army quietly began hiring hundreds of psychologists to find out how 600,000 high school graduates had successfully faked illiteracy. Regna Wood sums up the episode this way: After the psychologists told the officers that the graduates weren’t faking,
Re: [Edu-sig] Politics and Python in Education (meta on list charter)
to say. I'd like to draw everyone's attention back to the spinoff list which others started to have a narrower focus: http://groups.google.com/group/edupython Description: Supporting the development of online resources and interactive tools to serve high school students, undergraduates, and hobbyists learning Python, and to assist teachers and instructors in reaching those audiences. One comment by Michael T. on that list: http://mail.python.org/pipermail/edu-sig/2006-April/006278.html There was general agreement among the attendees at the education BOF meeting at PyCon that a new list was necessary, so although my own presence is recent, my assertion was not unsupported. There has also been some discussion of dissatisfaction with the breadth of discussion here expressed since I have been following the list, notably including some strongly worded advice from Guido van Rossum recently. Note the words new list. It seems to me you are trying to beat edusig into that new list (which is a bit ironic, as the new narrower list itself seems to be not very active in the past few months, especially compared to edusig). What's next, restricting discussion on educational philosophy as opposed to politics? That's another thing some people have complained about. And then after that? References to Squeak or DrScheme? Maybe comments on constructivism? If you want a new list with a highly focused charter (can such a thing even be defined in this context?), with an explicit policy anyone posting something beyond that narrow charter will be booted from the list, then by all means, go for it, and give it your blessing. Changing edusig's policies and culture midstream through censorship threats or related intimidation seems ultimately counterproductive to me. As you suggest, your main concern is just on the hypothetical chance a strict rule might prevent possible future problems like some *unspecified* lists had in the past and which this one has not had (at least not to that degree, even if watching Art and Kirby wrestling with each other could get tiring sometimes. :-) Having said that, I had pretty much moved back to lurk mode on the list (my previous last post was in April) before your strawman proposal anyway; I only started responding on this topic to defend Kirby. If you want to ban me for responding to a meta-discussion *you* started, then go ahead. :-) I'm certain we *both* have better things to do. --Paul Fernhout Guido van Rossum wrote: Please stop arguing politics on the list NOW. I don't want to start actually kicking people or posts off the list, but I will if it doesn't stop. This is simply not the platform for it. Find a different platform where this topic are welcome. --Guido On 7/18/07, Paul D. Fernhout [EMAIL PROTECTED] wrote: Anna Ravenscroft wrote: Still, I could essentially see Guido's point, because some conventional school staff who otherwise like Python may face issues posting to a list talking about the future of education (which may appear to threaten their job), so perhaps ultimately a solution would be to have one list for python in mainstream education and another list for python for alternative or future education. Or how about one list on educational politics and one on python in education. Oh wait - there ARE already lists on educational politics... how about those who want to discuss that, go to those lists and discuss it there?! And use this list to specifically discuss python in education? I think your analogy (and by extension Guido's strawman proposal) is flawed, because a key aspect of *design* is to see how values and priorities (which is the core of politics) lead to new and interesting structures for software and content and hardware. In a Python CP4E context I see this as including any or all of: * changes to Python itself (e.g. edit and continue support in the core and in IDLE), or * new libraries for Python (e.g. PataPata), or * new application based on Python (e.g. constructivist educational simulations, including perhaps, though he might have disagreed, the late Arthur Siegel's PyGeo :-), or http://pygeo.sourceforge.net/index.html * new curricula or other smaller educational materials (e.g. the Shuttleworth Foundation's steps in that direction), or * even new hardware which is Python-powered (e.g. OLPC, or even Lego Mindstorms NXT robotics, which I just got two of and was yesterday looking up references to using Python to program). To talk about creating such software or hardware or content without a sense of priorities and values would be analogous to going to an architect, asking them to design you a custom house and, and then saying, well, you're an architect, just design us something, we are busy people and have no time to talk about values or priorities. Although I guess even there a clever architect would learn one thing about such people's values and priorities. :-) For a personal example, to show these issues
Re: [Edu-sig] Python in Secondary Schools
I mostly agree with Andrew. And, further, as is made clear in the book _Disciplined Minds: A Critical Look at Salaried Professionals and the Soul-Battering System That Shapes Their Lives_ http://disciplinedminds.tripod.com/ http://www.amazon.com/Disciplined-Minds-Critical-Professionals-Soul-Battering/dp/0742516857 you can't separate politics from the educational process. In many ways, politics is about the control of the educational process. You can pretend to separate them -- by adopting a supposedly objective and professional viewpoint -- but in the end, when you do that, you just have made a vote to uphold the status quo, which is obviously and clearly failing the next generation (at least, in the USA). See also for example: why education technology has failed schools http://billkerr2.blogspot.com/2007/01/why-education-technology-has-failed.html (which links to an essay of mine). From there: Ultimately, educational technology's greatest value is in supporting learning on demand based on interest or need which is at the opposite end of the spectrum compared to learning just in case based on someone else's demand. ... Compulsory schools don't usually traffic in learning on demand, for the most part leaving that kind of activity to libraries or museums or the home or business or the real world. In order for compulsory schools to make use of the best of educational technology and what is has to offer, schools themselves must change... So, there is more to the story of technology than it failing in schools. Modern information and manufacturing technology itself is giving compulsory schools a failing grade. Compulsory schools do not pass in the information age. They are no longer needed. What remains is just to watch this all play out, and hopefully guide the collapse of compulsory schooling so that the fewest people get hurt in the process. I think Kirby's original post was completely on topic and illustrating why Python (and other programming languages) has not made the progress one might expect in expanding into broad areas of education. He uses math as an example, but one could just as well find similar issues in why computers (and Python driven software) are not used in teaching social studies or science via having kids build their own simulations or do detailed analysis of various issues from a critical and quantitative perspective. These political issues of constructing disciplined minds remain the elephant in the living room of any discussion of educational technology IMHO. However, as the recent discussion of scaffolding and Papert shows, there remains a lot of value in having another human being around to provide scaffolding and mentoring (even if it happens indirectly or subtly). And people on this list have made clear how writing a good tutorial requires special skill and much effort, and that is independent of whether you force people to use that tutorial at any point in time. So, both those things suggest the value of the *educator* even if one can (and I think should) have disagreements with the authoritarian *process* most educators in our society find themselves embedded if they are in a school environment or supporting one somehow. Basically, as I see it, there is a (peaceful) educational revolution going on right now around the world, see for example: http://www.educationrevolution.org/ http://www.greenmoneyjournal.com/article.mpl?newsletterid=21articleid=195 related to learner-centered approaches to education. It is difficult to discuss Python in education or Computer programing for everyone in any *meaningful* terms without the context of this ongoing educational revolution towards learned-centered solutions. Those ideals in turn guide the development of related techniques -- supporting learning on demand, learning by playing with a simulation, or learning by doing or construction or programming. This change in many is just a return to how learning used to be done hundreds of years ago either in a neighborhood or apprenticeship context. Essentially, what seems to me to be proposed here is making edusig a discussion group for How or why to use Python (as is) for use in the standard K-12 classroom to meet narrowly defined instructional objectives?. The short answer to that implicit question is, as Kirby implies, that there is essentially no role for Python in the standard mainstream K-12 classroom (I'd frame it as it's simply too dangerous a concept :-). Or, as someone else suggests, the other answer to that implicit question is, learn Java if you want a strategic plan because you can use it to get A.P. credit and save money in college. But those are not good answers for people who want kids to be empowered, since the mainstream classroom is mostly not about empowering kids, just like Java (unlike Python or other dynamic languages like Smalltalk or Lisp or Ruby) is mostly not about empowering programmers. Still, I could essentially see Guido's point, because some conventional
Re: [Edu-sig] Python in Secondary Schools (politics of installing Python edit and continue)
For some specific examples of how educational politics are effecting Python, see below . Anna Ravenscroft wrote: as a parent, I agree with Kirby about the education system in this country. Kirby, I suggest you join one of the many lists/groups on the topic, including mathematicallycorrect.org and others. Save your polemics for that community. Looks like that site you reference may have disappeared. It now seems to be a parked site hawking links to conventional mathematics teaching stuff. Here is an old version from 2001: http://web.archive.org/web/20010603024048/http://www.mathematicallycorrect.org/ That old page links to this other site www.mathematicallysane.com, which might be of similar interest: http://www.mathematicallysane.com Join us to stay current with the latest information about mathematics education reform. Over 2,000 people have already joined! It links to this essay on The Goals of Mathematical Education by George Polya (an expert on methods for solving problems) http://en.wikipedia.org/wiki/George_P%C3%B3lya from around 1969 (so, almost forty years ago): http://www.mathematicallysane.com/analysis/polya.asp Therefore the schools, especially the primary schools, are today in an evolution. A sizable fraction, ten to twenty percent, already have the new method of teaching which can be characterized in the following way in comparison with the old method of teaching. The old method is authoritative and teacher-centered. The new method is permissive and student-centered. In the old time the teacher was in the center of the class or in front of the class. Everybody looked at him and what he said. Today the individual students should be in the center of the class, and they should be allowed to do whatever good idea comes to their mind. They should be allowed to pursue it in their own way, each by himself or in small groups. If a student has a good idea in class discussion then the teacher changes his plans and enters into the good idea and now the class follows this idea. Two schools where kids learn like that: http://www.albanyfreeschool.com/ http://www.sudval.org/ There you have the core of what is still the *political* problem posed by educational technology (including Python in the classroom). Is it to be authoritative and teacher-centered (and to reflect a similar society) or is it to be permissive and student-centered (and also reflect such an alternative society)? Or is it to be some hierarchy/meshwork hybrid of both approaches (and reflect a hybrid society)? From Manuel de Landa's writings: http://t0.or.at/delanda/meshwork.htm Indeed, one must resist the temptation to make hierarchies into villains and meshworks into heroes, not only because, as I said, they are constantly turning into one another, but because in real life we find only mixtures and hybrids, and the properties of these cannot be established through theory alone but demand concrete experimentation. Finding our way to some balance of hierarchy and meshwork is the political problem of our age, and educators are smack in the middle of it, even when they choose to do something seemingly innocent like to install Python on their computer instead of teach AP Java. With all due respect to Guido for his programming and project management and other skills, somebody like Kirby lives his professional life in the educational trenches (or alternatively, now helping people get out of them for a day or a week at a time). I have a relative who teaches K-12; her school district made her sign an agreement a few years back acknowledging that despite her other employment protections she could be fired if she installed *any* software on her classroom computer. That is what it is like in those trenches even for many teachers -- it's often crazy-making. What's the point of having a computer in your classroom if you can't install free software on it which might be of interest to the class (like Python itself or even just other Python-based software)? What does this say about the culture of the classroom or even the expectations of the community in relation to the legal and technical literacy of teachers? And then what's the point of even discussing Python in secondary schools if no one can use it there for short-sighted legal or doctrinal reasons? Policies like that are one reason the web is playing such a big role in schools, including Java and Flash applets. How can one plot out future directions in education for Python unless one takes stock of where such policies are driving classrooms? Yet does discussion here of education in the classroom emphasize Jython (which could produce Java applets and so be usable by my relative)? Or some sort of platform to produce Flash applets from Python somehow (which also might be usable by my relative)? Not really. Although Crunchy Frog http://crunchy.sourceforge.net/ might help in that direction (but ignoring the fact most schools won't install and maintain their own server for similar
Re: [Edu-sig] More OLPC chatter (PataPata; EditContinue)
First, to emphasize a key idea below, everyone here should see for a six minute video walkthrough example: A nice demo of Smalltalk development in the debugger by David Buck. http://motionobj.com/article/demo-of-smalltalk-visualworks http://www.simberon.com/smalltalkdemo.avi That's what OLPC should ideally be able to do with a View Source key IMHO. Well, we've been round this before, obviously: http://www.mail-archive.com/[EMAIL PROTECTED]/msg02442.html Developing a more dynamic way to view and edit source on running systems built on Python was, of course, the main point of the PataPata experiments. :-) http://patapata.sourceforge.net/ Here is Francois Schnells' related demo video: http://showmedo.com/videos/video?name=patapata_tkinter1_fSchnell The phrase that now seems to be in vogue to describe such capabilities is Edit and Continue. Not quite entirely the same, but it covers enough to be really useful as a search term. This feature is of great value to beginners when it is integrated into an IDE well, as it helps them immediately focus on broken pieces of code rather than finding them by more indirect means. In hindsight, I wish I had focused more on getting plain Python and Jython to be more friendly in terms of Edit and Continue: http://www.google.com/search?hl=enq=edit+and+continue like by hacking the core C and Java code, and perhaps IDLE and PyDev, rather than focusing on using plain-vanilla Python to support prototypes, to add properties, or wrapping various widget libraries. After all, Smalltalk (Squeak or VisualWorks or several others) all allow edit and continue even though they are, like Python, mostly class based. In the end your (Kirby's) points have proven all too valid -- it's hard to get a new paradigm accepted, especially when it goes against the grain of how underlying libraries are written, all the books out there, and so on. The path of least resistance really would have been to add an edit and continue patch to C-Python (or Jython), perhaps centered around a PEP. It's not what I wanted -- since I wanted backward compatibility with older Python versions -- but in the end it I feel it would have been more effective, and likely a better payback for the person-months of effort that went into the PataPata experiment. Still, that's why people do experiments, to learn, and I learned. :-) Hopefully others can benefit from what I learned too. I still feel one thing PataPata got right (as a technical advance, inspired by Self) was showing how you could save and restore the state of a world of Python objects (and their behaviors) just by writing a plain text (and highly readable) Python program which reconstructed that world of objects (with that made slicker by using Ian Bicking's suggestions for meta class uspport). See my postmortem self-critique (for more information: PataPata critique: the good, the bad, the ugly http://patapata.sourceforge.net/critique.html I feel that's a good idea to keep in the back of your mind when thinking about OLPC applications and view source. And it's so much nicer to do things that way than via pickle which produces an almost unreadable (and so effectively unmodifiable) output of a live set of Python objects. On edit and continue, from Microsoft's web site: http://msdn2.microsoft.com/en-us/library/bcew296c.aspx Edit and Continue is a time-saving feature that enables you to make changes to your source code while your program is in break mode. When you resume execution of the program by choosing an execution command like Continue or Step, Edit and Continue automatically applies the code changes with some limitations. This allows you to make changes to your code during a debugging session, instead of having to stop, recompile your entire program, and restart the debugging session. I pick Microsoft's definition even though they were late to the party (compared to Lisp and Smalltalk doing this decades ago) just to show how mainstream such technology has become. Isn't this omission just a glaring embarrassment for Python at this point? And no, module reloading doesn't cut it, as it entails building your own hooks into your application as well as thinking through a lot of implications of what that means -- definitely not something for Python newbies to consider doing. I myself add limited support for module reloading in a commercial application while developing and it makes a lot of difference when developing an application which has long load times or long processing times -- but it's not a trivial thing to manage, nor is it the same as Edit and continue. So I think another attempt towards PataPata's ideals, but not emphasizing prototypes, and considering changes to the Python and Jython cores (C and Java), might be worth trying from a Python community point of view -- or even as Python3000 feature. Sadly, I'm now wrapped up in other things and can't devote even a few weeks (or more) to realizing this right now; plus I do think it
[Edu-sig] More OOP bashing ( which metaphor is best?)
I just came across these links (bearing indirectly on the value of Python emphasizing both procedural and Object-Oriented Programming support as a language good for beginners and experts): See: Object Oriented Programming Oversold! http://oop.ismad.com/ Or: Guide To Myths http://www.geocities.com/tablizer/myths.htm And: Why I Prefer Procedural/Relational Over OOP http://www.geocities.com/tablizer/whypr.htm From the last, for example: It is my opinion that the division between data and behavior in procedural/relational (p/r) applications also has software design benefits. It allows a certain contract between the database and the database user (application programmer). Contracts usually have certain obligations and costs, but these costs are worthwhile for the parties of the contract or else the contract would not be entered into. The relational paradigm involves just such a contract. If you follow your end of the bargain, then the other party, the relational paradigm, will provide wonderful benefits. The limitations required are not arbitrary, for they provide a powerful intellectual rigor which is one of the greatest tools of modern software technology in my opinion. Along with GUI's, relational technology is one of the rare wow! technologies that is a fundamental leap forward in software design. ... The contract of the relational paradigm basically says, If you put or keep your information (data) in a certain given structure, then there are powerful and concise operations that you can do on this information. E. Codd, the inventor of relational algebra, opened the world's eyes to a powerful kind of math (with some help from more practical-minded collegues). This math can reduce complex structures and patterns into relatively simple formulas, or relational math. Of course, one might argue relational databases are just well defined objects... :-) But then the object paradigm starts to break dawn -- and one is really thinking more in terms of modules then how objects are usually discussed. As I previously wrote here (and on the Squeak list a long while back): http://mail.python.org/pipermail/edu-sig/2006-December/007483.html Personally, one way my opinions differer from Alan Kay's in a deep way is on his, I think mistaken, notion that an object (or a class) can have any meaning apart from the ecology of objects (or really classes) it is embedded in. I think there is a deep philosophical (and practical) point there which he is perhaps only slowly beginning to see. :-) But it is reflected in the superiority of, say, Python's modularity in practice compared to early Smalltalks, that is, if you think classes stand alone, then there is no need for a higher level of module, whereas if you think classes need to be clustered to support each other, than modules make a lot of sense. Still, I think the more general issue, present even in AK's new proposal, is how one can simulate the world by objects but one also can simulate the world (perhaps more accurately, if with more effort) as a set of fields defined by relations (or by any other method). Whether such fields are best implemented procedurally or via OOP is another question. Anyway, when one delves this, it gets murkier and murkier -- in part because people often confuse having a modeling layer of discrete objects somewhere as meaning the models are all about Objects and OOP, but there is no reason one cannot use objects to model other things (fields) -- or even vice versa. Still, from a beginner point of view, why should you have to get the metaphor of objects if what you are interested in are fields (e.g an astrophysics simulation of particles in an electrostatic gradient and/or gravity well)? I think the appeal of APL based on arrays is in part the appeal of fields. One thing that makes this all confusing to understand is the human mind has a layer (or module) that models the complex real world in terms of a simplified representation of objects (as I wrote in my undergraduate thesis in 1985: Why Intelligence: Objects Stability Evolution and Model). William Kent explored this in his book _Data and Reality_: http://www.bkent.net/ For example, by numbers, people are about 90% bacteria, but we generally don't see other people as walking bacterial colonies. :-) People Are Human-Bacteria Hybrid http://www.wired.com/medtech/health/news/2004/10/65252 Yet if you want to understand some branches of holistic medicine (and why using antibiotics might have lifelong health impacts) then you need to think about people this way, as hard as it is. http://www.findarticles.com/p/articles/mi_m0NAH/is_2_32/ai_83316363 And then, if you want to understand bacteria, you have to see them more as a vast worldwide supercomputer than isolated individuals: New Science Of Metagenomics to Transform Modern Microbiology? http://science.slashdot.org/article.pl?sid=07/04/02/2017249 So, as Plato's Allegory of the Cave suggest it is sometimes hard to see past
Re: [Edu-sig] [BULK] More OOP bashing ( which metaphor is best?)
Peter Chase wrote: Not sure you can trust anyone using the phrase appeal of APL. Personally, I haven't used APL for over twenty years (since when you needed it to run a graphics package called FOIL to produce multicolor plotter output). I'm not a big fan of backspacing over funny characters to make more even complex operators (as neat an idea as I'm sure that sounded at the time). :-( Still, consider: http://www.sigapl.org/letter-2006-07.html The executive committee is making an effort for SIGAPL to strengthen its position as an organization that sponsors the use of many array programming languages, including APL, J, K, matlab, Gauss, and APLus. In addition, we want to re-activate the relationships with local APL user groups and initiate relationships with users of other APL dialects. Obviously, matlab is very mainstream in several domains (especially related to signal processing). But even in the Python context, NumPy or variants are bringing the power of arrays to Python. See: NumPy for Matlab Users http://www.scipy.org/NumPy_for_Matlab_Users MATLAB® and NumPy/SciPy have a lot in common. But there are many differences. NumPy and SciPy were created to do numerical and scientific computing in the most natural way with Python, not to be MATLAB® clones. FScript tried to bring powerful array concepts to Smalltalk. http://oopsla.acm.org/oopsla2003/files/dem-9.html The OOPAL model, a new high level programming model which unify OOP and APL-like Array programming. So, let me rephrase that as, the appeal of APL, J, K, matlab, Gauss, APLus, FScript and NumPy. :-) Sound slightly more trustworthy? :-) Anyway, my point is that array processing offers yet another paradigm alternative to OOP, and for the right task (e.g. simulating fields of force), it can be a very attractive approach. Of course Python, being very flexible and modular and expandable, gives you a lot of those possibilities without all the line noise. :-) And one might argue, that if you were teaching programming to, say, Astrophysics-interested people, you might be better off focusing on NumPy and doing array calculations using procedural code than talking about all the typical OOP examples of hierarchies of shapes and such. All the best. --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] [edupython] Python in Education Advocacy Article
To clarify, on PataPata, at the moment I am using Jython to prototype a version of a Smalltalk-like system and syntax for the Java (JVM) platform. I am doing this in part to have a system which supports edit and continue, and also in part just because it is fun. I think Java is a terrible language for a human to use because it is too verbose (among other reasons). Still, after ten years, the JVM is a not-that-terrible platform which has the advantage of hype and installed base and can supply about 1/2 C speeds in a portable way. So Java (or JVM byte codes) isn't that awful as a portable machine language -- and it involves less work for a single programmer to maintain a complex application across multiple platforms than for C. Personally, I like Swing, but then, I come from the world (VisualWorks) where most core Swing designers come from. :-) There is no question in my mind that Jython is a much saner way to write code for the JVM than Java in most situations. And Jython is probably a better choice for most JVM things than most of these JVM languages: http://www.robert-tolksdorf.de/vmlanguages.html (unless you already know one of the other languages or have a problem which has a neatly packaged solution in one of those systems). Still, for anything other than writing arbitrary portable fast code (1/2 C) or code that interfaces easily with Java libraries, Python by itself is probably a more reliable cross platform solution than JVM approaches in many situations. In any case, there is still a lot of Python in my own noodling around, at least for now. :-) And also, while I learned a lot about prototypes and their strengths and weaknesses when writing Python code for PataPata to emulate prototypes in Python, if anything, I developed a better respect for how much you could do quirky things in plain old Python when you wanted to or needed to, thus minimizing some of the need to use prototypes for everything. Still, there are always tempting new projects like Factor http://factorcode.org/ which uses FORTH ideals to do amazing things (like with OpenGL) in fairly small footprints and with minimal external dependencies and with fairly few core developer-years of work (though the developers are unusually bright. :-) From the web page: Factor has an optimizing native compiler, automatic memory management with a generational garbage collector, a powerful collections library, and various advanced language features such as higher-order programming, continuations, and extensible syntax. Factor development is done in an interactive environment with a graphical user interface. There is a single-stepping debugger which can travel backwards in time, and extensive documentation. An easy to use C library interface allows one to call C libraries without writing any glue code in C. Bindings for OpenGL, FreeType, X11, Cocoa, and Windows APIs are provided. (I can hope AK's FONC http://vpri.org/mailman/listinfo/fonc http://www.viewpointsresearch.org/html/writings.htm in a few years will produce something even beyond that, if it succeeds). In any case, I see the JVM, Python, C, FONC, Squeak, and Factor as all possible substrates for running a higher level system on top of. A well designed self-reflective system really should be able to run on all of them with appropriate back ends and interface layers. It just requires a higher level of abstraction than, for example, how PataPata already runs on both top of Python/TK and Jython/Swing. And also a willingness to sacrifice some performance in some situations. :-) Right now, on a 3Ghz AMD64, this new VM in Jython is doing about 25000 message sends a second (and about 30K in Python). This is about 1/1000 the speed of C, but I think when the system reflects on itself and can generate pure Java, I am hoping to have it at Python-ish and Squeak-ish speeds of about 1/20 to 1/100 C overall for loops and calls and sends. But given how fast computers continue to get, I'm not too concerned about performance. Even if it remained at 1/1000 C speed, in ten years, that would mean it would run about the speed of C on today's computers -- and there are plenty of interesting applications one can run on today's computers. I also have Jython GUI that lets me single step through hand-compiled code. (None of this has been checked in so SourceForge yet though.) From an educational point of view, looking at such a system and changing it, even if the system was never used for any other activity) could help Python-literate people understand more about message passing and VM construction and (abstractly) how a CPU works. I'm certainly learning something from it. :-) I certainly remain completely pro-Python for commercial development. And I remain pro-Python as the language of choice to teach most kids with at the appropriate age. It's a great language. And a great community. Python generally plays nice with other systems (including C and Java) and looks a lot like what most programmers already
Re: [Edu-sig] Comments on Kay's Reinvention of Programming proposal
Alan- Thanks for the thoughtful reply, including the interesting historical information on earlier Smalltalk VM sizes and also on performances losses with newer hardware and OpenGL's origins. Thanks then too for OpenGL! :-) I wrote the following long essay, but feel free to ignore it as I'm sure you have lots of coding still to do, and I am eager to see the results. :-) Essentially though, I explore whether one can really claim to be reinventing programming while ignoring tackling head on the issues of managing complexity and supporting legacy code. On managing complexity and supporting legacy code: I especially liked your point of: we want to use Math Wins! as the motto of this project. Certainly Moore's law is making it more possible for plain general math to win big, without the clutter of a lot of hand-coded implicit and explicit optimizations (which can be added later as you propose). And certainly Moore's law is only working to benefit existing dynamic systems like Smalltalk and Python as any late-binding performance overhead is becoming less and less important for more and more tasks. Also on math, and on rereading your proposal, it is common, if not essential, for a mathematician to redefine the terms of a problem until it matches something they know how to solve. Sometimes the result is useful -- sometimes it is not. In the realm of science, it is generally always interesting and entertaining though. From: http://www.inf.uos.de/elmar/Fun/light2.html Q: How many mathematicians does it take to screw in a light bulb? A: One. He gives it to six Californians, thereby reducing the problem to an earlier joke... I'll agree that ... the proposal is clear as to its aims, and it is sketchy as to how the aims will be realized That of course is the nature of much research. If it was claiming to be *very* basic research (which the USA has fallen down on), I'm sure it would be sketchy as to its aims too, :-) but then it would be unlikely to get funded these days. And that is why one famous academic I know said he built his basic research career on always submitting grant proposals for the work he was already doing and was near completing, and then using the grant money to do something new and unexpected, which after success became the basis of the next retrospective grant proposal. :-) But he also built his career back in the 1950s-1970s, when funding was more plentiful relative to PhDs. http://www.its.caltech.edu/~dg/crunch_art.html I'll also agree with your sentiment that: The rest of your discussion is orthogonal to the aims of the proposal. But, as you also say: Basically, we think we know how to do the bottom and the top, but the most interesting stuff in the center (how programs are expressed, etc.) is currently described in terms of analogies to good ideas rather than good ideas themselves. It's the stuff in the middle that several of my points are about. From my experience with other projects, including Squeak, I can agree wholeheartedly with with this fragment of the larger Dijkstra quote Ian Piumarta has in his talk slides of: ... we all know that unmastered complexity is at the root of the misery... Of the techniques you outline, which are really directed at managing complexity? Perhaps some will help sometimes (like programming using particles and fields for page layout) but they may introduce their own complexities. And while ignoring the outside world of legacy code leads to a simple set of issues for the design, they also lead the community to have complexity issues of its own maintaining and writing code in all sorts of areas. Where is, say, the broad emphasis on wrestling code complexity to the ground? Or where is, say, a broad emphasis on being able to easily interface with, reverse engineer, and maintain any legacy system in any language on any hardware? Fanciful perhaps to think so big, but is that not what reinventing programming would be about? Especially one that added in the word practical in the subtitle? Or is the proposal more really about reinventing all computers?. :-) which is a great goal, agreeing with your comment on performance loss by poor design by vendors of hardware or software, but still is quite a bit different. I know in practice one needs to draw lines somewhere, and one may have limited resources, so I am not faulting you on having to draw lines. In fact, it's remarkable you drew them as far out as you have! Nonetheless, I'm just playing with the boundaries here -- knowing they are unlikely to change, but doing so both to understand the nature of the problem space better and to understand more precisely what this projects contribution will be, given the provocative title. See: http://www.worldtrans.org/pos/infinitegames.html There are at least two kinds of games: finite and infinite. A finite game is a game that has fixed rules and boundaries, that is played for the purpose of winning and thereby ending the game. An infinite game
Re: [Edu-sig] Reloading code (was Re: OLPC: first thoughts)
the exceptions that bubble up to the top, since a lot of Python code routinely handles exceptions like for not opening a file or when using exceptions to check the duck typing of something, which is why this weaker form would entail extra work). A lot of IDEs for other languages (like C++) let you control what exceptions the debugger breaks on, so this is not that unfeasible. --Paul Fernhout Michael Spencer wrote: Paul D. Fernhout pdfernhout at kurtz-fernhout.com writes: This xreload module Guido supplies is similar to the approach I used for Jython in my earlier link. http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00023.html If you look at that thread, I acknowledge Michael Spencer as having supplied some of the more sophisticated reload logic which is similar to what Guido has posted here (not sure where Michael got it from of course, nor where Guido got xreload from). See Michael's first related post here: http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00016.html FWIW, I still tinker with the reloading issue from time to time, in pursuit of a fully-interactive environment. My latest module is at: http://svn.brownspencer.com/pynote/trunk/Mupdaters.py. It's not documented for standalone use, but may contain some useful ideas, and I'd be happy to discuss it if anyone were interested. Incidentally, class bodies provide one of the hard problems for reloading. Ideally, for reloading, one would execute the class body in a proxy of the existing dict, as for modules, but this can't be achieved with the same exec modulecode in proxyofexistingdict approach. In order to work-around this, I wrote a pure-python compiler. With this, it becomes possible to modify the class definition bytecode to execute the class definitions in the existing class dict rather than a new one. The compiler itself is at: http://svn.brownspencer.com/pycompiler/branches/new_ast/ . However, I have not yet connected it into the reloading module. Michael ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Reloading code (was Re: OLPC: first thoughts)
Oh, what a giveaway! Did you hear that? Did you hear that, eh? That's what I'm on about! :-) This xreload module Guido supplies is similar to the approach I used for Jython in my earlier link. http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00023.html If you look at that thread, I acknowledge Michael Spencer as having supplied some of the more sophisticated reload logic which is similar to what Guido has posted here (not sure where Michael got it from of course, nor where Guido got xreload from). See Michael's first related post here: http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00016.html Notice xreload's update is much smaller than the one I made with Michael's additional inspiration and ideas: http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00023.html In some ways, xreload's is better by including a general Provide a hook for updating concept. However xreload just ignores what to do with top level objects like lists or dicts -- xreload apparently throws away the updates to them. Notice it is not recursive -- for example does it handle nested classes? I'm not sure of all the reasons for the other differences -- it was tricky code I admit I never fully understood how to write thoroughly, mucking about with Python/Jython internals I only hazily understood. And even for the reload code I supplied, it is not always clear what to do with changes to top level objects -- do you want to update them or replace them? If you do update them, how deeply do you want the update to go? Notice xreload still has sections with comments like Not something we recognize, just give up (that's throwing away changes to top level lists and dicts and singletons and such), or Cop-out: if the type changed, give up, and it can not handle in general the issue of side effects I mentioned (e.g. is a singleton instance recreated?). And of course you can't use it to restart an exception after making a change (though it is perhaps a piece of that puzzle). It does however deal with updating pointers to existing function as far as I can tell (so previously set GUI callbacks will still call the old code) -- and does it in the same way the previous code linked to did (e.g. oldfunc.func_code = newfunc.func_code). So, the xreload module Guido supplies is nifty piece of code to have (assuming Python licensed?). Using it properly will make you more productive. However, it still requires building hooks into your application explicitly to call it for each module of interest; the Jython version I supplied includes a brief GUI control window listing all modules which could be made to work similarly under wx or tk. Still, elegant as it is (including the reload hook), even xreload does not handle all the important cases -- just (forgive me :-) the *easy* ones. When Guido supplies an xrestart.py :-) python 2.5 code module that lets you restart exceptions after having modified one of the functions in the stack trace, then I will admit it is something I have never seen before in Python and be suitably impressed. Is it even possible without modifying the VM? :-) There will remain the semantic problem of what to do with top level objects, but as I said, one can avoid that somewhat by just never expecting to reload an entire module at a time -- so using the core of these ideas to reload a method or class (which is what reload does, as it does not update other globals than code related ones). And then, a next bigger step is getting both xreload and xrestart (or related code) into general use into common Python IDEs like IDLE or PyDev. Otherwise, how is a beginner ever going to understand why you would want this xreload piece of code, or how it works, or when to use it? It's one thing to have a bit of code that suggest how something can be done -- it is another to weave an idea throughout a community and a set of application implementations. And the prevalence of those ideas of fine grained changes and fixing code using the debugger and then restarting is a big reason Smalltalk coders are more productive than Python coders, all other things being equal (which of course they are not given licensing, availability, libraries, community, and so on, which is why I use Python instead of Smalltalk. Can't stop pining for the fjords, I guess. :-). One impressive thing about the Python design which I liked from all this was how Python separates the notion of execution code from a pointer reference. That is what makes all these reloading tricks possible. And my hat goes off to Guido for having included the extra level of indirection which makes this feasible. I can hope that generality and late bindingness might also make possible restarting an exception without VM changes. --Paul Fernhout Guido van Rossum wrote: On 2/24/07, Paul D. Fernhout [EMAIL PROTECTED] wrote: To step back for a minute, the fundamental problem here is that for whatever
[Edu-sig] Reloading code (was Re: OLPC: first thoughts)
defining metaclasses to affect future class loading to executing random bits of code (sort of like Forth in this sense). So, only modules without these side effects can be easily reloaded. Consider for example what if your module makes a singleton instance of something -- when you reload it, should it make a new singleton instance and leave the other one to still perhaps be used by old instances, or should the singleton instance get upgraded to the new class? Just one of many issues that happen when you are using Python's textual module reloading paradigm. Ideally, when you change a method in a text file you probably almost always want only that specific method to change with everything else being left alone. But that breaks the Python paradigm. Still, even with this problem, easier class reloading like I outlined above still gets you great value when developing new code, especially if you slightly alter how you layout your new modules with this limitation in mind. But reloading older code may present you with problems -- making maintenance using this technique harder. --Paul Fernhout Andreas Raab wrote: Paul D. Fernhout wrote: This edit and continue support is much more fine grained and easier to use than reloading Python modules, even with the variants I and others have created. Where can I find out more about these variants and what they do? We are currently trying to enable a workflow that centers around a life environment and these issues become important for us. Are there any other life environments (besides Patapata which I have looked at) that are worth studying? ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Reloading code (was Re: OLPC: first thoughts)
kirby urner wrote: On 2/24/07, Paul D. Fernhout [EMAIL PROTECTED] wrote: There may be one major semantical issue, in terms of the meaning of side effects when loading a module (e.g. defining singletons, opening files, etc.) which is hard to deal with generically with Python. You can deal with [it] specifically in how you write your own code, but that is not a general solution. Not sure I follow yet. A module loads top to bottom, with lower defs premised on those previously mentioned. Is that what you mean? Once everything is loaded, it's more like a __dict__, i.e. the namespace of the module of accessible, either via dot notation, or directly if the names are top level. To step back for a minute, the fundamental problem here is that for whatever reason a programmer wants to modify just one method of an already loaded Python class (which came from a textual module which was loaded already), save the change somewhere so it can be reloaded later (overwriting part of the textual module?), and also have the program start using the new behavior for existing instances without any other side effects arising from recompiling this one change. In practice, this is trivial to do in almost any Smalltalk system; it is hard if not impossible to do in any widely used Python IDE or program (even when a Python shell is embedded). Unfortunately, the paradigm used by every Python IDE I've tried is to reload an entire textual module (or more typically, entire program) at a time for even the slightest change to one function. Embedded Python shells generally allow you to redefine a function if you have a copy of the code, but they offer no way to save the code. Most Smalltalks uses a different paradigm, where code is presented to the user one function at a time in a browser and is compiled one function at a time. Yes, there are cases where people filein Smalltalk code defining a complex program, but such fileins are generally considered an *interchange* format, not a preferred program representation for editing unlike as is usually the case with Python. Consider the meaning of an arbitrary piece of Python code near the bottom of a textual module. Essentially, you have no idea what it means if the original author has used some Python bells and whistles. For example, he or she could have defined a metaclass where every nested def under a class was converted to, say, an uppercase string and stored under a key that was the numerical hash of the function name (with no functions actually defined for that class perhaps). The specific metaclass behavior may even hinge on the current state of a global which has been modified several times during the course of loading the module. So essentially, you have no way of knowing for sure what any apparent Python code really means by isolated inspection. And because any module can run any arbitrary Python code, without actually running the Python program (or doing the equivalent analysis), you can never be sure what side effects loading a module has. Now, Smalltalk has metaclasses too, but in practice, because of the way code is presented to the user and edited and recompiled one method/function at a time, the context makes fairly clear what is going to happen when that snippet of code you just changed is compiled. The big difference is really the effective unit of compilation -- the complex module in Python or the simple method/function in Smalltalk. Now, this is rarely a problem the *first* time a module is loaded, but it generally becomes a problem when a module is *reloaded*. If you only treated as module as an *interchange* format, and then modified the live classes using a tool which only works on regular classes (like PataPata does), there is no need to reload the module, so this potential problem related to parsing a modules meaning via an IDE tool remains only potential, and also avoided is the possibility reloading a module might have side effects. (In practice, anything still depends on mapping from a function back to its source text, and this may go wrong for various reasons... :-) Naturally, this kind of major redefinition is rarely done, and it would create lots of confusion, but it is possible, so IDE tools that do not support it are incomplete. This is a perrenial problem with, say, C, where you can make all sorts of macros and so never know just exactly what arbitrary C code out of context does (see the obfuscated code contests...). And it means that you can't get a simple one-to-one mapping of a section of a file that looks like it defines a function and an actual function reliably without analyzing the entire program. Yes, 99.99% of the time Python code does the obvious thing, but it is not 100% certain. The same is true for Forth -- in theory any isolated snippet of Forth can mean anything, since it is trivially easy to modify how the compiler interprets text -- something that make Forth very
Re: [Edu-sig] arthur siegel has passed away
Beth- I just read your note. I am sorry to hear about the death of Arthur. I enjoyed conversing with Arthur via email. We didn't always agree (who does?), but he made a lot of great points and I learned much from reading his writing, including looking back on is contributions for years in the edusig archives. Arthur had many thought provoking things to say, and I am glad he took the time to say them and contribute to a large discussion on computers and education. We were certainly in broad general agreement about the value of learning and a desire to make the learning experience as good a one as possible for as many people as possible. Arthur may not have had the publicly-recognized star quality of some in the computer field (including some whom he critiqued here on the edusig list), but the woods would be very quiet if no bird sang there but the one judged best. Arthur's was an important voice in the wilderness of technology, and it saddens me that I will no longer be able to get his perspective on new technology issues as they arise. Arthur made a positive contribution to education with PyGeo (and I'm sure other things, including his writings to edusig, the archive of which will hopefully continue to echo his voice for a long time to come). I am glad PyGeo is hosted at SourceForge and so will also continue to be available to learners as a monument to Arthur's dedication and caring and generosity and love of learning and love of Geometry. One of the most insightful things Arthur wrote to edusig recently was: : One theme that seems to run through discussions here is related to this : issue. Is it the educators' mission to find just the right motivational : buttons and push them just right ??? Or rather focus on responding : appropriately to those who come to the learning process with some : critical mass level of motivation??? : : It seems to be one of the fault lines, in some of the discussions here. It was a great insight into the nature of education and the soul of the educator and the learner. It is an insight I still need to reflect on more, along with his other writings. Arthur will be missed. Whatever the nature of the great Geometric mystery beyond the end of life in this world, I wish him well. Again, my condolences in this difficult time for you and the rest of his family. --Paul Fernhout Arthur wrote: We wanted to inform anyone familiar with Arthur Siegel's work with PyGeo that Arthur passed away on Tuesday. Anyone interested in more information can email his sister at [EMAIL PROTECTED] The funeral will be at 12:00 at the Riverside Memorial Chapel, 21 West Broad Street in Mount Vernon New York. ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Exploring visible mathematics with IMAGINE: Building new mathematical cultures with a powerful computational system
Just came across this reference which might be of interest to people here: Ivan Kalas, Andrej Blaho: Exploring visible mathematics with IMAGINE: Building new mathematical cultures with a powerful computational system. Learning in School, Home and Community 2002: 53-64 http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/k/Kalas:Ivan.html Link to the first few pages: http://books.google.com/books?id=6smPFdJQy1sCpg=PA53lpg=PA53dq=exploring+visible+mathematics+with+imagine+building+new+mathematical+cultures+with+a+powerful+computational+systemsource=webots=zH27OaC5dlsig=WmPwNW7KL5szKw5SXHu3fzJDnl4#PPA53,M1 Abstract: In our paper we explore how programmable pictures together with events, parallel independent processes and direct manipulation tools can be used for building powerful interactive elements and provide rich environments for exploring basic mathematical concepts. To visualize the concepts we use IMAGINE turtles, the shapes of which are specified in the Logo language. Thus we achieve high interactivity in the resulting microworlds. Children can easily create such objects, control them, combine, move, group, match, etc. We hope that new features of IMAGINE will inspire math teachers and developers to create new visible educational materials. From the book: _Learning in School, Home and Community: Ict for Early and Elementary Education_ Schools, homes and communities, including after-care centres, resource centres and libraries, have increased and acquired more technologies, and a wider range of applications are being used. Research shows that students use ICT differently in each setting. School-based technology use is often viewed by students as routine and disconnected from their interests and abilities. Many teachers are hesitant as to how to teach about ICT and, at the same time, integrate ICT into subject-based learning. Parents and the community-at-large have goals that differ from the goals espoused by teachers and students. This volume highlights the concerns of all - students, teachers, parents, policy makers and the general public.Major themes in Learning in School, Home and Community: ICT for Early and Elementary Education include: *Teachers' and researchers' studies of ICT use in school, home and community. *National strategies and policies affecting ICT use in school, home and community. *ICT tools designed to promote learning and the optimal settings to promote learning. *School and community responses to ICT use that promote the integration of ICT for all members of the community. This volume contains the selected proceedings of the Working Conference on Learning with Technologies in School, Home and Community, which was sponsored by the International Federation for Information Processing (IFIP) and held June 30-July 5, 2002 in Manchester, United Kingdom. Contributions from experts around the world, working as teachers, teacher educators, researchers and government officials, make this volume an essential contribution to the development and implementation of ICT policies andprograms for schools, homes and communities. [Note: Personally I do not think computers an apropriate way for kids to spend much of their time before, say, age seven.] Related with online content: Imagine… a new generation of Logo: programmable pictures http://www.ifip.org/con2000/iceut2000/iceut12-05.pdf http://209.85.165.104/search?q=cache:64_IL0jHjlUJ:www.ifip.org/con2000/iceut2000/iceut12-05.pdf+%22programmable+pictures%22hl=engl=usct=clnkcd=1 In 2000 we completed the development of a new generation of Logo environments containing a radical combination of the direct manipulation interface and rich interactive programming language. Not open source it seems, and so had dropped by the wayside or become marginalized? --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Tracing the Dynabook: A Dissertation
Bert Freudenberg wrote: Btw, I hope that we might get a bit closer to this on the OLPC UI - at least it is running in Python, you have that view source key on the keyboard, so the necessary ingredients are there. It's just hard to get people to even *imagine* that something this powerful is actually doable. While it is not progressing at the moment, check out the PataPata environment for Python I developed to see what is at least a proof-of-concept of this level of interaction in Python. http://patapata.sourceforge.net/ http://sourceforge.net/projects/patapata http://sourceforge.net/project/showfiles.php?group_id=165910 It allows one to browse and modify the code of a running world of objects (using either tk or Swing as the interface). The screencasts done by Francois Schnell showes an earlier version in action, see for example: http://francois.schnell.googlepages.com/patapata or: http://showmedo.com/videos/video?name=patapata_tkinter1_fSchnell I think if I took PataPata further, I might de-emphasize the prototype-oriented aspect of it in favor of classes, while still trying to retain PataPata's capability of having an image or world of live objects stored as Python scripts that rebuild the objects of interest. I would certainly emphasize any changes to Python needed to easily debug into a function, change it, and restart it (which is at the core of a lot of Smalltalk productivity). I had earlier made support for that for plain Python (mostly in Jython, posted to that list) but it would be nice to see such support much better integrated into the base Python -- as a PEP perhaps? (And this suport is a lot more fine-grained than module reloading...) I think making easy and widely available this support for easy debugging into a function and changing it and restarting all in a still running application would be of great value to anyone learning through tinkering with a Python-powered application (like an educational simulation). And it would increase Python programmer productivity when developing medium to large applications probably by a factor of at least 2X or 3X. --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Edusig auf Deutsch [in German] using Babelfish
Bert- Just for fun, here is a link through Babelfish for edusig auf Deutsch: :-) http://babelfish.altavista.com/babelfish/trurl_pagecontent?lp=en_detrurl=http%3a%2f%2fmail.python.org%2fmailman%2flistinfo%2fedu-sig See for example: [ Edu-Edu-sig ] Slashdot Artikel: Programmieren Zicklein Jedoch? http://babelfish.altavista.com/babelfish/trurl_pagecontent?lp=en_deurl=http%3A%2F%2Fmail.python.org%2Fpipermail%2Fedu-sig%2F2006-April%2F006308.html Or January's posts: http://babelfish.altavista.com/babelfish/trurl_pagecontent?lp=en_detrurl=http%3a%2f%2fmail.python.org%2fpipermail%2fedu-sig%2f2007-January%2fthread.html I'd be curious what a native German speaker had to say about the quality or usefulness of these automatic translations of edusig? Useful? Confusing? Useless? --Paul Fernhout Bert Freudenberg wrote: Am Jan 18, 2007 um 6:45 schrieb Paul D. Fernhout: so no matter how cheap you made distributing a diversity of text books or related educational materials, schools would not want any but the standardized ones to be used at the standardized times. The point of conventional schooling was then ansd still is to produce a standard graded product, not amplify differences. As I point out in my previously linked essay Why Educational Technology Has Failed Schools http://patapata.sourceforge.net/WhyEducationalTechnologyHasFailedSchools.html computers linked to the internet have revolutionized just about every area of life today related to information access and education -- except, ironically, schooling. I think there is a reason. Schools are *actively* in the way of everything the better side of the world wide web promises -- diversity, expression, disintermediation, innovation, etc. Hi Paul, I *very* much enjoy reading your thoughts on technology and education. I wish they were in German, to be able to show them to people here ... Do you know any German writer with similar views? - Bert - ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] An OLPC comment (Why Educational Technology Has Failed Schools)
I guess you have your work cut out for you then to write one. :-) Thanks for the comments on Babelfish. --Paul Fernhout P.S. I did find that John Holt's _How Children Learn_ has been translated to fourteen languages -- not sure what they are though: http://www.holtgws.com/johnholtpage.html You also might find this to have interesting links: http://sandradodd.com/unschoolingotherwise According to that: Germany Although homeschooling is not legal in Germany at this time, there is a new web site for promoting respectful parenting and natural learning in Germany. Mit Kindern leben und lernen it's in German http://www.unschooling.de/ German Unschooling list Mostly ... German with a few Austrians and a handful of Dutch and English readers [EMAIL PROTECTED] Poking around at the unschooling.de URL, I found: http://www.leben-ohne-schule.de/deutschland.html I would think someone in there are bound to be links to people writing about technology and education in a German context, as there is some intersection. There are also some links here, of course, mostly to German news articles: http://wiki.laptop.org/go/OLPC_Germany Example: http://www.computerpartner.de/news/203352/ Then there is also Skolelinux Germany: http://www.fsfeurope.org/projects/education/tgs/tagatschool8.en.html Might be some discussions related to that in German? A related wiki: http://wiki.skolelinux.de/ My German from school is very rusty, so I can't easily be of more help; sorry. I would think searching on John Holt for his later writings might get you some interesting things though. Also, one more thought: http://en.wikipedia.org/wiki/List_of_Sudbury_Schools The following schools follow the Sudbury model of non-compulsory, democratic education, pioneered by Sudbury Valley School: [One in Leipzig, Germany] http://www.sudbury-hl.de/ Maybe some links from there or people to talk to about technology and education (especially if you are anywhere around Leipzig, Germany)? I know that unschooling or homeschooling is generally not as available in Europe as in the USA, but I also think that alternative schools, like Montessori, Waldorf, or the Sudbury model are perhaps more common (as you yourself discovered already). Personally, I think the Free school model is the most workable compromise given today's society, and if I lived in Europe I would be thinking more about those. I'd even consider it if my family lived nearby one here in the USA. I guess there is something I can thank the USA's social conservative movement for -- homeschooling laws making unschooling possible. :-) I can't imagine how much fun it would be to teach Python in such a setting, where if the kids are working with you they are doing it out of genuine interest (even if it might not be long lasting). Those schools tend to expect more parental involvement in the schools, and I know if I sent a child to one, as a parent, I'd want to be offering Python (or Squeak) programming experiences to all the kids there as a volunteer. Bert Freudenberg wrote: Thanks Paul, I know of Steiner, we have a son who went to a Waldorf school. We choose a Montessori school for our other kids, which I like much better. Anyway, I was specifically looking for someone both knowledgable in education *and* technology, and writing about the intersection of the two. ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] An OLPC comment (Why Educational Technology Has Failed Schools)
Art- It is funny to see the learning just in case educators crying out for more testing just in case. Like the Albany Free School, or John Holt, or The Hole in the Wall project or various other success stories relating to learning on demand which the OLPC project supports did not exist. No amount of testing will ever be enough for those who use testing as a way to hold people back and keep them in a lower class. :-( From: http://www.newciv.org/whole/schoolteacher.txt The second lesson I teach is your class position. I teach that you must stay in class where you belong. I don't know who decides that my kids belong there but that's not my business. The children are numbered so that if any get away they can be returned to the right class. Over the years the variety of ways children are numbered has increased dramatically, until it is hard to see the human being plainly under the burden of numbers he carries. Numbering children is a big and very profitable business, though what the strategy is designed to accomplish is elusive. I don't even know why parents would allow it to be done to their kid without a fight. In any case, again, that's not my business. My job is to make them like it, being locked in together with children who bear numbers like their own. Or at the least endure it like good sports. If I do my job well, the kids can't even imagine themselves somewhere else because I've shown how to envy and fear the better classes and how to have contempt for the dumb classes. Under this efficient discipline the class mostly polices itself into good marching order. That's the real lesson of any rigged competition like school. You come to know your place. I don't in general disagree with the notion that empiricism and testing as part of either engineering or science can be useful. But there are still aspects of garbage in / garbage out when doing testing in relation to the testers' assumptions, methods, and biases. And testing can also be just a big waste of time if you test for the wrong things -- for example, what do higher test scores really prove about whether people will be happier or whether some part of society will be better off (economically or spiritually)? Consider, how do you test for character or imagination or virtue? And how do you test for people who won't put up with BS of taking too many tests or being asked to jump through too many hoops? :-) Historically, if you measure programmers on, say, lines of code, you may get a lot of lines of code but poorly running and hard to maintain programs. Same too for testing kids for grades -- maybe you get high graders but little else. Consider the goal of Computer Programming For Everybody -- to make people more comfortable and in control of their increasingly computerized environment -- it's hard to put a number on someone's sense the importance of that or when it has been reached. There is some fancy sounding statistical term for numbers not being connected with the reality you are interested in but I forget it off-hand. :-) On the larger issues, see this essay I recently wrote which supports Negroponte's position indirectly: Why Educational Technology Has Failed Schools http://patapata.sourceforge.net/WhyEducationalTechnologyHasFailedSchools.html That essay could be considered supporting Alan Kay's suggestion that the computer revolution hasn't happened yet. http://squeakland.org/school/HTML/essays/face_to_face.html Essentially I explore whether computer technology which enables learning on demand has made learning just in case compulsory education obsolete. --Paul Fernhout Arthur wrote: Hate being the grunch. I hope the OLPC accomplishes everything it sets out to and more. What I suspect is that - having learnt something about complexity and dynamic systems from computers - that the most profound effects of the initiative will be unintended ones. Let's hope they are mostly good. Particularly given this, I don't understand the embedded need, as part of the process, to the compromise on some basic ideas - normally called science. We - on edu-sig - were trying to form some consensus on the need for empiricism around these issues. And in his own way, by my reading of events, my erstwhile friend Kirby was trying to suggest something along these lines during his participation at the Shuttleworth summit. Or - maybe more what he was suggesting - is that until there is empricial evidence that leads us in a certain and clear direction, best encourage the diversity of ideas. OLPC seem to represent very much a counter vision. Seems to me the OLPC has counter ideas on both empiricism *and* the diversity of ideas. Here is Nicholas Negroponte's reaction to the idea of bringing empricism to the party. http://www.olpcnews.com/implementation/plan/implementation_miracle.html So there will not be consensus, apparently, Art
Re: [Edu-sig] An OLPC comment (vs. Apprenticeship)
Art- I think one issue is here is the difference between apprenticeship and teaching. Perhaps there is a middle position of mentoring between those too, as apprenticeship can often be exploitive, plus take many years. One of the best ways to learn a skill (like programming) might be to be apprenticed to someone who does it to some useful end. For example, I learned much about computers in high school working (for pay, outside of school hours) for a teacher who had an educational computer company. He didn't teach me much directly, but he provide me documents and hardware and reasonable challenges and experiences and time which helped me grow as a software developer. Still, two other high school teachers provided me access to computers as well to a lesser extent, and I was also aided by my father's support of my earlier IC electronic hobby and subsequent computer activities, including buying a KIM-1, some books at a computer fair, and then a Commodore PET with printer and disk drive. It's hard to remember how difficult *access* was to computers in the USA way back when in the 1970s. But obviously that difficulty still exists in much of the world for many people. I am happy to agree that human apprenticeship (or even mentoring) is more powerful than a sink-or-swim approach of just connecting a kid with some technology or a hole in the wall: http://www.hole-in-the-wall.com/ -- as far as learning effective skills as part of a larger liberal education including values and strategies. When I read of the experiences of many other programmers who grew up around, say, Palo Alto (Xerox) or Yorktown Heights (IBM), I can see the tremendous advantages they had being part of such cultures and being able to learn from others. Consider, for example, Bill Gates, who learned to write better code by reading the operating system code listings thrown in the dumpster at a computer center: http://www.dynamicobjects.com/d2r/archives/002646.html Not that he would extend that privilege to others, of course. Contrast that to me at the one time I went to a local computer users group meeting as a kid and the person with a print out of the FORTRAN source code for Adventure would not let me look at it. So, these people who were close to such industrial or adult activities had big advantages. When people are put in a role of being a teacher, and they bring a personal enthusiasm for their subject, that enthusiasm can carry over into aspects of apprenticeship despite operating in a conventional classroom. Kirby U. here sounds like he does that. But, there is no realistic way a person can really have 30 apprentices, let alone 150 as is typical in high school (one teacher with five classes of thirty kids each). One or two apprentices is quite doable, even up to five, maybe. Much more than that, and at best you have a pipeline (like the one room schoolhouse) where the older apprentices teach the younger, as a sort of learning community. But the big difference is that with apprenticeship there is generally some easily measurable economic goal (or at least, someone one, the master) who is assumed to be in a good position to judge the apprentices output in terms of usefulness or craft. This is not always the case, since obviously apprenticeships can go bad, and some acclaimed masters are that way for bad reasons. But in general, apprenticeship is how most people have learned most complex skills for most of history -- well, that coupled with trial-and-error coupled with reading. Learning skills mainly from books or lectures is likely a very recent thing. Listening to people stand and talk has a place in human society -- but it often is more by way of story telling and communicating history and values through entertaining story. So perhaps if one wants a coherent alternative to a constructivist vision of OLPC and Kay and Papert and so on -- perhaps pushing apprenticeship (like to learn Python) is a positive alternative? However, schools typically do not have apprenticeships, in part because of child labor laws intended to protect children but which sometimes may harm them. Gatto talks about this from his own experience hooking kids up with apprenticeships only by breaking the rules: http://www.johntaylorgatto.com/chapters/4e.htm http://www.johntaylorgatto.com/chapters/5j.htm But he values other types of experience as well: http://webseitz.fluxent.com/wiki/JohnTaylorGatto --Paul Fernhout Arthur wrote: What I hear when I look over the Squeak shoulders is that of course we are not claiming that any of this is a substitute for an involved, caring, creative teacher working in a caring, creative environment. But given such a teacher in such an environment do you really suppose that Squeak, or the OLPC, or Python, or PyGeo, or PataPata is actually of much importance? I don't. My interest in computers and education is almost 180 degrees away. I am not convinced that they have any fundamental importance in
Re: [Edu-sig] An OLPC comment (Why Educational Technology Has Failed Schools)
Laura- That's a good sentiment to use testing to see how we the tester is succeeding at communicating. I totally agree with the benefit to any presenter of feedback about whether the audience gets what they are trying to present. Refining presentations and presentation skills is important. On the other hand, textbook authors or other non-fiction authors refine their presentations all the time without testing readers. They use other means (peer review, editors, focus groups, direct feedback on previous editions by readers, and so on). Would you buy a non-fiction book if you knew after each chapter someone would quiz you for fifteen minutes so the author could maybe make that chapter better? As an adult, you'd probably buy another book. A seemingly short ten minute test of a class of thirty uses up 300 life minutes, or five life-hours. Does a presenter have any clear right to those five life hours per test? Perhaps those life-hours could be spent more productively (like directly by the presenter in refining their presentation in other ways?) Personally I love written tests, or at least used to; so how the individual student experiences a test might vary, depending in part on attitude (and also a variety of other factors). Also, consider, on a practical basis, what is most important to teach is often attitude. That's why the suggestion is to only praise effort (I saw you tried hard!) and, perhaps, incremental progress (You're getting smarter every day!). See for example: Five Reasons to Stop Saying Good Job! http://www.alfiekohn.org/parenting/gj.htm In the case of Computer Programming for Everybody the right attitude probably includes thinking you can understand some software component, or replace it, or make it better. For example, one thing that in the 1980s used to mark a good UNIX systems administrator was a willingness to consult the man pages for new commands; that was the only common thing about them in one study. It did not really matter how much they could recall about any command on a test. How do you test for attitude? I would think most good teachers don't need a written test for attitude of a student -- and would not even trust a written test as they get a lot of feedback from reading body language. And they can get that body language feedback even while presenting (not afterwards). Sure, you can test skills perhaps. You can test aptitude. But how do you really test attitude on a practical basis, other than by being in a person's life and watching them in a variety of situations? Of course, you could try to formalize this the way, say, a behavioral ecologist scores actions of monkeys in a troupe (one grooming behavior, one eating behavior, etc.) but is there really much value in that? It's not a very human way to relate to other humans. Sure, anthropologists may do it, but people trying to communicate and mentor? Seems like a bit of a distraction if done regularly. Consider Gatto's more general comment on testing here, to see where the slippery slope of numerical grading heads: http://www.johntaylorgatto.com/chapters/18t.htm [I recommend to measure] performance with individualized instruments. Standardized tests, like schools themselves, have lost their moral legitimacy. They correlate with nothing of human value and their very existence perverts curriculum into a preparation for these extravagant rituals. Indeed, all paper and pencil tests are a waste of time, useless as predictors of anything important unless the competition is rigged. As a casual guide they are probably harmless, but as a sorting tool they are corrupt and deceitful. A test of whether you can drive is driving. Performance testing is where genuine evaluation will always be found. There surely can’t be a normal parent on earth who doesn’t judge his or her child’s progress by performance. So, how about performance testing as an indicator kids are learning some specific skill? For computer programming for everyone, perhaps it could be to write a program that does some task, and watch them do it? This is the kind of continual feedback one gets on presentations based on working with kids in the computer lab afterwards. Also, does it really matter if kids are learning what anyone is specifically trying to teach them at the time? Why should it matter? Kids are Learning all the Time, to quote John Holt: http://www.holtgws.com/learningalltheti.html http://www.amazon.com/Learning-Time-John-Caldwell-Holt/dp/0201550911 So what if they don't learn what you want them to know when you want them to know it? Surely, if the environment is interesting enough, they are learning something. The need to test to ensure learning is a denial of people as learning creatures, who learn in their own ways, on their own timetables. Does a library give you a grade for each visit? Does a museum? Does your web browser? Does anyone deny libraries or museums or web browsers can
Re: [Edu-sig] Learning (some more) programming
Paul D. Fernhout wrote: Arthur wrote: One theme that seems to run through discussions here is related to this issue. Is it the educators' mission to find just the right motivational buttons and push them just right ??? Or rather focus on responding appropriately to those who come to the learning process with some critical mass level of motivation??? It seems to be one of the fault lines, in some of the discussions here. You're right; this is very insightful. Bad form to reply to myself, I know, but on reflection, I realize there is at least one other obvious alternative. One can also try to change the system to lower the bar. So, here are some options, if you think of learning to program in Python like learning to jump over a high bar. 1. Motivate kids to want to try really hard and jump over that bar (perhaps using operant conditioning like training dolphins, perhaps just making the value of jumping over the bar so compellingly obvious like the value of driving in US society, or perhaps by wrapping the subject matter in something a kid will find more interesting like a game or contest or story or artwork). This is conventional schooling and even conventional homeschooling at its best -- and is based on *extrinsic* motivation. (*) 2. Leave a bar around, and wait however long it takes until a kid really wants to jump over a bar, and then make any help available to him or her they want right then (just in time learning). This is the unschooling approach, and it is also the approach of free schools. 3. Compel or coerce the child to jump over the bar by whatever unpleasant means is acceptable -- threat of the police or parents, threat of withdrawal of privileges, using peer pressure and related threat of humiliation, or alluding to some long term failure to find a job and succeed in life out of school. This is conventional schooling (or even conventional homeschooling) at its worst. 4. Lower the bar. This is the technology developer point of view (the one I usually have). 5. And as I reflect more on it, here is a fifth options. You could also change the task of jumping the bar into something the kid wants to do from *intrinsic* motivation. This merges somewhat into point #1, except it builds the feedback into the process directly. So, for example, you could put up all sorts of numerical feedback about each jump and plot a kids increasing jump height against on a big graph so they can see their progress jump to jump (with no praise per jump needed, except maybe for effort or progress). (Hard to know how to do this in a programming IDE? Perhaps length of programs? Or how often you go between syntax errors?) Or, for a high tech approach to jump training, perhaps you put up a smoky fog with a laser border shining on it to show a target area to jump though and then laser illuminate the area the kid actually jumps through (perhaps without the bar being there at first), or some such thing. (For programming, this might be some fancy system to give you metrics about programs you write: like on complexity or simplicity or elegance -- which are hard to think of, especially as aesthetic evaluation of programs is perhaps hard to formalize.) So, you are changing the nature of the task into one where there is continuous feedback of some kind the kids intrinsically wants to excel at even if they don't like the original task in its own right. Great teachers in any setting tend to naturally think about their material in this fifth way, I would expect -- assuming they don't otherwise just convey enough excitement to get kids hooked on the subject matter in its own right out of intrinsic interest in, say, the feel of jumping well. In the case of our gardening education work, we could have written a gardening curriculum that kids had to study and answer multiple choice questions about, giving out gold stars (extrinsic motivation) for success. Or we could, as we did, make a virtual microworld where they could succeed or fail on their own, where motivation is *intrinsic* from seeing plants grow and harvesting the results, and which might then motivate them to read about gardening from other sources (books, peers, mentors, trial and error, the help system, etc.) in order to make their virtual plants grow better. Now, I think our garden simulator fails at being intrinsically motivating as much as we wanted it to be for various reasons (it's both too confusing from having too many features while also missing some other key features) but I think the *intrinsic* motivating approach was otherwise sound. As primarily a software developer, I think of options #4 and #5 as the ones I explore. :-) I think the fourth option of lowering the bar (as well as sometimes the fifth option of changing the bar) is where I always get into disagreements with Kirby here. He maintains the bar is low enough and intrinsically interesting enough (that is, Python is adequate to use
[Edu-sig] Python Smalltalk (was Re: OLPC related: pyGTK)
[EMAIL PROTECTED] wrote: Squeaks pretense issues, and its licensing issues, are - by the way - not unrelated when you look at it. Sometimes I think something like that myself. :-) But, to elaborate on your point a little more (in a toned down way :-): Smalltalk came out of an industrial research lab (Xerox PARC). The people who invented and then built it and refined it were paid industrial employees working in the scope of their duties on company time (though very unusual ones, even by such RD standards. :-) Its subsequent history for decades involved mainly development by commercial organizations (either as Smalltalk or also as the Macintosh OS which in some sense was a Smalltalk-derivative, but Steve Jobs just got the window system because he left too soon. :-). http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html One of the best parts of the [1979] demo was when Steve Jobs said he didn't like the blt-style scrolling we were using and asked if we cold do it in a smooth continuous style. In less than a minute Dan found the methods involved, made the (relatively major) changes and scrolling was now continuous! This shocked the visitors, espeicially the programmers among them, as they had never seen a really powerful incremental system before. And: http://americanhistory.si.edu/collections/comphist/sj1.html Steve Jobs: ... That's the real gem. I'll tell you an interesting story. When I was at Apple, a few of my acquaintances said You really need to go over to Xerox PARC (which was Palo Alto Research Center) and see what they've got going over there. They didn't usually let too many people in but I was able to get in there and see what they were doing. I saw their early computer called the Alto which was a phenomenal computer and they actually showed me three things there that they had working in 1976. I saw them in 1979. Things that took really until a few years ago for us to fully recreate, for the industry to fully recreate in this case with NeXTStep. However, I didn't see all three of those things. I only saw the first one which was so incredible to me that it saturated me. It blinded me to see the other two. It took me years to recreate them and rediscover them and incorporate them back into the model but they were very far ahead in their thinking. They didn't have it totally right, but they had the germ of the idea of all three things. And the three things were graphical user interfaces, object oriented computing and networking. Let me go through those. Graphical interface: The Alto had the world's first graphical user interface. It had windows. It had a crude menu system. It had crude panels and stuff. It didn't work right but it basically was all there. Objects: They had Smalltalk running, which was really the first object-oriented language. Simula was really the first but Smalltalk was the first official object oriented language. Third, networking: They invented Ethernet there, as you know. And they had about two hundred Altos with servers hooked up in a local area network there doing e-mail and everything else over the network, all in 1979. I was so blown away with the potential of the germ of that graphical user interface that I saw that I didn't even assimilate or even stick around to investigate fully the other two. Essentially Xerox Parc in 1976 (thirty years ago!) invented the computing landscape most of us use now, and Alan Kay was part of that. What we have seen since is mainly just the dispersal and magnification of those ideas (often in a warped or dumbed down fashion, e.g. C++ instead of Smalltalk; XML instead of Lisp). Smalltalk's demise as a major player on the commercial scene in terms of VisualWorks and its predecessor ObjectWorks (*the* leading Smalltalk product, and still the most comprehensive and definitive and most cross-platform -- excepting perhaps Squeak is more cross-platform in theory) was mostly due to greed and mismanagement IMHO by a now defunct company (the current VisualWorks owners bought it cheaply from them). IBM's VisualAge Smalltalk's demise, on the other hand, was mostly due to IBM's decision to back Java (shortsighted and unfortunate I think as IBM had the clout to push Smalltalk syntax through to the masses IMHO). Smalltalk is still actively used by many, but is more of a niche player at the moment (like, say, OCaml or Haskell or Common Lisp), having been eclipsed by Java. The support community for Smalltalk was (at first) mostly commercially oriented, and remains so to some degree. While there were academic users, and in the past decade, especially with Squeak, the number of people using it for academic or free or open source type applications has grown, that has not been the bulk of the history. Even Squeak's most recent evolution was driven by work at Apple and then at Disney, with the Smalltalk principals reprising their roles as employees of large industrial research and
Re: [Edu-sig] Python Smalltalk
; it certainly also would not play well politically in terms of negative PR to the vendor. In some ways, in the end, this single issue may mean the death of free Smalltalks long term (barring one major vendor freeing their version) -- the fact that Smalltalk was open source (taken literally) embodied in proprietary products for so long but not free. Which is one reason Richard Stallman dislikes the term open source as it deemphasizes the freedom aspect. :-) In essence, the history of Smalltalk is brilliance shackled. Since its conception, the history of Python is pragmatism unshackled. :-) Still, I abhor having to, like Daedalus, turn away from brilliance for pragmatic reasons, even though I know what happened to his son Icarus when he did not. :-) http://thanasis.com/icarus.htm Especially considering Python was designed as a workhorse, and Squeak was supposedly designed for kids and education (both the focus of this mailing list, and an interest of mine). [Of course the metaphor is inverted here since Smalltalk is really the older of the two and if anything more like conceptually the father of Python. I need another myth where the father encounters disaster the son avoids because the sun is plugged into a different community spirit or Zeitgeist. :-)] --Paul Fernhout Arthur wrote: Paul D. Fernhout wrote: [EMAIL PROTECTED] wrote: Squeaks pretense issues, and its licensing issues, are - by the way - not unrelated when you look at it. Sometimes I think something like that myself. :-) But, to elaborate on your point a little more (in a toned down way :-): It is hard to know how to respond. I don't know how to tone down on this particular issue any more than I have. If you want to call it an obsession, OK. You can search the archives of edu-sig and find me obsessively attacking Kay and not Squeak itself, but Kay's positioning of Squeak, from the earliest days here, and suffering attacks here for doing so as: a) being presumptuous. b) being irrelevant. Let's leave it that I fully accept the standard history, the importance of Smalltalk, the role of Kay during the period of history which you recount. And the fact that he is un-shy about recounting it, and having others recount it on his behalf, provides him with certain powers, but with certain responsibilities. I am not a fan of how he has handled that power and those responsibilities. But that if I have not yet successfully communicated why I firmly believe his later efforts, his later approach and most particularly his later rap is more destructive than productive, I guess that I have to resign myself to the fact that I never will. I assure you, I am making perfect sense to myself - however. ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Python Smalltalk
Arthur wrote: My point was only that Paul is saying that Smalltalk was developed specifically for children. It is never fully clear to me in conversing with Paul whether he means for children to *write* or for children to reap the benefits of what can be accomplished by adults that can. If I have been unclear on this issue it was unintentional. Smalltalk, according to its creators, was always first about kids being able to write their own programs. http://portal.acm.org/citation.cfm?id=155364dl=ACMcoll=portal However, another issue is kids being able to understand and extend the work of others, and that brings one further into the second category you mention; they are not completely disjoint. In fact, most work done in a Smalltalk image is generally adapting other people's work to your current needs. Very rarely is stuff written completely from scratch. Libraries and classes arr reused; one often starts from working running application, say, a paint program) and makes incremental changes until it is more what you like, say, a program to design maps. Also, Kay, as in his 1972 paper of the title, seems to sometimes use phrases like: A personal computer for children of all ages. So, you see he is playing fast and loose with what it means to be a child, perhaps often meaning not age but a state of mind, as in child-like or playful. However, you would be right to call Alan Kay on what for children means, as you have in the past. Even he has said in public lectures (jokingly) that the way to get money to support work on new programming systems that are easier to use is to pitch them as if they were for children (since everyone wants to make things easier or more possible for kids), whereas if you pitch work to make programming easier for adults, at least historically he says the response is something like (not his exact words), well those engineers should just suffer and use what we have right now, what do we pay them for anyway? :-) I think he did find an interesting and effective sales pitch to continue his work, which I think is broader than just for people of, say, the five to fifteen year old range. I think he genuinely does want better to use systems, if for no other reason than so he can use them himself for example. But I see nothing wrong in that -- much software gets developed because someone wants to develop it to scratch a personal itch. However, Alan Kay, having said *something* like that is still somewhat wrong about that. There are, at least now, two reasons better programming languages get built.One is that people just build them for personal or academic reasons. The other is that people make arguments based on programmer productivity (e.g. Jython developers are, say, 4X more productive than Java programmers :-). You are also right to question Constructivism as an ideology, methodology, or so forth, on the general grounds it is good to be skeptical of anything people pitch for kids for any reason; still, that is where we part ways obviously, since I do see the value in a constructivist approach towards education, meaning, present kids with tools and objects they can use to build things with and hope learning occurs for many if they are ready; present them with things they can take apart to see how they work (say, working drawing program), and let them take them apart or change them if they want. And your PyGeo http://pw1.netcom.com/~ajs/ is a great example of that kind of constructivist tool Alan Kay and Seymour Papert and so on would admire as a Geometry Microworld. [Ducks. :-)] See: The Turtle's Long Slow Trip: Macro-educological Perspectives on Microworlds. http://www.iaete.org/soapbox/microworlds.cfm (Also note that Papert believes in both Microworlds (much about little) and Hyperworlds, the World Wide Web being an example of the second -- (little about much, or in his words: large world of.. loose connections). http://edtechlife.com/files/Wagner_Mark_KAM_II.pdf That does not mean other forms of education are invalid. Some people learn better by other channels, some people have different interests or needs, everyone benefits from reading the appropriate books or tutorials at certain times which are essentially mini lectures, and so on. Personally, for younger kids, I am leaning more and more to media restriction in the early years (say, five to seven and under) as a very good thing. See for example the Waldorf policy on that: http://www.openwaldorf.com/media.html http://www.waldorfhomeschoolers.com/media.htm From the second link: We KNOW the facts and the facts are that CHILDREN HAVE ABSOLUTELY NO BUSINESS TO SPEND TIME IN FRONT OF A TELEVISION SET OR COMPUTER SCREEN. That's it. So the Waldorfers might lump your PyGeo and Alan Kay's Squeak into the same boat, both problematical from that point of view. :-) My position is not as extreme as theirs, of course. :-) In the end, perhaps what you may smell
[Edu-sig] Constructivism (was Re: Python Smalltalk)
[EMAIL PROTECTED] wrote: But the fact remains that the only thing I have be willing to say about PyGeo with any sense of definiteness is that *building* it was an extraordinary learning experience. And I can say a similar thing about our (free, GPL) Garden Simulator. My wife and I are the people who learned the most about gardening (and software design) by spending over six person-years building it. And I think others, even Papert or Kay, would agree with that. Using a Microworld is a different (and usually lesser) experience than building one. Or, as is often said, if you really want to learn a subject, try to teach it. :-) On the other hand, you sometimes use a microworld for a different reason than you build one. If you just want a taste of a subject, or to get a hint or even a basic command of the big ideas in it, then learn using a microworld. If you want to really understand a subject in depth, or at least learn what is easily known and unknown about it, then try to build a microworld. :-) Though I am confident that just the right person, at just the right time, with just the right background, and just the right motivation would gain much from exploring and using it. Yes, that is the core of a movement like Unschooling. http://www.holtgws.com/whatisunschoolin.html Or as Holt or Gatto puts it, when a kid is ready and motivated, it only takes about a hundred contact hours (perhaps much less) to teach them enough about letters and words for them to then be able to bootstrap themselves by themselves through reading to as high a level of literacy as they can or desire to achieve. So too for basic math. I would guess the same might be true for programming with, say, Python or Smalltalk. But if the kid is not interested, you can spend thousands of hours trying to teach them to read or do math or to program and they never will learn those things (which is exactly why schools graduate functional illiterates and even more innumerates, even at a huge expense in dollars and student life-hours). Ask *any* teacher what a dream their classrooms would be if only the kids who wanted to be there were the ones there. In an exchange with Kirby a long time back on this list, we agreed that the potential of computers includes having learning labs in schools where kids can approach subjects as they want to. I think where I differ from many others is saying that, unless schools change radically, that sort of learning lab is not going to happen (at least in any meaningful way using a great deal of a student's time). The only schools I know of now that would permit such thing are the few free schools, like this one: http://www.albanyfreeschool.com/ General info on free schools: http://en.wikipedia.org/wiki/Free_school The issue is not one of technology or tools (Kirby is right to say we have enough of them, even as I think they could be better); the issue is one of philosophy. And that is why I have greater hopes for an effort like Sugata Mitra's hole in the wall projects: http://www.greenstar.org/butterflies/Hole-in-the-Wall.htm over Mark Shuttleworth's initiative http://www.shuttleworthfoundation.org (as noble as his intent may be, because ultimately he is up against bureaucratic pressures which he will likely be unable to overcome with a small effort, as so many have tried and failed before, including many, like John Holt, with much more inside knowledge of how schools work now). Still, I wish all such efforts well. But feeling that current schools cannot be fixed is no longer such a radical opinion -- consider this recent mainstream report, just out: To fix US schools, panel says, start over http://www.csmonitor.com/2006/1215/p01s01-ussc.html From there: What if the solution to American students' stagnant performance levels and the wide achievement gap between white and minority students wasn't more money, smaller schools, or any of the reforms proposed in recent years, but rather a new education system altogether? That's the conclusion of a bipartisan group of scholars and business leaders, school chancellors and education commissioners, and former cabinet secretaries and governors. They declare that America's public education system, designed to meet the needs of 100 years ago when the workplace revolved around an assembly line, is unsuited to today's global marketplace. Already, they warn, many Americans are in danger of falling behind and seeing their standard of living plummet. See also Time: How to Bring Our Schools Out of the 20th Century http://www.time.com/time/nation/article/0,8599,1568429,00.html The organization coordinating the report: http://www.ncee.org/ The report itself: http://skillscommission.org/executive.htm Of course, I do not think they go far enough in their proposals, from what I have read of the summary. :-) *One* answer seems simple enough to me -- just look at how the Albany Free School operates and duplicate it. :-) That's a no brainer. There
Re: [Edu-sig] OLPC related: pyGTK for cross-platform (Mac especially)?
Arthur- Wow, thanks for the link (and thanks also to you and Ian for the other comments). This is a little like what I tried to do with the PataPata OpenGL window, but that never went very far. Wonder if this system would easily work on the OLPC system? The key point for me (as a lazy programmer :-) is maximum effectiveness for least effort. It's one thing to build a proof of concept or something fun for oneself, but when one starts thinking about how does the biggest audience share what you have made, then the issue becomes ease of installability and how open the license is and how likely the effort will not have legal problems. (On your other post, Squeak has some licensing issues still in flux; it's hard to assess how they will come out as they are not *fun* to deal with for most programmers; Python's legal situation seems much clearer). By the way, in outlining the programming style that makes you smile, you just rediscovered Squeak. :-) The ability to work in Smalltalk all the way down and into the VM is what many people like about it. When working in Python I keep hitting these brick walls or black boxes of the compiler or window libraries which require switching languages and development environments. Now if they could just solve licensing and modularity issues as well as Python had. --Paul Fernhout Arthur wrote: Arthur wrote: Like offering alternatives. Like this new-on-the-scene effort http://pyglet.org/ Pyglet is a cross-platform multimedia library written in pure Python. Checked out the svn version. Exciting to see for - among other reasons - it seems to implement what had been kicked around here regarding VPython, i.e. a pure Python - via ctypes - fully native crossplatform windowing, OpenGL capable infrastructure. Humbling - the effort and background needed to pull something like this off. It is early, but with what has clearly been invested in it to date, one suspects the effort will continue to get it to wherever it needs to get. What I imagine to be the underlying axiom from an educational point of view is that it is more infrastructure for doing engaging things by writing pure Python from what - if it were up to me- would be the simplest possible edit/run environment. I don't have a name for the educational philosophy behind such thinking, and don't expect it to become ubiquitous. Justs makes me smile. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] OLPC related: pyGTK for cross-platform (Mac especially)?
I'm still in a state of flux about where to go next after PataPata Phase I (recently discussed here). Assuming I continue with Python (rather than moving more towards Smalltalk, either Squeak or one for the JVM), what interests me most is working on cross-platform applications (Mac, PC, GNU/Linux). Fro cross-platform work, I prefer Jython Swing over a Python plus widget set solution. This is because Swing is cross platform, Sun has announced plans to put lots of Java under the GPL, the JVM lets me ship very portable Java code alongside the Jython code if needed for performance, and we have already used Jython in cross-platform Mac, PC, GNU/Linux commercial projects with some success (we've only used Python + wxWidgets on PC and GNU/Linux, not Mac). However, for the areas I am interested in, especially educational simulations, being able to run on the One Laptop Per Child (OLPC) platform would be a nice motivating plus. However OLPC does not currently run Java. And with its resource constraints, the best choice for the OLPC is the mainline supported system, which is Python 2.4 (maybe later) and GTK+. http://wiki.laptop.org/go/OLPC_Python_Environment (Some variant of Squeak Smalltalk is another possibility too, as there is work on that.) http://wiki.laptop.org/go/Etoys Now, I don't *need* to support OLPC, and the JVM might run there someday, but I would say that is my biggest sticking point going forward with Jython/Swing if I stick with Python over Smalltalk. Our garden simulator especially is a natural match for the OLPC goals (and we have previously had people in various developing nations interested in it). So, I know I brought up this topic of PyGTK etc. before only about six months ago, but the computing landscape continues to change rapidly. So, what do people have to say now about using GTK+ (which the OLPC supports) for cross platform educational work these days, especially on the Mac and PC (since GNU/Linux support will be excellent)? Previously when I asked this there was a big groan from the Macintosh side of the Python educational community (at least from Brad Miller, see below). However, since then there is a continuing move for Aqua support for GTK. See: http://developer.imendio.com/projects/gtk-macosx This is the project site for the effort to port Gtk+ 2 to Mac OS X natively (so that you can run Gtk+ applications without X11 on Mac OS X). And from:: http://www.pygtk.org/ PyGTK 2.10.0 includes the following new features: ... MacOS X support Brad Miller had written back in June: http://mail.python.org/pipermail/edu-sig/2006-June/006571.html There is some work in GTK+ 2.9.x to get a native port of GTK working on the mac. Maybe when this effort is finally successful then native versions of vpython and other packages will be easier. .. But I also think that the effort required to get everything working under X11 would be too difficult for many beginners. So, is this still true six months later for shipping pyGTK based applications? Or should GTK now be considered a reasonable choice for applications to run under Mac and GNU/Linux? Anyone out there having easy success with pyGTK applications on the Macintosh? And if it works, is it still too bleeding edge to count on? As for Windows, it's long been working OK there as an easy install, right? Still, the installations I see seem to be separate packages, so it is not as easy as with wxWidgets, where I bundle the wxPython wxWidgets libraries with the Windows application, right? So, I guess my general question is, is pyGTK now an acceptable choice for applications that want to run on Mac, PC, GNU/Linux and the OLPC project? And if it is not, perhaps because of the Mac, is it likely within, say, six months of being an easy install on the Mac? (Software takes a long time to write and debug, so that time frame is reasonable for cross-platform support.) For reference, my most recent google search: http://groups.google.com/group/comp.lang.python/search?q=mac+pygtkstart=0scoring=dhl=en; turns up this comment: http://groups.google.com/group/comp.lang.python/browse_thread/thread/2ceb94790c8077c2/4339b2fc9f2fba95?lnk=gstq=mac+pygtkrnum=1hl=en#4339b2fc9f2fba95 GTK is being ported to Aqua, but the port it is in its early stages. And also: http://groups.google.com/group/comp.lang.python/browse_thread/thread/2ceb94790c8077c2/20f9a2e4e653f5b9?q=mac+pygtklnk=nlhl=en; GTK 2.8 uses an abstraction layer for drawing widgets called Cairo. Cairo can use OpenGL or Quartz as backends (still experimental). Thus, you can get a hardware-accelerated GUI from PyGTK if you are willing to use an experimental backend in Cairo. In any case, moving forward, for me, in Python, I think the choices are down to Jython + Swing vs. Python + pyGTK (assuming I don't try to write code at a level of abstraction that make the system mostly widget independent :-). --Paul Fernhout
Re: [Edu-sig] A Call to Arms - Advocating Python in Education
Don't forget unschoolers and home schoolers. :-) http://www.unschooling.com/ http://homeschooling.gomilpitas.com/ Plus free schoolers and other alternative schoolers: http://www.educationrevolution.org/ The needs here are often very different than conventional compulsory K-12 education -- they are generally more open ended and free form. Such students number about two million strong in the USA and growing, and include many parents and kids with free time to contribute as part of an educational experience (including potentially to free software development). So I'd suggest considering having an Unschooling / Home Schooling Advocacy Kit, too. :-) --Paul Fernhout Jeff Rush wrote: Greetings. I've just joined this list, to check out what is needed to support Python in the education community. I'm the Python Advocacy Coordinator that the PSF has hired to help out. My main jumping off point for advocacy topics is at: http://wiki.python.org/moin/Advocacy One of the items I'm hoping to get input about is the contents of three advocacy kits I'm getting together: - College Student's Python Advocacy Kit - University Educator's Python Advocacy Kit - K-12 Educator's Python Advocacy Kit Details at: http://wiki.python.org/moin/Advocacy#AdvocacyKits I'm drumming up a series of whitepapers, flyers, videos and podcasts to put into those kits. Not being an educator myself, I need ideas on what is needed. The actual individual items are being solicited at: http://wiki.python.org/moin/AdvocacyWritingTasks http://wiki.python.org/moin/ArticleIdeas. Next, we are seeking reusable/retargetable teaching materials, such as those under a Creative Commons license. We need slide presentations and class handouts. Now I know there are a great many slide presentations on the web about Python. I can google them all but we're not looking for just any presentation, we're looking for the best of field. We're collecting links and ideas at: http://wiki.python.org/moin/Advocacy#TeachingMaterials I know some of this already exists in the education community and I just need some nudges to come up to speed on what is available for me to make use of. Also permissions for reuse and reformatting, in some cases. Thanks for any assistance you have time to provide, Jeff Rush [EMAIL PROTECTED] Python Advocacy Coordinator ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] FYI: PataPata postmortem link
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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] 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=3569forum_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 ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Python-powered Fab labs the next big thing?
Dethe Elza posted about Fab Labs on this list in 2005. http://mail.python.org/pipermail/edu-sig/2005-April/004676.html A year later, here is a mainstream new article on them: 'Fab labs' deliver high-tech tools: MIT's fabrication laboratories aim to help developing communities find innovative solutions to local needs. http://www.csmonitor.com/2006/0927/p16s01-stct.html Excerpts: ... MIT opened the first international Fab Lab in Costa Rica four years ago and has sponsored nine others since then. Meanwhile, many more labs have opened on their own. They're just sort of popping up, Lassiter says. It's a good idea, and people want to do it. That's what is happening in South Africa, where the government has a stated goal of improving the country's science, technology, and manufacturing capabilities. ... The high concept is to get these into the communities, says Naas Zaayman, who runs the Innovation Hub Fab Lab for Advanced Manufacturing Technology Strategy, a government program created to spread science and technology. It's the idea that if you're somewhere in rural South Africa, and you want something for solar energy, you can go to a Fab Lab and make your own. ... Justinos Nkutshwev is one of the regulars. He sits at a computer, using the mouse to manipulate lines on a graphics program. He is building a bus, he says, and a generator to make it run. He is 15 years old and never used a computer before he came to the Fab Lab a few months ago. Now, he works with the lab's machines twice a week. I come here because I can make interesting things, he says. Although the lab technically closes at 5 p.m., the staff regularly keeps it open hours later. Sometimes teenagers show up at staff members' houses on Sunday, begging them to unlock the doors. They say 'We need to finish our projects, can you please open?' Nkadimeng says. It's great to see them so eager. There's no way to say no. === Looks like they use Python too: http://episteme.arstechnica.com/eve/forums/a/tpc/f/158007275731/m/615004070831 We primarly use the computer in each Fab Lab for running our computer aided design (CAD) and manufacturing (CAM). Our main 3D tool is BLENDER (pictured on the left above) which we are extending in Python (for example, see cad.blend) for use with our specific audiances. We also use SDRAW and PSTOEDIT for 2D design. http://cba.mit.edu/projects/fablab/tools.html Anyway, just fodder for the imagination -- nice having Python running these things. --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] slashdot: Teaching Primary School Students Programming?
http://ask.slashdot.org/article.pl?sid=06/08/27/000248 Teaching Primary School Students Programming? Posted by Cliff on Saturday August 26, @08:25PM from the toddlers-as-coders dept. Education Programming NotesSensei asks: Recently I was teasing the teacher who runs the computer club in my sons' primary school: 'You teach the kids only how to use software but not how to make software.' Today I got an email: 'OK, you're in: teach them programming.' Now I wonder what language should I pick? My first lesson will be the board game c-jump, but after that? The contestants are: Kids programming language KPL (ab VB.net derivate; Java using BlueJ; Greenfoot (and the BlueJ); and HTML. Does it sound like I'm on the right track or should I try something completely different? We are looking at primary 3-5 (that's 10-13 in this part of the world). Where can I find inspiration for the curriculum? === Python is mentioned there, along with a lot of other suggestions. ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] PataPata 0.2.04 released (Smalltalk parser; unified worlds)
I've released version 0.2.04 of PataPata on SourceForge:
http://sourceforge.net/project/showfiles.php?group_id=165910
Big changes:
* DandelionGarden, ExampleWorld, and WorldInspector now all use identical
code file for TK and Swing. This is a big milestone, as even if the
results don't always look 100% the same, being able to have an identical
source file could be the basis for making a HyperCard-like format for
PataPata to do simple stacks that work with both Python and Jython.
There remains work to be done on unifying the support files, but that is
hidden to the user worlds. The xturtle example is in a separate
TK-specific world file now. WX and GLUT still use their own world files.
* Added Pointrel version with Smalltalk-like parser (in Pointrel
directory, not integrated into GUI yet, but included wx version).
This is based mostly on work I did about two years ago, but which I never
released before. The Pointrel Smalltalk-like parser work may be of
interest for a few reasons:
1. It shows Python (the language plus libraries) being a universal VM for
other languages. (Yes, performance is a potential issue, etc.)
2. The Pointrel data storage format used makes explicit a lot of implicit
things in data storage for programs, and so might be of interest for
people learning how program compiling and evaluation can be represented
abstractly (using Python).
3. It might someday support blending Python and Smalltalk/Self syntaxes
for prototype development under PataPata.
Anyway, it's an experiment more than anything else. It does not use
bytecodes to represent compiled programs, instead it uses triads.
MethodContext objects should work; BlockContext objects are probably
broken in this variation (though BlockContext objects should work in the
older 20041201 code).
From the Pointrel subdirectory README.txt file:
=
Work in progress toward support Smalltalk syntax (for prototypes) on
Python using triadal data storage.
File pointrel20041201.py is a standalone program which offers a
smalltalk-like development environment (with a browser, inspector,
debugger, and workspace) Python under wxWidgets using a Pointrel triadal
approach. This is the most complete. It can read and write the image.p
file. From the first window you can open others.
File smalltalkToPython.py is a first cut at translating Smalltalk to
Python (not finished). This just prints out an attempt at Python code to
the console. It is mostly the same code as pointrel20041201.py without the
GUI and with a different code generator.
File protos20060808.py calls pointrel20060808.py and other pointrel*.py
files to parse a Smalltalk-like syntax with a different pointrel and VM
approach (intended to be simpler and clearer than 20041201 version).
Essentially, this is mostly the same code as pointrel20041201.py but
broken up into separate files and with changes to the VM instruction
evaluation (and triadal storage approach) and with the wx GUI removed. It
prints out:
Welcome to Protos
('String', 'The result of adding 10 and 20 is:')
('Integer', '30')
halting
As minor as that output is, it accomplishes the addition using a message
send and a stack of two [MethodContext] objects.
Usage:
python pointrel20041201.py
python smalltalkToPython.py
python protos20060808.py
python pointrel20060808.py (makes and reads test.im, and prints test output)
--Paul Fernhout
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Learning Math or Simulation with Python or Smalltalk
Andreas Raab wrote: tri triangular num n = sum of n consecutive counting nos (n=1) n = 1 ifTrue:[^n] ifFalse:[^n + (n-1) tri] Perhaps a Smalltalk could be changed to accept from a workspace the following? Integertri self = 1 ifTrue: [self] ifFalse: [self + (self - 1) tri] There is a bug with the use of n I think in your example? This modification also eliminates the return, as it is implied as being the result of #ifTrue:ifFalse: and also as it is the last statement in the method. Python needs the return however. I guess I actually don't see this if as control flow, by the way, more as result calculation, so the lack of a preceeding if does not bother me in this case. But I agree with you that since the f(x) style is how conventional math is taught, x f could be disconcerting. The question then is, how far would gnu math be willing to depart from current mathematical conventions? :-) For fun, another approach using imaginary Self-like Smalltalk prototypes. :-) = Calculator := Proto new. Calculator at: #tri: put: [:n | triangular num n = sum of n consecutive counting numbers (n=1) n = 1 ifTrue: [n] ifFalse: [n + (self tri: n - 1)] ]. Calculator at: #sqr: put: [:n | square num = sum of 2 consecutive triangular numbers n = 1 ifTrue: [n] ifFalse: [(self tri: n) + (self tri: n - 1)] ]. (Calculator tri: 20) print. (Calculator sqr: 4) print. == So, you could select this code in a Workspace and pick do it. But, explaining the use of brackets to novices could be awkward, as they need to understand a level of abstraction related to deferring a computation. If one could integrate Python-ish identational syntax into Smalltalk somehow, one could have: Calculator at: #tri: put: :n triangular num n = sum of n consecutive counting numbers (n=1) n = 1 ifTrue: n ifFalse: n + (self tri: n - 1) where indenting a subsequent line implied a block, except when it began with a keyword (not sure that covers all cases though, or if it does not create other problems). Generally I Smalltalk doe snot need indentational syntax as much as Python does, because methods are typically short and managed in a browser, whereas Python functions are often long and managed in a text editor with perhaps hundreds or thousands of lines in one file. In PataPata, this could be done as: = import Prototypes Calculator = PrototypeClass() def tri(self, n): # triangular num n # = sum of n consecutive counting nos (n=1) if n=1: return n else: return n + tri(n-1) Calculator.tri = tri def sqr(self, n): # square num = sum of 2 consecutive triangular nos return sqr(n) + sqr(n-1) Calculator.sqr = sqr = Or as: = import Prototypes world = PrototypeClass() class Calculator: __metaclass__ = world.buildPrototype def tri(self, n): # triangular num n # = sum of n consecutive counting nos (n=1) if n=1: return n else: return n + tri(n-1) def sqr(self, n): # square num = sum of 2 consecutive triangular nos return sqr(n) + sqr(n-1) = Still, a lot more extra stuff than Kirby's orignal: === From: http://www.4dsolutions.net/ocn/numeracy0.html def tri(n): # triangular num n # = sum of n consecutive counting nos (n=1) if n=1: return n else: return n + tri(n-1) def sqr(n): # square num = sum of 2 consecutive triangular nos return tri(n) + tri(n-1) But, it is also doing more. Kids spend tens of hours learning to type. Why should we expect them to be doing math from the first minute? Maybe the issue is that kids need to learn about levels and abstraction and pointers first? When I taught C programming to Bio majors I spent a lot of time in the first classes getting the college kids to point to each other and follow that around the room, and to pass string around, and so fort. The reason is I knew that pointers were the hardest part of C programming, and so I started with that fairly early on (Well, after a bit of turtle stuff, and getting kids to pretend to be turtles, or trying to. :-) Then I spent hours in the computer lab with them. (To answer a question Kirby asked previously on teaching style.) Again, both the Smalltalk-sh prototype code and the PataPata example are doing more -- by building objects which respond to messages. But whereas Kirby starts with recursion as important (levels of nesting), from a Smalltalk-ish OO point of view (and by extension, OO simulation) getting kids to understand the abstraction of objects receiving and processing and sending messages may be seen as more important. :-) One of the problems of teaching programming is that many kids need to learn the very basics sometimes. For example, that is one reason learning to play music at an early age may be better for building a programmer than actually learning to program first.
Re: [Edu-sig] Freedom: some Smalltalk history and Python implications
Kirby- Thanks for the insightful comments, including about vacation languages, which I agree with. You make a good point distinguishing conventional content (astronomy, higher mathematics) from programming issues. I guess my answer there is handwaving about the potential for a PataPata version of HyperCard as an authoring environment. Now that is still just mostly vaporware at this point, though closer to substance than it might look in some ways, i.e. you can already plop down buttons which do things or open other windows, but it is vaporish in the sense of not being done with the elegance of HyperCard. So, in that sense PataPata falls in the category of trying to make a Python GUI easier to build than existing methods. Perhaps it fails at that still (no documentation, probably bugs, perhaps performance issues, and so on), but anyway that's part of that hope. Of course, I could do even more handwaving about things that are just twinkles on the horizon about large projects being easier to maintain and debug using prototypes like Self and integrated development tools similar to Smalltalk, but clearly PataPata isn't showing that yet (i.e. prototypes add another layer of clutter right now including strange error messages, and there is no integrated debugger). Still, I don't think your characterization about respect or aloofness are accurate, and (as in the past with such comments I usually let slide) are perhaps verging on twising thigns in an ad hominen fashion. One can respect a language while still being critical of aspects of it. In the syntax case, I am continuing to point out that Smalltalk's keyword syntax (e.g. Point x: 10 y: 20 versus Point(10, 20) ) produces code where all arguments are labeled and so it is easier to read and understand. As I see it, that is a fact independent of licensing, object models, breadth of libraries, size or quality of community, or engineering reliability of the VM, and so on (areas which Python often has as an advantage over any specific Smalltalk). From a programmer point of view, thinking about maintaining a large system, that one syntactical point is a big win for Smalltalk and the Smalltalk culture. And, while I can label arguments in calling Python, as in: class Point: ... def __init__(self, x, y): ... pass ... Point(x=10, y=20) that call is syntactically noisier (i.e. more special characters) than the Smalltalk-ish: Point x: 10 y: 20. and clearly not how the bulk of Python code is written. And in Python, the internal names of variables are then exposed into the API and then effectively fixed in concrete and immune to easy refactoring (without introducing another layer of variables in the function). Also, for beginners, Smalltalk code is then easier to understand (assuming the beginner isn't already steeped in a BASIC or C or Java or Scheme background). And programmers spend most of their time reading code, not writing it. When I refer to politics I don't mean mainly in the PEP sense -- but more in the issue of seriously (not this level of chatter) lobbying for a language feature to people who are embedded in a C mindset against a community norm, where there is unlikely to be change and is likely to be outright misunderstanding and hostility (as Prothon etc. show). And where the language (Python) succeeds in large part exactly because of its syntax looking familiar to the majority of existign programmers (i.e. like C). And I am still unable to bring across the massive decrease in effectiveness and immersion I feel programming a large system in Python compared to Smalltalk, like were when an exception is raise I cannot immediately change the code and then carry on from the point in the program where the exception was generated, without either restarting the entire application. Granted, with some user added code (including from more general approaches I've posted to the Jython list) one can get a specific Python application to the point where you can reload some libraries and continue after an exception with modified code but usually only from the top of the event loop (so, redoing a menu selection or button press for example). I have used that in making one medium sized application in Jython. But that level of support is both dependent on active user modification of their program to have such hooks and limited in how well it works and certainly is not in the same level of what almost all Smalltalk support. And it is not the community norm. So, if you have a big application to develop, Smalltalk wins on this front as well. But also from a learner point of view, I think Smalltalk also wins here -- and beginner's programs often have many errors, and a restartable debugger can help them understand what is going on, keeping them in the flow of their program more than starting their application over every time an error shows up, or worse, trying to put in by hand all sorts of specific code
[Edu-sig] Smalltalk syntax benefits
Arthur- As a simplification, admittedly a cartoon, most professional mathematicians often care very deeply about a very few things for a long time (where a mathematician might spend ten years thinking about, say, proving Fermat's last conjecture) where they refine a concise notation they understand in a specific problem domain (with some cultural norms perhaps like dX), while most professional programmers need to care somewhat about a lot of things which change from function to function and application to application (where in a year a programmer might work on thousands of functionsand tens of applications, and perhaps read the intent of hundreds of thousands of function calls). That is why, for example, when I read code written by mathematicians they feel it totally acceptable to use, say, rd everywhere in a small program, when I as a professional programmer would prefer rainfallPerDay_mm, because to me I experience their program as just one little day trip on a lifelong journey, and life is too short to spend hours puzzling over cryptic variable names or mathematical items in simulations used without units (and often inconsistently in hard to find bugs where the code works but is wrong). I think this issue of argument labeling may fall into the same category of variable naming. Sure, if you maintain one program only and it is short, or if you spend a lot of time in one problem domain, then not labeling arguments so anyone can read them may be acceptable. But if you have to read and understand the intent of literally tens of thousands of function calls per year across dozens of libraries, then writing or reading something like calc(rd, i) or in your example Line(point1,point2) just does not cut it IMHO. (The Python codebase itself may suffer from something of the same effect in parts.) What about constructors like Line origin: 10 @ 10 angle: 35 degrees distance: 10 mm (which is easy to have in Smalltalk syntax) and so on? And I bet you can read what it means not even knowing Smalltalk. Would you rather read: Line(10, 10, 35, 10)? Or at best: Line(Point(10, 10), 35, 10)? Which is clearer? I think this goes beyond my bias as being experienced using Smalltalk system keyword syntax. Not to be too hard on you or Kirby, but I think it is easy to not see the value of the unfamiliar, and there is a lot functional foo() syntax makes difficult and awkward looking (Lisp, a Python ancestor in a sense, has a bit of this problem too). Again, just because Smalltalk has this and Python does not does not mean I'm saying use Smalltalk. I'm just saying, how can Python get this feature? Maybe it can't. Then my next thing is, can the two syntaxes live side by side -- a possible area for exploration. --Paul Fernhout Arthur wrote: Paul D. Fernhout wrote: In the syntax case, I am continuing to point out that Smalltalk's keyword syntax (e.g. Point x: 10 y: 20 versus Point(10, 20) ) produces code where all arguments are labeled and so it is easier to read and understand. That is, IMO, an arbitrary point of view, at best. Touches a particular nerve with me because I went to great trouble in the design of PyGeo to *avoid* the use of keyword arguments, feeling it in fact important that in creating a construction one should be in geometry mindset mode, not programmming mindset mode, and therefore *not* have to be explicit in stating the obvious. See http://pygeo.sourceforge.net/docs/Overview.html#built-in-geometric-intelligence The point is not whether my design is right or wrong, but that I found myself to be using a tool that allowed me to express my design exactly as I wanted to - right or wrong. Would I have had the same right to be wrong using Smalltalk? Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Version 0.2.03 of PataPata released (adds Jython/Swing support)
Andreas- Looking more into this issue (and based on testing feedback here) I see a couple if things: That the tokenize.py module has been under recent development: http://sourceforge.net/tracker/index.php?func=detailaid=1224621group_id=5470atid=105470http://sourceforge.net/tracker/index.php?func=detailaid=1224621group_id=5470atid=105470 [ 1224621 ] tokenize module does not detect inconsistent dedents from: http://www.mail-archive.com/pudge@lesscode.org/msg00050.html The source versions for tokenize.py are at: http://svn.python.org/view/python/trunk/Lib/tokenize.py Though it looks like only minor changes in the latest version. And the version before that introduced this test. Looking carefully in WorldCommonTK.py, there are two lines in the file in that class ( SimpleSequenceLayoutManager) which have extra space at the end before the carriage return. I think that is perfectly legal Python (though sloppy of me perhaps) but I'm wondering if the specific version (2.4.3) of Python you are using has a bug in the tokenizer.py in handling it? So, a few more things to try based on previous tests (thanks to people who tested): So you could remove trailing space on these two lines: Line 834: width = panel.width - panel.borderwidth * 2 - self.sidePadding * 2 Line 859: lengthUsed += self.betweenMorphSpacing * (len(visibleMorphs) - 1) And see if that makes a difference. You could also modify tokenize.py on your machine to generate a better exception with a line number where the error is. I haven't tried this, but something like: raise IndentationError( unindent does not match any outer indentation level) would become something like: raise IndentationError(unindent does not match any outer indentation level around line %d % lnum) That would at least help pinpoint the textual line tokenize.py does not like. Just to get running under Windows, if there was another later windows installer for 2.4, you could try upgrading to Python 2.4.4 (the Python 2.4 I have on my Debian machine is 2.4.4c though I don't use it by default, which apparently also works with the code according to my own testing). However, looks like the Windows installer from the Python site is only 2.4.3. http://www.python.org/download/releases/ You could try 2.5 beta maybe? Or downgrade to Python 2.3.5? Or install them side by side? But I'm not sure how much trouble having two Pythons installed under Windows might get you into, or what else might go wrong with different versions. But even if that worked for you, that isn't a great solution, as it means anyone using the latest Windows installer is out of luck. Anyway, I'll keep looking at other possibilities too. --Paul Fernhout Andreas Raab wrote: Hi Paul - When I try to run 0.2.3 (Python 2.4 on Windows XP) all I get is an indentation error (stack dump below). Any ideas? Cheers, - Andreas - PataPata Version 0.2.03 Using 'Alt' as the meta key to drag Morphs and get menus You can change this key in the file options.py If you use ALT under GNU/Linux and it drags windows instead of morphs, then you need to change a setting in your desktop settings. Loading world file: WorldExampleTK.py from C:\PataPata_v203\PataPata_v203 Loading world file: WorldCommonTK.py from C:\PataPata_v203\PataPata_v203 Traceback (most recent call last): File PataPata.py, line 18, in ? PataPataViewerTK.main() File C:\PataPata_v203\PataPata_v203\PataPataViewerTK.py, line 24, in main world = PrototypeClass(None).newPrototypeFromFile(WorldExampleTK.py) File C:\PataPata_v203\PataPata_v203\Prototypes.py, line 514, in newPrototypeFromFile newPrototype = worldModule.define_prototype(self.world) File C:\PataPata_v203\PataPata_v203\WorldExampleTK.py, line 9, in define_prototype world.worldLibraries = [world.newWorldFromFile(WorldCommonTK.py)] File C:\PataPata_v203\PataPata_v203\Prototypes.py, line 522, in newWorldFromFile result = newWorld.newPrototypeFromFile(fileName) File C:\PataPata_v203\PataPata_v203\Prototypes.py, line 514, in newPrototypeFromFile newPrototype = worldModule.define_prototype(self.world) File C:\PataPata_v203\PataPata_v203\WorldCommonTK.py, line 794, in define_prototype class SimpleSequenceLayoutManager: File C:\PataPata_v203\PataPata_v203\Prototypes.py, line 641, in buildPrototype prototype.setAttributeWithoutSideEffects(propertyName, value) File C:\PataPata_v203\PataPata_v203\Prototypes.py, line 576, in setAttributeWithoutSideEffects value = PrototypeMethod(self, value) File C:\PataPata_v203\PataPata_v203\Prototypes.py, line 47, in __init__ source = inspect.getsource(function) File C:\Python24\Lib\inspect.py, line 563, in getsource lines, lnum = getsourcelines(object) File C:\Python24\Lib\inspect.py, line 555, in getsourcelines
Re: [Edu-sig] Version 0.2.03 of PataPata released (adds Jython/Swing support)
kirby urner wrote: When Python first came out, maybe C programmers were the primary target, but a lot of us were used to an interactive shell environment from xBase (i.e. dBase II, III, IV, V, Clipper, FoxPro). So when MSFT purchased FoxPro to compete with Borland (FoxPro for Windows versus Borland's dBase V), and started going OO, that pushed a huge cadre into the OO paradigm'd who'd hardly even heard of Smalltalk, let alone coded in it. What was cool about FoxPro is it didn't go the VB route and just let programmers use precoded objects from libraries (the OCX, later ActiveX model). VBers were kept blissfully igorant of OO at the level of actually defining classes (with VB .NET, that's all changed). Just for reference, I seriously learned OO from ZetaLisp+Flavors on a Symbolics, as the TekTronix Smalltalk machine in the lab was hogged and APDA (Apple) Smalltalk was too slow and limited on the Mac Plus. Before I seriously got into Smalltalk years later, I learned the dBase compiler Clipper for an information management project, and that was phenomenal for the time. The best thing about Clipper for our use was that you could ship live code in the application -- that is, while Clipper was fast compiler, it could also interpret some of an applications code loaded from a database. For a time, I used ObjectWorks (a VisualWorks precursor) to prototype stuff I recoded in Clipper. After Clipper, I started doing some stuff in FoxBase, which I agree was really neat for the time and PC equipment. Not being able to ship end-user modifiable code like I could with Clipper haunted me for a long time after that in my own later work in C++ or Delphi (or VisualWorks) -- one reason I liked Python and Squeak (this was before open source ideas of just ship the whole source took root). Python definitely has a comfortable Clipper or FoxPro sort of feel. Not sure completely what defined that -- interactive turnaround? useful error messages? the syntax? And I agree that helps with its adoption. My phrasing was perhaps not clear. I think Python does have many benefits now for beginners or non-C users, but I feel its early success and continued (relatively) easy acceptance by industry derives from looking a lot like C without the braces. But I'll agree that feeling like dBase in terms of libraries or interactivity or some other aspect was a big win too. --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Freedom: some Smalltalk history and Python implications
kirby urner wrote: On 8/9/06, Arthur [EMAIL PROTECTED] wrote: Yeah, because after years of OO in commerce and industry, it's not this big elitist thing any more to have mastery of that jargon. Smalltalkers were impressive, in their day and age, to the great unwashed. But no longer. In and of itself, just knowing OO is not a mark of anything special. Knowing a dead language implementation of the paradigm is also not a turn on for young people. While you can repeat Smalltalk is a dead language until as many people believe it as Iraq had WMD (i.e. too many :-), but Smalltalk remains quite a live language, thought smaller in adoption than many others and often a secret weapon. http://www.cincomsmalltalk.com/blog/blogComments?entry=3331578947 Old might be more appropriate. :-) Or maybe, mismanaged, or less popular. Unfortunately (for me :-), general consulting rates have fallen for it from the heydays of the mid 90s when I did it commercially, as have the number of new gigs. Still, VisualWorks Smalltalk as a cross-platform stable environment useful for mission critical software where performance matters has never been surpassed IMHO (although Python comes closer every day, but will never match it for syntax reasons IMHO). While there are other Smalltalks, http://wiki.cs.uiuc.edu/VisualWorks/Overview+of+different+implementations+of+Smalltalk the flagships in the mid 1990s, mainly VisualWorks, and secondly Digitalk, determined much of the landscape. Hard to even remember what that landscape was like before so many free and open source projects became popular, like Python (but also CommonLisp variants, Ruby, Perl, even GCC, and so on). Rumor has it VisualWorks missed its biggest chance when Sun wanted to license it for their set top box work, and PPD wanted too much in run-time fees, and so Sun turned to what became Java instead. The chance not being to make money from Sun, but instead to have forestalled the development of Java. Short-sighted greed. Sigh. If VisualWorks had been open sourced instead of sold for a song to Cincom, I maintain ParcPlace/Digitalk/ObjectShare might still be a going concern with consulting, the way, say, the Zope Corp is. And surprise, I (and others) advocated that in 1999. :-) See my post here: http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/3b3a67ab0ab756e0/6d08b70aa9f6aea1?lnk=stq=rnum=1hl=en#6d08b70aa9f6aea1 One snippet of my post there back in 1999 (which also pertains to Python): === Because of these factors, I think there is much residual anger at ObjectShare. After all, it is unpleasant to think about how the most advanced development tool and OO language on the planet has been mismanaged and mismarketed into relative obscurity over the past twenty years. It has caused real suffering to programmers forced to take work in other (painful) languages like C++ or Java or VB. Nonetheless, Smalltalk is still in my opinion the best OO language (although Python is easier to learn for C/C++ coders and more modular). I've been having more success lately getting people to consider Python for places where Smalltalk might be the better tool and price is not a factor. The reason for this has to do with the license and availability of source (and smaller download footprint). It also (sadly) has to do with it looking like C (although I see no reason Python could not run on a Smalltalk VM as a combines Smalltalk/Python product).(*) It also has something to do with the community surrounding Python. This is a bunch of people who are using Python every day in mission critical applications (like web servers, data reformatting, spacecraft launch operations, industrial facilities, and complex simulations). They make sure it works, and have a great set of add-ons. This is all enhanced by the fact that Python supports modules well (each with its own namespace). Squeak has much potential, but is not used as much (at all?) in mission critical applications. It also has a license that makes it awkward to use in embedded systems (GPL actually is better in that respect). VW NC has potential, but will forever be hampered by not being a completely open solution (unlike Squeak or Python). The same thing happened with the ST/V free release, where without an open VM, interest in working with it has been marginal (compared to Squeak). I think it will be difficult if not impossible for ObjectShare to overcome this two decade legacy by conventional marketing tactics. A name change is not sufficient. My suggesting to ObjectShare is that since the bulk of their revenues (73%) is now from service, make VisualWorks open source under a Python-like license. http://www.opensource.org Then users will be assured of indefinite support of the product. Source code escrow as many big users have is not adequate because no one at a client's staff can keep current with the source. ObjectShare will be in a great position to increase its service revenue,
Re: [Edu-sig] Version 0.2.03 of PataPata released (adds Jython/Swing support)
Tony- Thanks for the tests. So, you got the same error on just one platform. Maybe an interaction of that version and perhaps line endings like Arthur suggests? Yes, xturtle is not in the Jython version as it is a library written for TK by someone else (Gregor Lingl) -- though in theory it could be ported (not sure how much work for someone). Sorry, I should have mentioned that somewhere. I also have a 3D turtle of our own I might put in there down the road (when I finish porting it from Delphi). And yes, I too think the Jython version is sluggish in several ways, compared to TK. Some of it might be how I am using a glass pane for some events, or might be some other issues. I'm assuming the dispatching approach I use is not the culprit (as not much is being done by the prototypes yet other than passign through some limited data). Definitely sluggish in redrawing when you drag; I tried to improve on that for quite a while with yields and sleeps and so on, but could not get it to work better. Hopefully mucking around some more with other approaches with Swing could fix some of that? --Paul Fernhout Tony Theodore wrote: == testing wanted Any Smoke Test level (e.g. does it run at all for you?) feedback on trying PataPata under Jython 2.2 on various Mac/Win/GNULinux Just downloaded and installed Jython 2.2, it starts up (very slowly) and mostly seems to work, however the xturtle doesn't work and there's significant lag in most actions. As a matter of interest python 2.3.5 and 2.5b2 both work very well, but 2.4.3 raises the indentation error reported earlier. I'm running WinXP SP2. Regards, Tony ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Version 0.2.03 of PataPata released (adds Jython/Swing support)
Arthur- Thanks for the suggestion. I used hexedit to look at the WorldCommonTK.py file and there were no 0x0d characters (cr). There were only 0x0a characters (new line). So, at least that file is consistent. But I'll keep looking (or maybe find a Python program that checks this for me?) Maybe I should write a checker using PataPata as a test... :-) --Paul Fernhout Arthur wrote: Paul D. Fernhout wrote: Andreas- Thanks for trying PataPata and sending the informative bug report. I have run into what I think is a bug in tokenize.py when it confronts mixed line endings in a module. Tried to get some feedback on python-list but no one bit. I would check your line endings to see that they are consistent. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Version 0.2.03 of PataPata released (adds Jython/Swing support)
kirby urner wrote: However, I have had many hours in an intimate setting with Kay himself, and so am not shy about stating what I think were his clearly expressed views e.g. (a) we haven't yet done enough to empower children (adults abuse their authority by dumbing it all down too much) and (b) we should have killed off Smalltalk long ago, but people since Kay have generally been too stupid to come up with a better language (victims of (a)), with maybe the exception of Guido. That sounds about right. But to be clear by killing smalltalk he doesn't mean Smalltalk is worse than any other language, just that he wants something even better. It goes along with is mantra of burn the disk packs and also, as I reflect on it, points to one of the sources of conflict in the squeak community -- between those wanting Squeak to be a good free Smalltalk implementation, and Alan Kay wanting it to be a stepping stone to something much better. The problem was though -- that without a relatively stable base, all the blue plane efforts got bogged down in the mud of silly little problems any commercial Smalltalk long ago resolved (e.g. even things like not having underscore for use in names -- mapping to a return arrow instead). In this video: Alan Kay: The Computer Revolution hasn't happend yet. Keynote OOPSLA 1997 http://video.google.com/videoplay?docid=-2950949730059754521 Alan Kay talks about the pink plane and the blue plane of thought. Simplifying, pink plane activities are exploring agreed on spaces (like playing a game by its rules) and blue plane activities are pushing boundaries (like making up new rules for a game). This previously mentioned link relates to that: http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-February/052648.html From there: To have a tension between the Pink Plane and the Blue Plane in Squeak, you would need a Blue Plane to begin with, and there isn't one. No, the tension is only on the Squeak list, where for years now people crop up requesting blue plane things (blue plane widgets, child windows and separate system windows, small deliverable images, too name some). These requests often turn the Pink Planers red, and so provoke a genuinely hostile (or more often, condescending) response. There have been some valiant attempts in the Blue plane during that time, but the general direction that Squeak has taken for the last few years has taken us further away from having a Blue Plane, to make it more like eToys, to have an image more and more addled with osteo-pink-plane-itus. Make Morphic *more* like eToys?! Oh how little that idea appeals. The Pink Plane is a plain old pain. I quote it because it reminds me of your comments on list sometimes. :-) And this is not to disagree with your points on using Python as-it-is for education -- in the sense that you remain absolutely correct that Python is a great system and people can learn a lot using it just the way it is in the manner it was primarily intended (as something better than C or shell scripting for those who already know C syntax and shell scripting). Or, because of its continued success over the past decade, that is is now a good first language for programmers (for reasons relating to community and libraries and popularity, as well as other good things about it). Now this is not to say any specific camp is right or wrong -- just to point out the difference in hopes, dreams, fears, and so on by various groups. The thing about lists and projects is they often become self-selecting -- people come to them, see the main line of philosophy or effort is in a different direction, and go onto other lists. Also, in a sense, relative to a Smalltalk Pink Plane of experimentation, Python has explored a relatively blue plane of reliability and modularity and so on. So labelling of planes are relative to expectations and communities. With PataPata, it seems you're unhappy with Python being a crystal clear implementation of a simple paradigm, and want to schmoo it into something for which its ill-suited, but which Self and/or Smalltalk may handle quite well. You'd like to ruin Python in other words. Or so it sounds to me. But I don't worry about it, as I know Guido well enough to know he's ruthless about keeping Python on track, at least through this 2.x series. But maybe he'll have a mid-life crisis and decide we should all be learning Smalltalk instead. I guess you could put it that way? Although perhaps one person's ruins are another person's foundation? :-) Ten plus years is a long time to stick with any one project. And sounds like, at the very least, Guido must be pretty jaded with Monty Python jokes by now. :-) So what is the Pink Plane for Python? Some interaction of Guido and the (self-selecting) community will define that. Anyway, with PataPata so far I have tried to stick with just adding a library to Python, although now I do use a metaclass function (inspired by
[Edu-sig] Version 0.2.03 of PataPata released (adds Jython/Swing support)
Version 0.2.03 of PataPata (a live Python object environment of Prototypes and Morphs) has been released. The zip file is at: http://sourceforge.net/project/showfiles.php?group_id=165910 The big thing in this new version is support for Jython (2.2 only) using the Swing interfaces ans supporting essentially the same prototype-based API and widget dragging GUI as the TK version uses. The Inspector and Dandelion example world also work under Swing in this release (and needed only minor changes from the TK version). Read on for more details. == testing wanted Any Smoke Test level (e.g. does it run at all for you?) feedback on trying PataPata under Jython 2.2 on various Mac/Win/GNULinux configurations would be appreciated. You need to use a Jython 2.2 (not 2.1) version (sorry, PataPata save file source format uses object for metaclass support for loading files). Jython 2.2 can be downloaded and installed from links here: http://www.jython.org/Project/installation.html To run PataPata for Jython under GNU/Linux (assuming jythonRelease_2_2alpha1 is installed in your home directory), use: java -jar ~/jythonRelease_2_2alpha1/jython.jar PataPata.py I'm getting this out early so people can play with it. As the first Swing verison it is bound to have some issues. Still lots of rough edges and some cut corners (e.g. some missing events like enter/leave). A future version needs to integrate the swing and TK versions better so that user World files that are now almost the same will really be the same. == unique benefits to a Jython version It might be possible to add quicker prototype method dispatch lookup more easily to a Jython version as a patch on top of regular Jython as opposed to doing that under C. I'm not sure I'm up for it at the moment, but in theory with a little big of effort and wading through Sun's documentation (and ignoring some other potential deployment issues, e.g. why we dropped Java web start http://www.dynamicobjects.com/d2r/archives/002859.html ) one could in theory make a one click Web Start application with PataPata and Jython that would give you a live Python environment with a GUI builder and Inspector with (essentially) one click from a browser on any computer with Java Web Start enabled. That might be nice in some educational settings. No doubt WebStart will continue to improve as a delivery vehicle, just like I hope Sun's Java will be open source someday. == grungy work to be done Right now there is a lot of duplication of files between Swing and TK (havign similar WorldInspectorTK.py and WorldInspectorSwing.py files, etc.) Ideally, I want to refactor the system to have common files, general platform files, and unique platform files such as: WorldInspector.py, WorldDandelionGarden.py, WorldConversions.py, WorldExample.py, WorldEmpty.py using WorldCommon.py, which woudl import UtilitiesCommon.py, which would import one of: CrossPlatformWrappingOfTK.py, CrossPlatformWrappingOfSwing.py, CrossPlatformWrappingOfGTK.py, CrossPlatformWrappingOfWX.py World files could then also import: WorldOnlyForTK.py, WorldOnlyForSwing.py, WorldOnlyForGTK.py, WorldOnlyForWX.py making them platform dependent. Doable, but that looks like some slogging. :-( == future directions and a pause for reflection Perhaps the best news about this all shows that I can make progress using PataPata and any specific widget set it wraps and then later use the (almost) identical code on another platform with some effort to write support code for that platform. Of course, Python's anygui and even wxPython has already done that, but in a different way. :-) Still, I know that the more I stray from the basic widgets (Buttons, Labels, Lists) the more work that would be -- but it is likely fairly doable. On the other hand, a truly 3D GUI if I had one is not going to be easily portable to a 2D platform. This version also started a GLUT 3D version of the interface, but that just opens a window as a proof of concept (I like the 3D approach, but it looks like a lot of work). Anyway, the good news is, PataPata now supports the default GUI for the Python and Jython releases. That means people could write some simple educational software that run on both platforms using (near) identical code. I don't think I'll venture into IronPython dot net support any time soon to cover all the major Python bases (I've never used IronPython and don't want to learn it right now). I'm not sure where to go from here on GUIs as I've gotten more interested in the One Laptop per Child project http://laptop.org/ and they are using Python and GTK. http://wiki.laptop.org/go/GTK From there: GTK+ is the basic GUI toolkit used by Sugar and other OLPC applications. Any application that needs a GUI consisting of standard Windows, Icons, Menus and Pointers should use GTK+. The OLPC include the PyGTK Module to simplify the task of building Python
Re: [Edu-sig] Version 0.2.03 of PataPata released (adds Jython/Swing support)
Andreas-
Thanks for trying PataPata and sending the informative bug report.
Reading through the stack trace, there is an error when loading
WorldCommonTK.py (a file defining supporting prototypes for the TK based
GUI). But (see below) the error doesn't seem to happen when importing the
file, just when doing introspection for the source of a function.
As a first guess I suspect the Windows Python version of inspect.py you
are using is somehow having trouble parsing the WorldCommonTK.py file on
your XP system for some reason, but Python itself can parse it. So again
as a first guess it seems like some sort of tab-to-space problem, or line
ending translation, or character encoding issue, or something like that,
where inspect.py might use a different approach than Python compiler
itself. Or maybe a garbled file?
My focus on 2.03 was for Jython support, so I'd be curious if you would
have the same problem trying to run the previous version (2.02). If both
have the same problem (no source loaded) then that may mean it is an issue
with something about the configuration of Python under XP you are using
which I would have to adjust for (I test under 2.3 for Debian). I just
tested under 2.4 under Debian and it starts also so it might be a Windows
issue?
Sorry I don't have a clearer answer for you; we don't have XP here, just
2000 under VMWare, and I just now tested under that with Python2.3 and it
works OK. I know from Francois Schnell's testing in June that previous
versions a while back did run under Windows XP, so it would be something I
more recently introduced (perhaps with the metaclass function handling?)
== more details on my reasoning and other ideas to try
That error by itself is directly from a line of code I see I
unintentionally left in when I was testing today. Sorry. Remove the line
that says raise in Prototypes.py on line 49 which reraises a caught
exception. I normally catch that exception, but temporarily reraised it to
resolve something related to Jython packaging at the last minute and
forgot to take it out, sorry. Normally, that exception should not be
generated in the first place though unless something else is wrong, so if
the system otherwise works, that line should be mostly harmless. Removing
that raise line might let it start if there are no other issues, however
there would at best remain a deeper problem (probably making a new error).
If it is failing there, that also means there is likely another problem
where it is not finding or parsing the source code for a method it is
loading from the file. Assuming the source code for the file being loaded
was correctly parsable (and I suspect it is not for some reason), you
might get a GUI, but you could not look at the source for some or all
methods. (Think of it as almost like some variation of sources file not
found in Squeak. :-) But, normally that code should never have an
exception in the first place -- it is mainly a holdover from supporting
the wx version where you can type in code from the command line and the
source is not stored in a file and so inspect does not work for such
functions. So while the raise should ideally be removed, I don't think
that will fix the entire problem.
The stack trace part:
File C:\PataPata_v203\PataPata_v203\WorldCommonTK.py, line 794, in
define_prototype
class SimpleSequenceLayoutManager:
is probably most significant here, as SimpleSequenceLayoutManager is
likely the prototype being defined at the time in WorldCommonTK.py. The
rest of the stack below that is calling the metaclass function
(world.buildPrototype) to define a prototype instead of a class and that
in turn is calling library functions to look up the source of a function.
(And frankly, I feel that source introspection code is a little shaky in
Python, unlike Smalltalk. :-) That prototype only has one function
(layoutMorphs). However, if the code is not indented properly, likely
loading that file would fail in some other way as an import even if that
exception you saw was not raised.
I just replicated a similar error (but not identical) by going into that
function and adding one extra space before layout = {}. I got:
Traceback (most recent call last):
File PataPata.py, line 18, in ?
PataPataViewerTK.main()
File /home/pdf/workspace/PataPata/PataPataViewerTK.py, line 24, in main
world = PrototypeClass(None).newPrototypeFromFile(WorldExampleTK.py)
File /home/pdf/workspace/PataPata/Prototypes.py, line 513, in
newPrototypeFromFile
newPrototype = worldModule.define_prototype(self.world)
File /home/pdf/workspace/PataPata/WorldExampleTK.py, line 9, in
define_prototype
world.worldLibraries = [world.newWorldFromFile(WorldCommonTK.py)]
File /home/pdf/workspace/PataPata/Prototypes.py, line 521, in
newWorldFromFile
result = newWorld.newPrototypeFromFile(fileName)
File /home/pdf/workspace/PataPata/Prototypes.py, line 508, in
Re: [Edu-sig] Version 0.2.03 of PataPata released (adds Jython/Swing support)
Kirby- Thanks for your note (and also the previous ones when I went on vacation, which I did read but replies got lost in the homecoming shuffle). I didn't reply to those (e.g. how important categories are in practice in Smalltalk as a cultural convention thing), but to sum them up it without the details it might revolve around your use of SmallTalk versus Smalltalk. Using the first signifies having been part of that community for any length of time. :-) Now, that capitalization of SmallTalk may actually most sense, because by the communities own common coding conventions it is actually the proper way to capitalize it if you think of it as two words Small and Talk -- it just isn't done though, as the community tends to think of Smalltalk as one unique concept as another sort of convention. So, is that capitalization consistent? Or inconsistent? Anyway, the deeper issue is that every community has conventions (even when they may not make total sense), and you made that point yourself a while back I believe, in the context of how library implementation are a big part of defining the syntactic and semantic conventions of a language (especially one like Python with open source libraries), and it's hard to swim against that tide. And any new effort runs into difficulties when it attempts to swim against the conventions (or leap into the blue plane instead of stay on the pink plane in Alan Kay's metaphor), requiring not a 10% improvement to be acceptable, but more like a 10X improvement. In the case here, looking at the prototype related issues (not Python with classes, for which your comment holds better) for a beginner, the Smalltalk (or really Self) way would a single obvious option when you need to get something and the getting has a side effect (just put code in a x slot). But in Python, you either need to have a function activate on using a property or you need (as PataPata supports) some way of specifying a side effect before or after a setting operation. That makes for a few points of confusion for any learner (or implementor. :-) You sort of handwave away the property function as a rarely used necessary evil for Python, but needing such thing often in Prototypes is one of the big points here about elegance. And in writing code to wrap widgets, having side effects on property access turns out to be common thing in order to keep state consistent with a widget which may not always send changed events for various internal fields (and side effects on setting even more so). In the PataPata case using side effects defined in properties breaks the link between the name of a property and the name of the code that says what it does plus you have to need to know to look at property definitions to see how these are defined. So, you are left as a learner with a basic confusion given that functions in a prototype system are also properties -- so if a piece of code is used related to a property, is it called directly on the property get or is is intended to be used as a function with parens? Now there are ways to resolve this, but they require more intellectual effort and tracking usage and such. So, one more layer of difficulty between you and the code -- and the whole point of prototypes is to bring a person closer to the code IMHO. I think that is one ugly thing about PataPata I saw more clearly after my vacation. But another issue is from a debugging standpoint that you can override __getattr__ in Python (as PataPata does) but it is not clear whether the caller intends to use the result to send a message or as a value, and that can have a big impact on how to handle messages (e.g. when to call doesNotUnderstand in Smalltalk and perhaps invoke other delegation code, where there is a big and obvious difference from accessing the code for a method, say, to copy it, and actually using it). Anyway, these are finer points, but they bear on issues of conceptual elegance and ease of learning. Granted, people can learn the exceptions and deal with ambiguity or create new conventions, and a language like Python has so many great features that may overcome these issues for Prototypes, but they are still in some sense conceptual warts in this case for using it to do prototype based systems. Then again, maybe there is a cleverer approach I have not seen yet. I really need to reflect more on how I have used and elaborated on the notion of properties and see how much of it still makes good sense on reflection, and also consider your points here further. The parens on a constructor never bothered me. :-) But coming from Smalltalk (not Self) it is a big deal you can't have multiple constructors. with different names --Paul Fernhout kirby urner wrote: On 8/7/06, Paul D. Fernhout [EMAIL PROTECTED] wrote: On the other hand, after doing even more coding in Python, I'm really missing even more all the Smalltalk development tools, a situation which PataPata
[Edu-sig] The keyhole problem and learning environments
While looking around the web looking at issues related to Squeak and Python and 3D GUI issues(*), I came across this: The Keyhole Problem. http://www.aristeia.com/TKP/ From there: This is the web page for my current book project, The Keyhole Problem. The book explains how some kinds of constraints in software systems decrease the quality of those systems in many ways. It proposes practical steps programmers can take to avoid these constraints. I call the constraints I'm interested in keyholes: arbitrary restrictions on your ability to see or express something. The name is motivated by the analogy of looking at a room through a keyhole in the door. I'm especially interested in keyholes that programmers can easily avoid, i.e., on gratuitous keyholes. The book defines a number of such keyhole types, gives a variety of examples of how they manifest themselves, explains why they are harmful, and describes how they can be avoided or mitigated. While much of the book seems to be more about specific smaller programming issues, metaphorically I think that the general metaphor relates to my concern about promoting web-based development environments for Python beginners. Especially having seen the alternative as advanced by Smalltalk development environments thirty-odd years ago, I am concerned that such efforts may be creating experiences of looking through lots of keyholes instead of feeling increasing mastery of a powerful development environment. Maybe this is also a spin on what Kirby uses other language to describe related to when people try to hide the guts of GNU/Linux. Now, that doesn't mean that it is not worth making web tools, just that this is a concern, to be weighed against the advantages of getting people doing any programming at all or having an easy way to deploy educational Python simulations, and I think it worth reflecting on to see if one can both get the cake of people using Pythonic simulations easily and eat it too by letting them change those simulations in unexpected ways. Consider again my previous mention of transient versus sovereign http://www.cooper.com/articles/art_your_programs_posture.htm applications. I accept the idea that when you want to know something specific it may be nice to find a canned simulation about it on, say, a Wikipedia page. But, what I want is a way for people. when they wish, to go further, and turn that transient experience of interacting with a canned simulation into an ongoing expandable experience using sovereign development tools. For a decade that has always been my indirect goal with plans for our garden simulator -- to present something complex and educational, yet open to the user to easily build on, tear down, or just go further with, and that has been part of what has driven my interest in Squeak and now Python. Essentially, after the user looks through the keyhole of the specific simulation running, ideally they can open the door and walk into the simulation with easy-to-use development tools and start making changes. For the web systems, I would have less problems with the concept if it was easy to easily point your large development tool at the web page, download the code, and then keep modifying it (and republish it). I think this also returns to earlier comments on how to design a good graphical context for Python newbies -- one that just lets you do some interesting things easily (a keyhole) versus one that makes such things easy but still gives you power to move beyond that and do general graphics. Thinking about a 3D turtle vs. 2D turtle in that context, then maybe a same idea would be to have a turtle that does 2D by default with a simple API but also supports complete 3D operations in an extended API for people who suddenly have an interest in going further. Part of this of course comes from pedagogical philosophy -- restrict what kids can do at the moment versus point them to interesting things and see what happens. I guess one could have a system that restricts at first and gradually unlocks. Games are often structured this way as you proceed across levels or acquire new abilities. While that is looking at it from a pedagogical point of view, this issue pops up in lots of contexts. For example, emacs has tons of key bindings, and it is easy for a beginner to press one by accident and instead of getting a beep they get some completely unexpected behavior which they may not be able to back out of easily. It might be nice if for beginners only some of the key bindings worked, and they could be gradually added as needed in an easy way. Similarly, a criticism leveled in the link below on Squeak is that it is very easy to just break Squeak in various ways from the advanced shooting yourself in the foot by making a base class change that causes an error window to open when opening a window :-) to simple things like tearing off a window's close box in Morphic. PataPata has
Re: [Edu-sig] Alan Kay - another one of his ideas
pages which users wander onto. But Wikipedia is a complex platform both in a social sense and in a technological sense, even if the content is served through a web browser. It's kind of like looking at Squeak and its community and saying, well, that's just about clever use of BitBlit, so let's make BitBlit better. I feel that just trying to make more dynamic pages misses the broader issue here of Wikipedians (the authors) interacting with a very large system with a long persistent history and surrounded by a community. It's ironic that when I started thinking about contributing to Wikipedia some time back, my reaction is that it needs local tools to it can be a distributed network to share server load and allow people to visualized relationships between articles and authors in 3D (i.e. perhaps something built on Squeak :-). So, I had a very different set of thinking about that forest heading in a very different direction. I'm not saying, say Wikipedia, could not benefit from LogoWiki technology, just that I don't see that as a really big win, compared to say, just using Flash or Java Applets for dynamic content. What's really happening here is just a battle over standards for end user content delivered over the internet. A nice win, maybe, to use more open solutions like JavaScript over Flash, and so a battle worth fighting, but not a big win in-and-of-itself for education. And many solutions can coexist. And it seems to me that Alan Kay's work was always about the big ideas. And if one is going to fight the battle directly, then perhaps it might be easier at this point to argue more for Java solutions (as problematical as they are) like Java Applets or Java web start. For the Python Community, Jython already runs on those, so it is a good enough solution. So, maybe targeting Jython/Java (or using a similar compatible approach) is another way to go, even for Smalltalk related systems. [I have a bit more to say on Squeak/Python/Jython issues I'll put in another post.] --Paul Fernhout Andreas Raab wrote: Paul D. Fernhout wrote: I don't mean to complain specifically about these pages, just to point out that while the supposed intent here is to make programming available to the masses by using a dumbed down environment like a web browser, in practice, this fails for me. Whereas, when I install Squeak or Python, it works. So, I think Alan Kay may be going in the wrong direction here in some ways, compared to Squeak. Not to say it might not be useful for certain audiences, just that it fails the everyone test, at least for me. Not surprising, really, because you're missing the point of Logowiki. Logowiki's main purpose is as an example for what dynamic content on a web page can mean, in particular in an educational setting. Remember that we lost the ability to author with the introduction of the world wide web and we're only about to get it back. The choice of Logo is simply because it's easily recognizable for the intended target audience. [A secondary motivation for Logowiki is as an experiment in zero install deployment and to be able to see what can be done with Ajax and friends and a bit of compiler translation technology which is not so different from PyPy btw - parts of it would make perfect sense to translate Python to Javascript code on the fly] And of course, the site was also inaccessible when I first learned about it (from Kirby's post to this list I think) from too much demand most likely, so it also failed the cost test. Presumably, they just could not afford to put enough resources into the project for everyone. Paul, you are confusing a demo with a product. Logowiki was done to explain to OLPC what we mean when we use terms like dynamic content and what may change if, for example, Wikipedia had the ability to included such dynamic, end-user authored content. ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Big thanks to Ian Bicking for metaclass ideas for PataPata
Ian- I just wanted to publicly thank you for your suggestions, help, and patience here on this Edusig list getting me (and PataPata) started with using metaclasses to define prototypes (using the class ProtoFoo: syntax), for example your note here: http://mail.python.org/pipermail/edu-sig/2006-May/006383.html I just started using a metaclass approach inspired by your comment there for the main WorldCommonTK.py library, viewable here: http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/WorldCommonTK.py?view=log After a lot of work :-) I could just open the old code written by hand in a more procedural way in PataPata and write it out that live world of prototypes in the new metaclass way. (I did lose some comments I may want to put back in eventually though, probably in some sort of overall comment property or in the documentation for specific properties.) For reference, you can see the old approach here: http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/WorldCommonTK.py?view=markuprev=237 So, here is an example from that WorldCommonTK.py file (again, wrapping Gregor Lingl's xturtle library) of how you can now define a prototype in PataPata using the class syntax (and stored as a global to use elsewhere) somewhat along the lines your outlined: class XTurtleCanvas(Morph): __metaclass__ = world.buildPrototype pen = None size = (200, 200) def _destroyEmbeddedWidget(self): if self.widget: if xturtle._canvas == self.widget: xturtle._canvas = None if xturtle.pen == self.pen: xturtle._pen = None self.widget.destroy() self.widget = None self.setAttributeWithoutSideEffects(pen, None) def _newWidget(self): xturtle._root = self.world.widget newCanvas = xturtle.ScrolledCanvas(self.container.widget) xturtle._canvas = newCanvas self.setAttributeWithoutSideEffects(pen, xturtle.Pen()) xturtle._pen = self.pen return newCanvas def userInterrupt(self): xturtle.TurtleScreen._RUNNING = 0 def windowFocusIn(self): if self.widget: xturtle._canvas = self.widget xturtle._pen = self.pen _property_writeFunction_pen = '_store_None' _property_copyFunction_pen = '_store_None' world.worldGlobals['XTurtleCanvas'] = XTurtleCanvas [You can also see the older xturtle wrapping approach in my earlier re: News about turtle graphics post to the Edusig list.] Notice how I also added inline support for defining properties (anything starting with _property_ is processed as a property directive). I also used a builder function __metaclass__ = world.buildPrototype instead of a metaclass, and that builder function is actually a method of an existing world; all prototypes need a link back to the world they are in, in the current approach, so it was either that or some other initialization code with a module or class global. Notice also how what would normally be shared class variables (e.g. pen or size) are instead now more like local prototype instance variables. And here is actually using the global prototype in another file (WorldExampleTK.py): http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/WorldExampleTK.py?view=markup class proto17(XTurtleCanvas): __metaclass__ = world.buildPrototype pen = None position = (38, 377) widget = None For reference, I made a decision a long while back to explicitly require naming prototypes before you could derive from them (for development clarity). There is no reason you could not link directly to other prototypes, and I used to do that, and it was more work to make the indirect lookup through a globals dictionary, but I'm hoping that explicitness make documentation of intent clearer. So, what is going on here isn't quite copying or cloning, it is setting a self.traits array to have one or more strings, which are then used to look up properties and values if they are not locally defined in the prototype itself, so something like multiple inheritance from named base classes. You can then override behavior locally or otherwise modify the globally named prototype you have as a trait. Anyway, thanks again for your help and suggestions, Ian. All the best. --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] PataPata 0.1.19 release Stigmergy
kirby urner wrote: Or committed company employees, or crew members, or television screen writers... Good point. By the way, SourceForge is finally allowing logins again, so there is now a proper release here: http://sourceforge.net/project/showfiles.php?group_id=165910 I wonder if you've contacted Kevin Altis, the PythonCard developer I know best. Robin Dunn, author of wxPython is also local (we've met many times). I saw the new wx book at Powell's Technical, and almost bought it (I'm waiting for a bigger book budget to materialize, so I might expand my library). To be clear, it is limited PythonCard compatibility, but it is using TK to achieve that, not WX. Eventually, I hope to improve the wx GUI, but the TK one is more advanced right now and the PythonCard compatibility is built on that. So, you can take your PythonCard resources (simple ones) and build TK GUIs with them (at least, as far as laying out widgets, connecting code still needs to be done by hand, and automating that is not a priority for me, if it would be doable at all given various issues). It's a tribute to PythonCard's modular design of using a resource file that I was able to do this with PataPata. The basic difference between PythonCard and PataPata is that PythonCard seems focused on helping you develop GUI-oriented Python applications faster and in a more maintainable way, whereas PataPata attempts to give you a live world of Python objects where some of those objects are Morphs and non-visual Prototypes. Still, I'd expect the PythonCard project might not like a competitor? :-) I'm all for friendly competition of course -- but the reality is there are only so many volunteer developers to go around at any specific time, so if PataPata picked up some I would expect PythonCard might lose some. Certainly I could have tried to improve PythonCard rather than make something different. On the other hand, sometimes when something becomes popular, say building GUIs in Python, then everyone benefits (say if VB and Ruby and PHP developers switch to Python and either PythonCard or PataPata). In the PythonCard case, since it is under a more permissive license (BSD-ish) than PataPata (GPL) they do address different audiences. So, see, some teamwork going on, though of an artifact mediated kind. I think of that as a form of Stigmergy. http://en.wikipedia.org/wiki/Stigmergic Wow, I'd never have guessed. Same root as stigmata, no? Maybe not. Never thought of that. On etymology: From: http://www.answers.com/topic/stigmata stigmata ... [plural of stigma, from Gr.,=brand] From: http://stigmergiccollaboration.blogspot.com/2006_05_01_stigmergiccollaboration_archive.html Below are some variations on the terms origins (see the [poster for references): * ‘stigma’ (goad) and ‘ergon’ (work)…” to “…stigmergy (stigma: Wound from a pointed object; ergon: Work, product of labour = stimulating product of labour). * from the Greek words stigma ‘sign’ and ergon ‘action,’ and captures the notion that an agent’s actions leave signs in the environment, signs that it and other agents sense and that determine their subsequent actions. * [F]rom the Greek stigma: sting, and ergon: work. So actually related in some sense I guess. From there: Stigmergy is a method of communication in emergent systems in which the individual parts of the system communicate with one another by modifying their local environment. So like when I mow my lawn in a certain pattern, signalling a satellite, or when ETs use a crop circle to phone home, right? Science fiction examples of stigging out (slang for exercising stigmergic abilities). Not quite the same, though interesting examples to work with. The point of the individual or group stigmergic activity is not generally explicitly to signal, which is what you give examples of -- people intending to send a communication, but just doing it by making a large physical artifact. Rather, the idea is that each actor does something that feels good to them to improve their local environment, and other actors then build on their work in some way, or connect their own independent work to the others work on recognizing it. So the cooperation is mediated through the artifact, but the artifact itself isn't necessarily intended as a signal (though it could be). For a better example, it would be like your neighbor sees you mow part of a crop circle in your cornfield, and they then decide to mow another part of a circle along the same arc which joins up with yours because it feels right, and so on, until soon your community has got a really big circle around the whole neighborhood someone really could see from space. In the PataPata example, Gregor wasn't writing xturtle for PataPata, and PataPata wasn't written to host xturtle, but it turns out the two things can be used together. That is more like stigmergy in termite mound building, where termites mill
Re: [Edu-sig] News about turtle graphics
Gregor Lingl wrote: I've decided, that my new turtle graphics module ready now. Gregor- Nice work! Just for fun, I've integrated xturle.py with PataPata as a component, and here are a few changes I made to it (in diff format, at the end of this message), in case you are interested. Using PataPata, I was able to interactively build a xturtle script which took parameters, where the parameters were entered via Morphs I made as I needed them (like iterations, or color). I have an example world file with two widgets. Now, obviously, such an activity is not for the beginner user -- but more advanced ones might like being able to make parameterized xturtle functions. Since I use Python2.3 mainly as it is the default install for Debian, I made xturtle.py run with Python2.3 by changing the static methods and the use of sorted(). There might be more Python2.3 issues, but those were the only ones I've come across so far. I also added a line of code to reset TurtleScreen._RUNNING before throwing the Terminator exception, as otherwise you can't restart the turtle if you are using the library in a long running application. When I started playing around with it, that was a big issue for me, so that motivated my adding a BREAK interrupt key response to PataPata (though it only works for the xturtle XTurtleCanvas -- an endless loop doing nothing or just printing will still hang TK and PataPata). Now, whether you want to make it run with Python2.3 may be debatable, and you may well use those static methods in other code, so making them instance methods may well break other demos. But you most probably want to reset the _Running flag in any case. PataPata 0.1.19 has the XTurtleCanvas.py component in it, but the extra BREAK handling code is only in the latest stuff I've been adding to SVN here: http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/ By the way, here is a simple world file written by PataPata that uses an XTurtleCanvas: http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/WorldWithXTurtlePC.py?view=markup Note how the color and iterations are taken from GUI widget Morphs in the section: def mouseClick(self): reset() down() color(self.components.colorEntry.text) for i in range(int(self.components.iterationsEntry.text)): forward(100) right(91) forward(50) This is the file that defines the XTurtleCanvas (among other things): http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/WorldCommonPC.py?view=markup This is the relevant xturtle specific code to make an XTurtleCanvas: XTurtleCanvas = world.newPrototype(Morph) XTurtleCanvas.size = (200, 200) XTurtleCanvas.pen = None def _newWidget(self): xturtle._root = self.world.widget newCanvas = xturtle.ScrolledCanvas(self.container.widget) xturtle._canvas = newCanvas self.setAttributeWithoutSideEffects(pen, xturtle.Pen()) xturtle._pen = self.pen return newCanvas XTurtleCanvas._newWidget = _newWidget def _destroyEmbeddedWidget(self): if self.widget: if xturtle._canvas == self.widget: xturtle._canvas = None if xturtle.pen == self.pen: xturtle._pen = None self.widget.destroy() self.widget = None self.setAttributeWithoutSideEffects(pen, None) XTurtleCanvas._destroyEmbeddedWidget = _destroyEmbeddedWidget def windowFocusIn(self): if self.widget: xturtle._canvas = self.widget xturtle._pen = self.pen XTurtleCanvas.windowFocusIn = windowFocusIn XTurtleCanvas.localProperty(pen).writeFunction = _store_None XTurtleCanvas.localProperty(pen).copyFunction = _store_None XTurtleCanvas.localProperty(pen).setFunction = None world.worldGlobals[XTurtleCanvas] = XTurtleCanvas (The bit at the end with properties just ensures the pen is read only and is stored as None when the world is saved to a Python file). It was a bit tricky to get the thing to work right with those global functions when you have multiple canvases! I'm still not sure I'm quite satisfied with the result, but basically I swap in _pen and _canvas into the loaded xturtle module from the window's xturtle canvas whenever a TK window gets focus (I had to add that window focus handling too). This would be a problem if there was more than one xturtle canvas on a window, but by then for multiple canvases on one window I assume one could write code that accessed the each canvas's pen directly instead of using those globals functions. Good luck with your talk. Thanks for making such a nice library. --Paul Fernhout $ diff xturtle.py ~/workspace/PataPata/xturtle.py 20a21,22 # PDF -- Modified to work with Python2.3 instead of 2.4 (removed static methods use and sorted() use) # PDF -- added TurtleScreen._RUNNING =
[Edu-sig] PataPata 0.1.19 release Stigmergy
kirby urner wrote: In other words: as I learned long ago, the solo developer is quickly outclassed by what teamwork can do, when it comes to finalizing a commercial and/or educational product. We've discussed this several times on this list, in connection with game development. How often true... Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has. -- Margaret Mead But a lot of times, one just goes for green field development, per the recent Pata Pata example. Well, it's somewhat green, but as mentioned before, I'm building on the shoulders of giants. :-) I've been pretty quiet on edusig as I've been hard at work. :-) SourceForge is partially down right now so I can't make a proper release in response to your mention :-) but I just added PataPata_v119.zip (version 0.1.19) to SVN here: http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/releases/PataPata_v119.zip?view=log You can download from that web page. This version includes the current release of Gregor Lingl's xturtle library, wrapped as a Morph. (I modified the library slightly to work with Python 2.3). To run the demo (after unzipping the file) use: python PataPata.py It even has some PythonCard compatibility. It can read PythonCard resource files and build GUIs for them -- if the widgets are from the limited set it supports (Button, CheckBox, TextField, TextArea, Menus, and a few others). You still have to link in the code by hand though. I converted one example -- the conversions sample which converts temperatures, currencies, and Morse code. I also converted the menu builder tool GUI but it has no functionality yet. (Limited) PythonCard compatibility motivated several major improvements in the system (including naming morphs and supporting menus and a visible flag). There is also one example using the approach Ian Bicking outlined previously here of using metaclasses to read in prototypes defined using class. Also included is an example of how it works just using regular python code to construct them, so one can compare the two. It still uses the old approach for writing as I explore the new (for me) idea. There is also a webcast Francois Schnell made of PataPata on ShowMeDo: http://showmedo.com/videos/video?name=patapata_tkinter1_fSchnell So, see, some teamwork going on, though of an artifact mediated kind. I think of that as a form of Stigmergy. http://en.wikipedia.org/wiki/Stigmergic From there: Stigmergy is a method of communication in emergent systems in which the individual parts of the system communicate with one another by modifying their local environment. --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Accessibility to non CS types?
kirby urner wrote: I also admire many of the constructivists you mention. [snip] Wow, you sure get around, Kirby! :-) By the way, in my post on sources, I forgot to mention Doug Engelbart, of course. His mother of all demos is still driving much of computing RD today (including, perhaps, a lot of Alan Kay's work). You can see the original demo at: http://sloan.stanford.edu/mousesite/1968Demo.html Even if you don't want to watch the entire 90 minutes, there is a textual description there of what is presented. Perhaps making computers accessible to non CS types should involve teaching them more of the history of computing, i.e. how far we have *not* come. :-) If one taught that, one would want to include Alan Kay's comments (linked by Francois in another thread) http://www.redhat.com/archives/olpc-software/2006-April/msg00035.html on how hardly anybody wants to use post 1960s language ideas. :-) (Although, even in the 1960s, there was Lisp with first class functions, which mainstream Java still lacks. :-) While I'd rather have my three screen Debian GNU/Linux box and internet of today than his specific 1960s technology, clearly what Doug Engelbart's team demonstrated was such a quantum leap from what went before(*) that it really is barely matched in some ways by today's consumer systems, at least in spirit almost forty years later -- as around 1968 he demonstrated real-time collaborative audio and video conferencing and editing over a network, a dynamic extendable language, hypertext, graphics, the mouse, a chord keyboard, and so on. Have we really come that much further in four decades conceptually? In terms of chord keyboard use, for example, we're still behind his demo (his argument was learning to chord keys was a good investment for a professional, as beyond the improved speed, you could also mouse with one hand and chord text with the other). I did try to get Doug's newer effort to consider doing the next version in Python (as part of his Unfinished Revolution II Stanford course), as well as try to hook them up with the Zope people directly, but I had trouble prying them away from the grip of Sun's Java. :-) See for example: http://www.bootstrap.org/dkr/discussion/0215.html (I have long since taken down the experimental Zope site linked there, though.) Note: while I thought using Java six years ago was not a very good idea because at that time, beyond the language's clutter and limitations, the JVM was also an unstable write once, debug everywhere solution with limited libraries, now, six years later, while I still think Java remains a problematical language syntactically, I think the JVM itself is a reasonable deployment vehicle in many situations (i.e. for Jython applications) and the Java libraries themselves have finally gotten most of the bugs out and there are some fairly good free versions of JVMs (e.g. Kaffe) and supporting libraries (e.g. GNU Classpath). --Paul Fernhout P.S. I should also mentioned Neil Postman and Charles Weingartner, from their late 1960s book: http://www.amazon.com/exec/obidos/tg/detail/-/0385290098?v=glance P.P.S. (*) well, this is ignoring Ivan Sutherland's work on Sketchpad, http://en.wikipedia.org/wiki/Ivan_Sutherland or Vannevar Bush's Memex concept, http://en.wikipedia.org/wiki/Memex which both informed Doug Engelbert colleagues' work (and which J.R. Licklider funded, and even relates to Theodore Sturgeon's 1950s writings). Vannevar Bush's 1940s Memex idea really seems like the origin of many of these ideas. http://www.theatlantic.com/doc/194507/bush By the way, here is a Python version of a Memex-like system I wrote a while back (included in a larger Python package): http://sourceforge.net/project/showfiles.php?group_id=6010 The implementation is in the included sample file tkPointrelMemex.py. It is mentioned by me here with some usability tips: http://hardware.slashdot.org/article.pl?sid=05/07/19/2330201threshold=1tid=126tid=198tid=185tid=103 Oh, and that article reminds me I did a Jython version of Memex too, see: http://pointrel.org/projects/memex/ which has a screen shot and links to the code here: http://pointrel.org/projects/memex/memex.py I guess I'm kind of working my way through the history of computing with Python. :-) First Memex, now sort-of a nod towards Smalltalk (and Self) with PataPata, and then maybe, someday, Augment. :-) ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] PySqueak: pyGTK Cairo pygtkglext (OpenGL) next?
francois schnell wrote: Still take care of yourself ! undefined day you should ... time.sleep (7*60*60) Well, after a good night's sleep, the bug I've spent endless time chasing, scouring all the delegation code in Prototypes.py for perhaps ten or so hours on and off, turned out to be a problem in the GUI code from all the way back to the wx code I copied for tk (which it turns out had the same problem). So nothing wrong with the delegation code (though I did optimize it some, and add a debugging flag during all the hair pulling. :-). Avoiding these kind of mistakes is just the reason pair programming is surprisingly cost effective. http://www.pairprogramming.com/ From there: One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work. Someone looking over my shoulder when I wrote the original code might have noticed that and saved me lots of debugging. Need to add support for doing that virtually over the net with PataPata someday. :-) It's amazing how much even a novice programmer can contribute to an expert's productivity by just noticing something like that and asking a question about it while the code is being first written. For those who are curious, or to mildly challenge your students, here is the offending piece of code (though most of the problem was knowing where to look, of course. :-): def duplicateMorph(self, morph): newMorph = morph.copy() self.addMorph(newMorph) newMorph.x += 5 newMorph.y += 5 if morph.getPropertyDefinition(createEmbeddedWidget): morph.createEmbeddedWidget() World.duplicateMorph = duplicateMorph As the Monty Python team might say, Can you spot the loony [bug]? :-) If you need a hint: === If I had done a better job of naming the input variable to originalMorph this would have been a more obvious problem. Solution below: (*) I also corrected the wx version, which used the identical code, which I had copied to the tk version. Don't worry about the package I've actually co the repository a day ago (on my XP and Kubuntu box) and will check for updates often to have my current juicy PataPata version :) Great. :-) Here's the problem I have with the Tk version: On Win XP : - If I alt-right-click on a Morph and call the inspector it doesn't work (ie I can see in the dos window that it called InspectMorph Prototype x but the inspector doesn't focus on this Morph) - If I manually search for a morph in the Inspector (where it says morphs 'type list') and if I try to change its color for example (lets say 'red') and click accept = the morph disappear from the world and the dos window says : problem drawing morph Prototype On Kubuntu Dapper Drake: - the alt (left or right) click doesn't work as expected : if I want to drag a morph I'm always dragging the whole application window and I can't drag an individual Moph anymore. If do an alt-right click I can't access the menu to inspect the morph (I have a ~resize icon for the mouse cursor). - I have the same bug than for XP if I want to change a value in the inspector. Maybe it is related to the bug you were talking about ? I can make a quick screencast if it helps you to visualize the problem. Sorry about those difficulties. You've kept me busy for the afternoon. :-) Probably no need for a screencast for these issues, but I'd love to see one for TK once things are working well for you. First, so it works at all (even with smoke coming out :-)? That was my first concern, and implicitly I think that is answered by yes. :-) Hooray! For the the inspector tree updating, that was simply not finished. I had known about this, but I has just had not got around to fixing it. I have now fixed it and it is in the latest SVN. Should work for all platforms. The non-widget morph disappearing and generating a drawing error message is most likely a problem with validation of whatever was entered for the color field. If TK can't interpret the color value of the widget, it can't draw it. I can't be certain that is the problem, but I think that is the most likely cause because I have seen it happen myself (like if I put in blue instead of blue). There is a color selector dialog now used under TK, though you need the world menu. In testing this just now, I'm finding the TK multi-line edit is adding an extra newline. I think this is a known TK issue, so I just now changed the code in SVN to strip that out, otherwise this will never work from the inspector? You can also use a new right click menu option of edit value which gives you a popup single line editor where you can enter blue and no
[Edu-sig] Jython Poll: Java3D apps -- one click works or not?
I'm wondering how suitable Jython would be right now for easy-to-install educational 3D apps in Python (e.g. PySqueak/PataPata, but could just as well be any Python 3D app that runs under Jython). So, I would be curious, for those who care to try it, what percentage of people on the edusig list who go to this Java 3D site, https://j3d-webstart.dev.java.net/test/ and click on one of the web start links, will actually see a 3D application window open up on their system and run properly without much effort? This is the simplest test (a rotating cube) so you could just click here: http://download.java.net/media/java3d/webstart/test/HelloUniverse.jnlp One click and you are done (in theory, if your machine has a JVM installed and web start enabled). On my Debian GNU/Linux system, the first was a 4.6 MB download, after accepting a couple of Verisign certificate from Sun for trusted code. Then it just worked. After that, the other apps did not require much of a download, and all just worked. However, I've done lots in the past related to Jython and Java (including enabling web start for some tests), so my system certainly is far from being a stock one. I also just tested it on an iBook G4 and it ran. Though I had to do an extra click for accepting a certificate, plus say no to whether I wanted a desktop icon. But I'd consider that a one click success. :-) However, I then tried it under another Debian machine and while everything loaded, the window did not display. And I also tried it on that machine under VMWare running Windows 2000, and while a window came up, it was empty. That machine probably does not have proper 3D drivers configured for X Windows, but in any case, it fails the one click test (twice, sadly). So far, we have: Debian/Gnome -- Yes Mac OS X -- Yes Debian/KDE -- No; No window VMWare Windows 2000 under Debian -- No; Empty window. So, I'm running 50% here for four tries. :-) The biggest determinant for Debian GNU/Linux is probably whether I have already tried to get 3D running on the machine. I'm not so much interested right now in who could in theory or practice make these 3D programs run on their machines with effort (though reports related to that are appreciated, of course). I kind of expect, if people are willing to put in some work on any recent computer and OS (minutes to hours), these programs should run (although other things might get broken in the process, if twiddling with any OS's configuration. :-) What I am trying to get at here, as a real world data point, is how many educators (or parents) on this list can just click and get Java3D working at home or in a school computer lab (ignoring the 5MB download, I'm assuming we almost have broadband here?) Even though these are just plain Java applications (using the Java3D library), if there is any significant level of responses of One clicked worked for me with few negatives then I would have to rate Jython as a strong candidate for doing 3D with Python with minimal install problems, since if you can run these Java 3D apps, then you should pretty much just as easily be able to run a Jython 3D app. Obviously, this isn't a statistically valid experiment (e.g. only adventurous types may try it), but it is the best I can do easily. If you try it, please mention what OS you tried it on too (Mac OS X, Win 2000, Debian GNU/Linux, etc.). Negative reports very much wanted too, so if you try and it fails, please let us know. Having webstart disabled maybe should count as a negative report, although I'd be curious the app it did run after enabling and how hard the issue was to resolve. --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] PySqueak: pyGTK Cairo pygtkglext (OpenGL) next?
in SVN -- though I have not packaged it, so you'd need to check it out with SVN (or download each of about twenty files separately, ouch). http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/ I could make a package if that makes it a lot easier though. The inspector is now live in the world, and you can now save and load files with TK widgets. You can even delete the save and load buttons. :-) I'm trying to resolve a bug right now related to the prototype delegation; I've spent hours trying to trace what is probably some tiny mistake somewhere; it is related to copying a TK button and modifying the copy's click method and having the first buttons click method still called; so I haven't wanted to make a new released version with that problem. Anyway, I'd be curious to read your opinion on whether a TK version would hold your interest (or the interest of other educational people) given you mention somewhere on your site an interest in moving from tk to wx. If TK is good enough for you, I might keep developing with it for a while just to see how far it can go (hopefully to the point of a HyperCard like thing), since it is, for good or ill, the most cross-platform easy-install solution right now for Python GUIs and related graphics. Even wx takes an extra set of libraries. (I also think PataPata could make TK a little more approachable in some ways. :-) Then, with a little magic and tinkering, maybe a future Jython version could come along to make any future HyperCard-like PataPata stacks into applets? It really does not take that long to wrap the basic widgets of a system (a suprise for me, as I thought it would), and I already know Jython and Swing (my TK was very rusty). Anyway, I think a TK HyperCard-like system (and eventually raiding the PythonCard demos :-) that might be a nice next goal to aim for. Not as funky as pyGTK and Cairo and OpenGL, but something I could show ready progress on to some point of critical mass. However, if there are a predominance of yes responses to my other post about one click Java3D, I might think about moving to Jython and Swing. Even though two of my four tests failed, I think they failed due more to lack of OpenGL support on one machine than Java WebStart failing, which would mean a regular Jython Swing app might run correctly with one click more often than not. Anyway, for now, I am pushing along with TK as these issues percolate and I get feedback. Several things I need to do (e.g. making PataPata worlds talk to each other so you can have you app in one and the development tools in another) have little to do with the GUI anyway. All the best. --Paul Fernhout francois schnell wrote: On 03/06/06, Paul D. Fernhout [EMAIL PROTECTED] wrote: Just for feedback, I've just installed PyGTK GTK+ 2.8 runtime pyCairo on a WinXP box and its really quick: 1 exe for each to double click on. http://www.pcpm.ucl.ac.be/~gustin/win32_ports/ The 3D gtkglext is more difficult for now (I didn't find any exe): = mingw , make for win, etc ... Maybe for very *motivated* people (under win and mac-intel), a heavy-gear possibility to be sure that most things are well set-up will be a patapata-liveCD (maybe based on something like Morphix - that I might try this summer). While checking this I've just found out that pyro made an apparently nice live-CD (with knoppix) : http://www.pyrorobotics.org/?page=PyroLiveCD Actually I think it would also be useful to have a ~ PythonWorldEdu-LiveCD with : - Python resources (+ videos) - all the educational Python softs possible (patapata, vpython, Crunchy-Frog, rur-ple, gnu-math, pyro, pygeo, pygame, pymol, etc ...) - Pyhon and Python bindings apps to make contents with (Blender, Gimp, etc) or to play games. In fact I'd like something I could show to people and say : all this software are done either in Python or you can tinker them with Python (bindings) and if you want to begin to discover/learn Python all you need is the live CD and begin playing with all these. Concerning your java options, I don't know if you've seen the Logo TNG Gui on OS-X : http://education.mit.edu/starlogo-tng/tutorial-videos/ I'm not a big Java fan but if Java applets could help to bring patapata in a browser with some python code background it could be important. For Alan Kay the browser is something to reconsider: http://www.redhat.com/archives/olpc-software/2006-April/msg00035.html (And I would rather be modifying Jython than CPython, since Java is somewhat easier to work with than C.) So, maybe I should think harder about a Jython/Swing version of PataPata (at least as another proof of concept)? Dear me I don't now were you find all this pluridisplinarity and energy ! I don't know what you eat (or drink) in the morning but I want to order the same ;) Concerning the different graphical/GUI choices I just don't now enough yet to be useful but I'm
Re: [Edu-sig] Accessibility to non CS types?
Andre Roberge wrote: Indeed! This is really neat. I had downloaded a much earlier version which left me rather underwhelmed (probably because I had no clue as to what patapata was leading to). This is really neat. Congrats Paul! Thanks for the encouragement. --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Elementary graphics library
context otherwise, it becomes a design goal issue of, Is it more important to *potentially* support multiple backends for a simple display context, or is it more important to provide a display context that is easy to use and yet does not limit a kid's imagination and possibilities once they get started with it (assuming it runs on the platform they have access to)?. So anyway, looking back at Johannes' original proposal, http://users.ox.ac.uk/~orie1763/coder-python.pdf it seems to me that just making Cairo a little easier to use would still fulfill the intent there (including being cross-platform enough), while not creating any artificial limits on what kids could do. Installation and availability still may be an issue, of course, but long term, won't that be solved for Cairo if Mozilla and GTK use it? Still, I should admit to being a little self-serving with my argument here; if Python educators got behind a good cross-platform standards like, say, Cairo, and GTK, and pygtkglext (for OpenGL), and it got bundled into the main CPython distribution in the future http://wiki.python.org/moin/PythonThreeDotOh (or at least as an easy add-on package for Mac, Win, and GNU/Linux), then I think there would be enormous value for Python in education to have a solid GUI, 2D, and 3D display engines which everyone could count on for being available when introducing people to Python. And, that selection of libraries features in my next post (on PySqueak/PataPata). That level of standardization might be a pipe dream of course, but still, as an edusig community, having a set of technologies like those as commonly recommended ones for intro Python programmers might still be of great benefit (when going beyond the command line or text handling). Right now, if I'm going to write educational software for Python, the only thing I can count on easily being installable cross-platform is TK/Tkinter. And if we are agreeing that is not a good enough solution (say, for web graphics as in this case), then it seems to me it would be nice to push along a good set of emerging standards rather than spend a lot of time writing all sorts of extra abstraction layers to support lots of libraries. I mean sure, if you have a commercial product, fine, support everything, but time is so limited for these things, that having just one good library choice which is a no brainer in each area of interest in learning GUIgraphics with Python (widgets, 2D, 3D) can save a lot of time and painful searching. So, maybe this is a variant of, if TK is not good enough anymore as a standard given the things people want to do with Python and how they want them to look, then what's next? An EasyCairo display context for Python which is made popular might be an important part of that push. Anyway, just my two cents. :-) --Paul Fernhout Andre Roberge wrote: On 6/1/06, Paul D. Fernhout [EMAIL PROTECTED] wrote: Amazing how much of these decisions often hinge on easy installability and ready availability. So, as another comment for the original poster, can TK as a backend meet the basic graphics operations desired? Doubtful, since Johannes's intent is to render graphics in a web browser, not in a separate window. André ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] PySqueak: pyGTK Cairo pygtkglext (OpenGL) next?
Short version: Would people here be willing to install PyGTK 2.x and pygtkglext (OpenGL on GTK) and related files on their machines *if* there was a Python-based software package they *really* wanted to use? Mac and Windows are of issue mainly, since GNU/Linux probably is probably trivial install. Does anyone under Mac or Windows have happy experience doing that for either PyGTK or the 3D extension pygtkglext (either in a home or a lab setting Long version: While exploring the issue of restricted evaluation environments (I am considering having PataPata windows communicate by passing textual Python programs :-) I came across this on Python 3.0 wish list: http://wiki.python.org/moin/PythonThreeDotOh Include wxPython or PyGtk in core library [for Py3K]? Would anygui also be a good option. Place Tkinter into legacy status? (Musing again. Seems like we need a more mainstream, higher performance standard GUI in the core distribution. wxPython is very popular, so I suggested it as an option. The PyGtk is an awesomely thin layer over the C library and it makes Gtk objects look like native Python classes.) Now given the wx bashing lately (including from the OSI Chandler project I linked to), and the Cairo blessing(?), that PyGTK comment got me thinking. Also, Francois mentions somewhere he wanted to move beyond TK for his work. Well, I just implemented a rudimentary TK proof-of-concept version of PataPata. And the inspector is live in the world. And I am not as dissatisfied with the look or performance of TK as I thought I would. [Though of course it still needs more work.(*)] BUT, I read that, and the squeaky gears in my brain start creaking, thinking, hmmm, Python2.x, GTK, and Cairo?. And after a Google, this link has me pretty excited: Writing a Widget Using Cairo and PyGTK 2.8 http://www.pygtk.org/articles/cairo-pygtk-widgets/cairo-pygtk-widgets.htm and so I tried the file there and it ran on my Debian machine without needing to install anything (though I have in the past installed lots of stuff, so I don't know about stock distributions of Debian Python, but clearly this support is just an apt-get away apparently, at least as far as Cairo). From the link: Cairo is a powerful 2-dimensional graphics library designed to support a number of modern graphics techniques including stroking, alpha blending and antialiasing. It supports multiple output formats, which allows developers to use the same code to display graphics on the screen, print them to the printer or accelerate them with OpenGL. As of GTK+ 2.8, GTK+ has been integrated with the Cairo 1.0 rendering library, giving developers access to this flexible graphics API. PyGTK added Cairo support in the 2.8 version. See the wiki for further info. There is also PyGtkGLExt for Python 3D OpenGL support (though I have not tried it): http://gtkglext.sourceforge.net/ Example Python 3D program: http://mail.gnome.org/archives/gtkglext-list/2004-April/msg00012.html I really like the idea of using something like Cairo if it is picking up steam (see my previous post in Elementary Graphics Library). And 3D support sounds good too (rather than the TK developers leaving behind TK's togl :-( ). As I reflect on it, I am also willing to trade-off 90% of popularity for PataPata right now in terms of easy install for Mac/Windows *if* it would make my life under Debian easier to get something neat working that I and a few others want to use, and has the promise of picking up easy install in a couple of years (like if Python3K went with pyGTK as a default). Plus I already have wx and tk versions, so it's not like people could not try the basic idea on those platforms. The issue is more a matter of where I shoudl be putting more energy, since if I could use GTK and Cairo and PyGtkGLExt for cross-platform widgets, 2D graphics, and 3D graphics, then long-term it makes it easier for me to maintain a system using common cross-platform standards, especially because I don't have to put in much of an extra dumbed down compatibility layer. For example, I can just pass GTK events around rather than translate them to my own; I can use Cairo calls rather than my own simplified 2D context; I can assume everyone is using the same way to access 3D graphics rather than try to abstract initialization out; and so on. Now, this compatibility issue is a bit more complex, because I would like to run PataPata things as applets on Jython, but I'm not sure that is important enough at the start to prevent using an otherwise promising cross-platform solution CPython works with, given that I'm not sure how important Applets really are, and in the future there might be more person-power to make some GUI object wrappers that runs both on GTK and Swing. Obviously, I could search the PyGTK and gtkglext list archives: http://www.daa.com.au/mailman/listinfo/pygtk http://mail.gnome.org/mailman/listinfo/gtkglext-list/ but I was
Re: [Edu-sig] Accessibility to non CS types?
francois schnell wrote: Thanks Doug I begin to gather all this on a single page (while testing googlepages in the same shot...): http://francois.schnell.googlepages.com/patapata Wow! Beautiful page. Thanks for that and the two new videos. I'm being mostly quiet because I am mostly coding(*). :-) --Paul Fernhout (*) ... coding a TK version. The wx widget dragging bug under GTK (plus other comments here including in the graphics library thread) led me to question using wx further for this. Yet, I want this thing to be usable quicker if people are interested right now than doing all my own widgets in something like Cairo (nice as that would be long term). So, throwing even more performance to the winds, I'm trying to make a TK version of PataPata for easy install since TK comes with Python by default (even on the Mac?), better accessibility to what Python programmers already know (e.g. your liberlab software is in TK), and hopefully be able to support a variety of embedded TK widgets (and Pmw widgets too, etc.). The very first PataPata proof of concept was with TK and had Morph copying issues, but that was before the properties work for wx, so now, bringing the two together, that works (you can now copy a TK button). BUT, I'm stuck on intercepting all ALT mouse activity so embedded widgets can be dragged without messing with their individual events handlers (which I could do as in a try with passing on right click menu events [like I did with the wx Button], but is inelegant and may have other problems). New code is in SVN at patatpata/trunk/PataPata/ (several files) and you can drag all but the Button, and menu interact with all morphs, but the inspector and shell are gone for the moment, so a big step backwards at the moment. :-) Not worth using, though it would be nice to know if it ran on other people's systems if you want to check it out from SVN (the wx version is still there, but renamed PataPataViewerWX). But if I *could* get the embedded widgets to drag, then I could fairly quickly make and maintain the development GUI in itself, as a separate Morph world of wrapped-TK-widgets Morphs. :-) Anyway, one Tkinter book later (_Python and Tkinter programming_) plus lots of newsgroup reading, and I'm still not sure how to do it correctly. Something about writing my own mainloop I think, to get the mouse event before the button or other widget does. But I have a few other leads too. ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Elementary graphics library
Dethe- Thanks for these other links and comments (especially on wx). Putting all the dozens of options together, I definitely think PyCairo makes a lot of sense because it has been adopted under Linux for GTK (and for Mozilla), so it almost certainly has a future, and would make a solid choice for the library of drawing my own cross-platform widgets, and would avoid me even wanting to write a cross-platform compatibility layer because I could just use it as is (which relates to the original poster's question, although in their case I can still see the point to a simplifying wrapper for education, though less so the need to have multiple back ends). However, there is an ancient Chinese proverb that when confronted with making a decision between 100 different alternatives(*), the best choice is always to Run Away!. :-) So, along those lines, I decided to start using TK again (used in the first PataPata proof of concept) for several reasons including mostly it is the Python default. I am trying to use its widgets rather than draw my own, and ignore cross-platform font problems, speed issues, bitmap drawing issues, and so on for now. I wanted something to give me some fast progress on the HyperCard/widget front, and at least now I can drag TK buttons now under GTK 2.6 with proper feedback. Though who knows what else will be broken or missing -- I already had to borrow Idle's tree widget. :-) I am also stuck with the tk canvas for drawing (until I understand how PIL works? Or until PyCairo can render to a TK Canvas or Frame?) Also on the plus side, OpenGL should then be available through togl (though I have not tried that, looks like it may no longer be supported?). Still liking wx for general stand-alone applications though. :-) The funny thing is, since PataPata is its own Squeak-like beast, the TK widgets actually look kind of funky and retro in it. :-) Amazing how much of these decisions often hinge on easy installability and ready availability. So, as another comment for the original poster, can TK as a backend meet the basic graphics operations desired? --Paul Fernhout (*) Or a nasty rabbit with long sharp pointy teeth. Dethe Elza wrote: The full set of Ginsu 2D interfaces for only $9.95 a month? But wait, there's more... Mirra http://www.ixi-software.net/content/body_software_mirra.html Mirra is a 2D openGL python library. It defines a set of classes to render primitive shapes (Text, Pixel, Line, Circle, Rect, Bitmap, BitmaPolygon) and manages rendering and user input (mouse and keyboard). Mirra focuses on interaction and implements an event listener and classes that receive mouse events. (in a way like macromedia director or flash do). It runs using pygame(SDL) but it can also be used under wxPython. Mirra is also thought to teach students (basically design and multimedia students) programming in python by playing around with graphics. SVGDraw http://www2.sfk.nl/svg Create SVG (XML for 2D) images using Python. My head is spinning. :-) Just wait till we delve into 3D %-) Just a thought: rather than a new GUI implementation, improving the Python GUI FAQ with lots of this information and pros and cons and so on might be a very valuable effort just by itself. I think this is an excellent idea. So much of choices depends on specifics and tiny details. For example, I'm fairly happy with wx, but there is this bug with dragging certain widgets under GTK 2.6. I haven't used wx for some time, but when I did it a) sucked on OS X, and b) seemed to be a random mix of reasonably polished widgets and half-baked crap that would be as useful as writing your resume in crayon. It also suffers from being huge and very Windows-focused. I can understand using it on Windows (beats using MFC, but so does hitting yourself with a ball-peen hammer), but I think it goes downhill as you move to Linux and drops off the cliff when you go to OS X. Just my impression, though I've seen the same feelings expressed elsewhere. I'd sooner use PyGame, and PyGame sucks for general UI/event handling (by itself, there are libraries on top of PyGame which help). Of all the systems, I think PyCairo has the most momentum (and also has OpenGL hardware acceleration). Mozilla and GTK are both moving to Cairo, so it's getting lots of real-world use, profiling, bug-fixing, and speed-ups. This makes it a bit of a moving target, but the APIs should be fairly stable even though the implementation is in flux. Caveat emptor. I haven't spent a lot of time with any of these (on the Mac I can access Quartz from Python, which works for me). I'm planning to explore further for an article or blog at some point, but any recommendations I make at this point have to be taken with a huge grain of salt. And of course, I also want platform independent fonts (and I'm not sure how to get those best, wx uses sizers to get platform independent dialog looks,
Re: [Edu-sig] Accessibility to non CS types?
kirby urner wrote: I'm pleased you have become so enthusiastic about Paul's work. I know you know this, but just as an obligatory disclaimer, if PataPata is any good, while I can (and will :-) certainly take some credit for yet another attempt at putting constructivist educational ideas (and a prototype-programming paradigm) into a Pythonic context, the vast bulk of the ideas are coming through others like David Ungar, Adele Goldberg, John Maloney, Randy Smith, Maria Montessori, Dan Ingalls, Alan Kay, Seymour Papert, Grace Llewellyn, Diane Balestri, David Ferguson, and so on -- even Richard Stallman for the free software movement, and of course Guido van Rossum, for making Python so approachable and already prototype-ish. So, shoulders of giants and all that. :-) By the way: Shoulders of Giants -- A Paper on the Inevitability of Open Source Dominance http://www.cyber.com.au/users/conz/shoulders.html And there is nothing like even one interested user to motivate improvements. It's not so much recognition as just the thought it might actually be useful(*) and so worth the continued investment of time relative to other priorities and interests. --Paul Fernhout (*) From Winnie-The-Pooh: Chapter 7: Piglet was so excited at the idea of being Useful that he forgot to be frightened any more, and when Rabbit went on to say that Kangas were only Fierce during the winter months, being at other times of an Affectionate Disposition, he could hardly sit still, he was so eager to begin being useful at once. ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Accessibility to non CS types?
Cairo might not be accessible to an Applet?] Basically, that is a Squeak-like approach, sending in mouse and key events into a world of custom Morphs. So I plan to pull out the wrapped wxButton and go to pure Morphs pretty soon. Still, it was worth it to actually wrap a few wxWidgets because that caused the improvements in the property system. Should doing the basic widgets prove too difficult, then I can fall back on wrapping wxWidgets or TK widgets or even GTK widgets etc. If you know of any GPL compatible sources of widget sets in Python to draw from, that could really help a lot in terms of minimizing wheel reinvention (Dethe just posted some which I need to look at). Right now I'm thinking of PythonCard for the event naming structure, and maybe Pyxel and OcempGUI and GNU Smalltalk for some implementation ideas. The GUI uses wx right now, but I've been musing over using Cairo or something like it instead -- but it would be best if whatever is used can work both in Python and in a Jython Applet (either as a simple layer written for PataPata that works on both, or as one library like Cairo that might work in both). For now, my default is to just do some basic drawing with wx and then port it to Jython/Swing at some point. I also have a few more things I want to add to properties from Smalltalk, mostly automatically tracking dependencies and sending changed messages, but more on that if/when I get to that. You wrote: make PataPata a good imagination amplifier ! That sounds like a good concept to always keep in mind as it develops. All the best. --Paul Fernhout By the way, I was the one mentioning Ocaml :-) though I mainly see it as a much better C than something I want to be coding in all of the time. I prefer Smalltalk-like and Self-like systems with dynamic objects, including Python, but that's because, except for coding the VM or certain libraries, I am more interested in changing the system while it runs (like Smalltalk Python can) than having the fastest system (like OCaml C can). Naturally, for other people working on other problems (especially numerically oriented-ones), their priorities may differ. francois schnell wrote: On 29/05/06, Paul D. Fernhout [EMAIL PROTECTED] wrote: Francois- Wow! Thanks for making that Flash recording: http://francois.schnell.free.fr/bazar/patapata-test1/patapata-test1.html That is a neat demo showing things I had not even thought of, like with the jumping Morphs (and far beyond my presentation skills). Well what I''m doing here is not really a neat presentation it's just that when I find something interesting like this I like to show it to other people :) (I'm also very much into Free Culture and Free Software advocating). My wife is now finally impressed somewhat with what I am doing. :-) The version you are using did benefit from her trying an earlier version and her feedback on it, as several things she (also a programmer) tried that were hard or confusing or generated errors, I made easier or fixed. Oh , send also to her mes homages and congratulations from the french man :) (my English spouse still have nearly no idea what I'm doing with electronics bits and computers all over the place). To answer your first question: To add a method, try right-clicking in the yellow inspector pane [...] Dear me ... I didn't think you already have that and didn't try ... it works great thanks ! fun times ahead :) To answer your second question: To execute a method in another morph, you must first have a pointer to that morph directly. Ideally, that would be supported by cut and paste in the inspector, but you can't do that yet. However, you can, say, go to Morph 0 and add a field and call it morph1 and then when asked for the value, enter (without quotes): world.morphs[1] which will evaluate to Morph 1 in the world. Then you could reference self.morph1 in any method of Morph 0, like to call self,morph1.X() directly.[...] Great my objects can now talk to each others ! It will be awesome when you'll also have quick integration of this. :) More fun times ahead :)) I'm guessing you're using WinXP? Nice to see the wxWindows button dragging properly. I'm mainly using XP for software I don't have on my Ubuntu Dapper (like quick sreencasting, itunes/podcasts for my ipod, etc). I have one screen/keyboard/mouse and a switch quickly between the Linux and XP box. So many times one does things and thinks no one notices or cares, so I'm very excited to see someone trying it (and going to the effort to make a Flash video, too). Thanks again for trying it and the encouragement. Well ... maybe it's why Einstein said it's difficult for people to understand what they never experienced (ie in our case a visual hands-on squeak-like familiarity of objects land) , that's also why he said that imagination is more important than knowledge. I believe it's Alan
Re: [Edu-sig] Elementary graphics library
also want platform independent fonts (and I'm not sure how to get those best, wx uses sizers to get platform independent dialog looks, but the sizes may still vary across platforms). Maybe this 2D, 3D, and Python GUI efforts needs a web site or blog or something? Some place where the nitty gritty details gets hashed out? Might be one already? Kind of like this one for programming languages? http://lambda-the-ultimate.org/ But specific to Python and graphics and user interaction? http://www.google.com/search?hl=enq=python+graphics Might be something to think about if it does not already exist. --Paul Fernhout Dethe Elza wrote: On 5/28/06, Paul D. Fernhout [EMAIL PROTECTED] wrote: If you haven't already, you could check out: Also: PIL.ImageDraw http://www.esrf.fr/computing/bliss/python2/pil/PIL.ImageDraw.html http://www.pythonware.com/library/pil/handbook/imagedraw.htm The ImageDraw module provide simple 2D graphics for Image objects. You can use this module to create new images, annotate or retouch existing images, and to generate graphics on the fly for web use. Aggdraw http://effbot.org/zone/draw-agg.htm The aggdraw module implements the basic WCK 2D Drawing Interface on top of the AGG library. This library provides high-quality drawing, with anti-aliasing and alpha compositing, while being fully compatible with the WCK renderer. Matplotlib http://matplotlib.sourceforge.net/ matplotlib is a python 2D plotting library which produces publication quality figures in a variety of hardcopy formats and interactive environments across platforms. matplotlib can be used in python scripts, the python and ipython shell (ala matlab or mathematica), web application servers, and six graphical user interface toolkits. Kiva http://code.enthought.com/kiva/ Kiva is a multi-platform DisplayPDF drawing engine that supports multiple output backends, including Windows, GTK, and Macintosh native windowing systems, a variety of raster image formats, PDF, and Postscript. DrawBot/NodeBox (OS X only, but useful as examples of simple 2D systems) http://drawbot.com/index.html http://nodebox.net/manual/reference/topics.php DrawBot is an powerful, free application for MacOSX that invites you to write simple Python scripts to generate two-dimensional graphics. The builtin graphics primitives support rectangles, ovals, (bezier) paths, polygons, text objects and transparency. PyCairo http://cairographics.org/pycairo Cairo is a library for drawing vector graphics. Vector graphics are interesting because when they appear on screen, they don't lose clarity when resized or transformed. --Dethe ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Elementary graphics library
Paul D. Fernhout wrote: Just a thought: rather than a new GUI implementation, improving the Python GUI FAQ with lots of this information and pros and cons and so on might be a very valuable effort just by itself. So much of choices depends on specifics and tiny details. For example, I'm fairly happy with wx, but there is this bug with dragging certain widgets under GTK 2.6. And of course, I also want platform independent fonts (and I'm not sure how to get those best, wx uses sizers to get platform independent dialog looks, but the sizes may still vary across platforms). Maybe this 2D, 3D, and Python GUI efforts needs a web site or blog or something? Some place where the nitty gritty details gets hashed out? Might be one already? Kind of like this one for programming languages? http://lambda-the-ultimate.org/ But specific to Python and graphics and user interaction? http://www.google.com/search?hl=enq=python+graphics Might be something to think about if it does not already exist. To answer part of my question, there was a Python GUI sig but it got retired in 1999. And I can't access the archives for some reason (when I wanted to see why): http://www.python.org/community/sigs/retired/gui-sig/ The link: http://mail.python.org/pipermail/gui-sig/ goes to: The requested URL /pipermail/gui-sig/ was not found on this server. There is the ongoing Python Image Processign SIG http://www.python.org/community/sigs/current/image-sig/ though I had thought that was more oriented around the specific PIL package. It seems to me that graphics are a powerful way to show people something in terms of education, as well as a powerful way for kids to learn about themselves through visualization, so having all these choices made neat and tidy on a web site (or log kept up to date) for beginners or educators who want to make software seems like a good thing. Presumably the demise of Gui-sig suggests it is hard to keep up that sustained level of interest? But I know I see questions on this on the Python mailing list (i.e. what GUI should I use) all the time. Before this question was asked here, I had never really thought about how many options for Python and graphics and GUIs there really are -- dozens it seems. So, clearly any sort of effort put in this direction (including the original poster's plan to make simple wrapper) is going to be in the right direction. --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Elementary graphics library
If you haven't already, you could check out: Pyxel http://bellsouthpwp.net/p/r/prochak/pyxel.html Pyxel is a python library that provides a dynamic, interactive, highly portable, graphical environment. It makes diagrams and widgets look identical in whatever underlying environment it supports. wxOGL http://wiki.wxpython.org/index.cgi/wxOGL The OGL library was originally written in C++ and provided to wxPython via an extension module wrapper as is most of the rest of wxPython. The code has now been ported to Python (with many thanks to Pierre Hjälm!) in order to make it be more easily maintainable and less likely to get rusty because nobody cares about the C++ lib any more. (bottom of that pages has more alternatives, like the next) Piddle http://piddle.sourceforge.net/ PIDDLE is a Python module for creating two-dimensional graphics in a manner that is both cross-platform and cross-media; that is, it can support screen graphics (e.g. QuickDraw, Windows, Tk) as well as file output (PostScript, PDF, GIF, etc.). It makes use of the native 2D drawing calls of each backend, for maximum efficiency and quality. It works by defining a base class (piddle.Canvas) with methods for all supported drawing primitives. A particular drawing context is provided in the form of a derived class. PIDDLE applications will be able to automatically select an appropriate backend for the user's environment. and of course PyGame or PySDL or even the OpenGL Canvas stuff (there are probably more) for ideas and to see what others have done before in pure Python and you could possibly build on. Or even PyGeo if your focus is mainly on geometry instead of arbitrary 2D graphics (I wasn't sure). There are a lot of charting and plotting and other graphics packages out there with Python bindings (including Cairo, which you are looking at as your first backend target). You can ask yourself if a newer API really gets you that much over these existing things? Will it really be that much simpler once you really try to make it useful? And if you have a crossplatform backend already like Cairo or wx, does it gain you that much to abstract above that if can you simplify it somehow, versus just make a simple interface to one cross-platform library (which may be hard enough)? Now, it still might be worth doing for you even if the answers are no, but to maximize your effectiveness it is nice go in with your eyes open about whether you are doing this to learn and to have fun, to improve an existing thing, or to make something new that fills an empty niche (or to try do do all three); that is a question I often wrestle with for my own projects. :-) --Paul Fernhout Johannes Woolard wrote: As part of my Summer of Code proposal, I said i would write a simple graphics library. I've spent the last couple of hours brainstorming this, and written it all up: http://crunchy.python-hosting.com/wiki/GraphicsDoc. If anyone has any comments/ideas I would love to hear them! Johannes ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] new python // and /
I would just like to point out that Python (compared to Smalltalk) http://www.smalltalk.org/articles/article_20041008_a1.html has always done division wrong, and the new approach still does division wrong, IMHO, from a mathematical (not implementation) perspective. :-) In a dynamic object system, especially one oriented towards beginners at all, the proper result from division of two whole numbers is a fraction. Fractions can be represented as a special type of mathematical object different from either an integer or a floating point number, with the order of promotion when mixing various types being integer - fraction - floating point. Multiplying two fractions should still yield a fraction (unless it reduces, e.g. 3/5 * 5/3 -- 15 / 15 -- 1). Smalltalk has done this for twenty plus years. It's the way mathematicians work on the chalkboard (if any still do. :-) when working with equations and reducing terms. It lends itself to generalizations, like including units into expressions and reducing or multiplying units. if the mathematics library is written to be extensible. It's the way grade school math is taught. It avoids a loss of precision (converting, say, 2/3 to the imprecise 0.3) until explicitly required (e.g. float(2/3)). If you want a float from a fraction, then in such a system you should generate it yourself, either by making one of the numbers a float (e.g. 3.0 / 5) or by taking the fractional result and converting it to a float (float(3/5)). Obviously float(2/3) in Python as it is now yields 0.0 not 0.59998. Python as a community is still stuck in an integer vs. floating point mindset left over from C, IMHO. Having said that, I don't necessarily think Guido is making the wrong decision for the overall Python community or language, e.g. his comments here: http://mail.python.org/pipermail/python-dev/2001-March/013587.html Just one example of how when a language goes down one path from a set of choices, it kind of gets stuck with them, and builds a community comfortable with those decisions (where others uncomfortable with them use other systems); the same is generally true for mailing lists about any topic :-). The bigger issue here is actually that in Smalltalk these sort of things are done by user accessible libraries, and so you could use a different math library or extend the current one without changing the language, whereas in Python (especially in the past) they are more under the covers hidden in C and built into the system, at least as far as is generally thought and discussed. Still, here is Python implementation of fractions done by Mike Hostetler: http://users.binary.net/thehaas/fractionpy.shtml (haven't tried it myself though.) So, it is possible. And as Python moves to more generally unified types and objects by default, stuff like that may be done more and more as more people think of it. And I think it would be nice for a standard to evolve for that, especially from a using Python to teach mathematics standpoint. Personally, I think that since one isn't going to be doing much serious number crunching computation in Python itself (compared to NumPy or some other library accessed through Python) that having fractions in Python isn't much of a performance issue in practice (more a coding style change if anything to be explicit about floats). But it certainly is a potential major compatibility issue, so I can see the argument for the current approach, although to be fair, any minor change affecting math is a major compatibility issue, and the current behavior of 2/3 == 0 is always surprising. It would seem problematical to beginners to need to learn yet another operator, yet another inconsistency, and so on, before it is needed; I have no problem by itself with a // operator, which is useful in special circumstances, as is one to yield a remainder, see for example: http://mail.python.org/pipermail/python-list/2001-August/060184.html So I think from a pedagogical point of view, getting kids to use // when / really should be OK at the start and maps onto the infix syntax they already know is at the very best an ugly necessity to gain other Python benefits, given how Smalltalk shows that operator is not needed for routine mathematics or for beginners. Still, given the current situation, I think your suggestion makes sense. --Paul Fernhout Andrew Harrington wrote: As I gear up to write or translate lessons for Crunchy Frog, I would like feedback on one general issue: // -- the new integer division operator. // is already legal in Python 2.4, though / still means the same thing for integers. That is to change in Python 2.5, that is already in alpha 2: / as integer division will able to be set to mean the old operator or always mean real division (I forget which is the default in 2.5). I think this is an excellent change in Python. I would encourage using // for integer
Re: [Edu-sig] Refocusing on Capabilities (was PySqueak)
kirby urner wrote: About your prototyping experiments: I'm interested in learning more about Self and would gladly attend lectures on same, at OSCON or wherever. Then I could better follow your logic. Save yourself the airline fair :-) and just watch online: http://video.google.com/videoplay?docid=5776880551404953752 or: http://www.smalltalk.org.br/movies/ At least to see the basics. For textual statement of the key issue, see: http://en.wikipedia.org/wiki/Self_programming_language The problem: Traditional object languages are based on a deep-rooted duality. Classes define the basic qualities and behaviours of objects, and instances are a particular object based on a class. ... Unless one can predict with certainty what qualities the objects will have in the distant future, one cannot design a class hierarchy properly. All too often the program will evolve to need added behaviours, and suddenly the whole system must be re-designed (or refactored) to break out the objects in a different way. Experience with early OO languages like Smalltalk showed that this sort of issue came up again and again. Systems would tend to grow to a point and then become very rigid, as the basic classes deep below the programmer's code grew to be simply wrong. [My note: I think Squeak got to that point of rigidity long ago. :-) ] Without some way to easily change the original class, serious problems could arise. ... In general, such changes had to be done very carefully, as other objects based on the same class might be expecting this wrong behavior: wrong is often dependent on the context. ... The problem here is that there is a duality, classes and instances. Self simply eliminated this duality. ... This may not sound earth shattering, but in fact it greatly simplifies dynamism. If you have to fix a problem in some base class because your program has a problem, simply change it and make copies of that new object instead. No other program will see this change. ... This dramatically simplifies the entire OO concept as well. Everything might be an object in traditional system, but there is a very fundamental difference between classes and instances. In Self, there isn't. Now this perhaps paints an overly rosy picture of the solution. In practice, how libraries are written and what tools you use make a big difference too. And Python's use of namespaces make possible management of some of these issues in a different way. Still, I think there remains of core of truth to this, at least as a sense of the overall tone of development. You really need to see it in action, like with the video, to really grasp what is possible and what is different about, at the very least, the GUI development paradigm (which in some ways is not that unlike Delphi or VB, but applicable to even regular objects). My layman's question, after reading your posts, is: why not just keep Python pythonic and Self selfish? In other words, Python already has a very strong paradigm, very simple to learn. Why mess with that? I guess I'm a purist in that regard. But that doesn't make me a language bigot, as I fully respect the right of other languages to define themselves around equally strong, yet different, paradigms. I'm also biased towards OO. That doesn't mean I think the lambda calculus people can't hack their own brands. They already do, and quite successfully by the look of things. This is a good question and a good related comment. In general, you are right of course. And I understand your point about language bigotry. I agree, and I think it is not bigotry to say a language does certain things well, and if you want to do those things well and easily, stick with its mainstream approach. Languages have cultures and paradigms, and you swim against them at your own cost (especially in terms of productivity). Still, I wonder if dominant paradigms in the future will be mainly OCaml (or a derivative) as a better C, and something derived from Self (maybe with Python syntax) as a better Smalltalk. I understood the value of OCaml much better when I stopped thinking of it as a Python or Smalltalk replacement but instead as a C/C++ replacement. I'm not even sure the OCaml community sees themselves that way; they almost certainly don't. :-) Python is stuck in the middle there, and sometimes that is a great place to be (especially at the right time), and sometimes it isn't (especially if times change, in part due to its own success). I feel Python as a community right now as it contemplates its own evolution is torn between types and prototypes. Like Squeak, it has developed its own approach to solving the type problem by having a mini-language in the PyPy project, but, while I think it is a neat thing to try, I am left wondering if perhaps it might be better to just use something like Ocaml for that purpose. As an analogy, I read there was a Basic English that all aircraft pilots and control
Re: [Edu-sig] Accessibility to non CS types?
kirby urner wrote: Now they open a tutorial or book on such as Python, and immediately feel lost. There's a lot of new jargon, and not many references to languages they already know. Where is Python for Pascal programmers? As in my longer email previous, I think part of the answer is in better tools and libraries, and that is why HyperCard, VB, or Delphi became popular. While TK is nice, not having a good generally purpose default GUI development system with the power of, say, Hypercard that everyone points to as a no-brainer for any beginner to use is a weakness from a beginner standpoint IMHO. I think Self leads the way here in generality with one inspector that can be used to build GUIs, programs, or just sets of objects. And here is an attempt to bring that ease of use to Python, building on ideas from Self (and Squeak): :-) http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/PataPata.py?view=log Doesn't succeed yet perhaps in making that beginner friendly, but a start. (PythonCard is much better choice for current work though.) --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Refocusing on Capabilities (was PySqueak)
kirby urner wrote: Say, Kirby, speaking of data rich content, can you suggest any Bucky Fuller-ish or synergetics-type graphics or clip art under a free-as-in-freedom license somewhere on the web I could use to spice this demo up when I move beyond having everything in one file? Click around in my websites. A lot of what's in synergetics is generic concepts organized in sometimes novel ways, but not owned in the sense the icosahedron is not owned, nor the sphere packing lattice we call the CCP etc. So often what's fun, given Python and a few tools, is to generate one's own images (no permission required). Excellent idea. And probably what I'll do if I go down that path. Thanks for the suggestion. Now just to get a three-D turtle going again in Python... :-) However, if you want already-ready images, there's lots at grunch.net/synergetics. If you have any questions about a specific image, just sent me off-list email. Thanks for the generous offer; I may do that. == a bit of a copyright and licensing rant follows, but it is not meant personally === In practice, though, as a free software developer who dislikes paperwork, it's probably more work to ask (perhaps multiple times as new things are of interest) for permissions than it is worth, compared to, as you suggest, doing my own stuff programmatically (or otherwise). In practice, I almost never think something is worth using enough to ask for permissions; I just don't use it and look for something else, or I even abandon the project. I also would have to trust a longer copyright paper trail. This is not to suggest anything sleazy by anyone, just that it's easy in copyright issues for miscommunication or misinterpretations to arise as to what is permitted when someone other than the original author or copyright holder makes a formal statement. So what one person who knows the author or current owner thinks they can do safely often looks a lot less safe to someone else coming at things second or third hand and relying on indirect representations. Looking for stuff that is already clearly licensed is generally just easier, like at: http://www.openclipart.org/ which links further to various other similar sites: http://www.openclipart.org/wiki/index.php/Similar_Projects [No Bucky stuff I could find though.] Googling on free clipart first leads me to commercial sites it seems. :-( Are there any other good free clip art sites people recommend for use for clip art for Python programs? Or perhaps now that I think of it, Wikipedia could be a source: http://en.wikipedia.org/wiki/Buckminster_Fuller There are two GFDL images on the Bucky page. Or more broadly, lots of GFDL images here: http://en.wikipedia.org/wiki/Category:GFDL_images Unfortunately the GFDL license is GPL-incompatible! I've already had words with Richard Stallman about this, :-) but so far I haven't been able to get him to acknowledge how evil GPL-incompatibility is for a content license (especially one the FSF promotes)! :-) From: http://en.wikipedia.org/wiki/GNU_Free_Documentation_License The GNU FDL is incompatible in both directions with the GPL: that is GNU FDL material cannot be put into GPL code and GPL code cannot be put into a GNU FDL manual. See also: Why You Shouldn't Use the GNU FDL http://home.twcny.rr.com/nerode/neroden/fdl.html which suggests, among other things, just using the GPL instead for content. Ironically, this FSF page expounds on the problems with some Creative Commons licenses being GPL-incompatible, http://www.fsf.org/licensing/licenses/ but is strangely silent on GFDL/GPL incompatibility issues which IMHO are similar. I'm hoping that incompatibility gets fixed in later versions of the GPL or GFDL. I've already had it make impossible another project (building GPL-d simulations based on Wikipedia content). I'm not sure yet on Python-license and GFDL content compatibility; I think they might work, except the GFDL would take precedence and might not really give permission to run the combined work? I'm really picky about these licensing issues, because it is so easy to use something incorrectly and recently the formerly civil problem of copyright infringement in the USA has been turned into a criminal offense (felony), and though it is not yet often enforced, it is made easily enforceable by broad interpretations of what it means to make a profit from redistributing something. http://www.usdoj.gov/criminal/cybercrime/CFAleghist.htm See also for example this slashdot article and also my comments here: http://yro.slashdot.org/article.pl?sid=05/11/13/1624200 So, best to stay on the safest ground when possible and when building stuff for others to use, and an example of the chilling effect of such copyright legislation on innovation in the USA (or, another infrastructure problem :-). Joe Moore has a lot of images. Plenty of other sources. Fuller School is definitely data rich (huge
Re: [Edu-sig] PySqueak: More on Croquet and 3D
kirby urner wrote: That will never happen, except sure, maybe *some* people will eat their own dog food in this regard. In general though, people are too curious to ever alight on one generic omniembracing containment system. That's what reality is for. Within reality, all GUIs are special case. Good point. Funny thing is, as I think about it, that Croquet to some extent perhaps repeats the thought of the original Macintosh Desktop -- that is, give people a desktop they are comfortable with and they can easily use it. The problem is, that things didn't always do what people expected, and the desktop metaphor can be pretty limiting. By the way, as I though about your use of first person (I) and third person (he/she/it) for interface types (exemplified by 3D shooter vs. 2d map with markers) I realized that for completeness one should consider second person (you) interfaces, which I would think would be more like conversations, e.g. (Computer, you should really print out my reports, please. :-). [I have worked somewhat in the past on such speech driven second person interfaces.] Likely there might be other versions related to tense or indirect reporting of things. Some more ideas here: http://en.wikipedia.org/wiki/Grammatical_person From there: The grammar of some languages divide the semantic space into more than three persons. The extra categories may be termed fourth person, fifth person, etc. Such terms are not absolute but can refer depending on context to any of several phenomena. That being said, let's use Croquet sometimes, why the hell not? I'd especially like it on a much bigger screen with a projector, and with less of an Alice in Wonderland flavor (I've already got Alice, the computer game, which twists the scenario into something darker and more gothic -- closer to Batman in flavor, and therefore more comfortingly all-American in my book (but who wants something that twisted for an interface? (we should at least be able to skin Croquet in some dimensions, according to personal taste, if it really purports to be more of an operating system and less of an application))). Interesting idea... Some will experiment with other shapes of screen. Imagine the challenge of fitting a GUI to an hexagonal frame. Very Klingon. Very Dymaxion. Definitely the promise of making systems you can glue together. By the way, no hexagons yet, but this project http://sourceforge.net/projects/patapata is up to proof_of_concept_021.py http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_021.py?view=markup which finally has gotten to the point where I can edit what morphs do in a very limited sense. You have to put your code in like this: PrototypeMethod(self, def grow(self): print 'grow changed'\n) and you can only modify existing methods. These proof of concepts have brought home hard one major language impedance mismatch issues trying to use Python to be like Self or Smalltalk: Python is oriented around supply a function and then calling it, whereas Smalltalk and Self are oriented around message passing. Thus, implementing doesNotUnderstand is possible in Squeak/Self, as is executing code on simple accesses (e.g. self spam), whereas under Python I can't assume what someone retrieving a function or variable plans to do with it. That also leads to the issue of dynamically wrapping methods and the overhead for it in memory and computation in Python. Also, I need to think through initialization better, because otherwise prototypes which are filling the role of classes have their lists or dictionaries shared across all instances, whereas I really want those per item. I have a workaround in place but I don't like it. And that gets back to a problem with my very first prototype using TK, where I copied a prototype which inherited from a TK widget, but the widget itself was not duplicated. I guess I could duplicate that widget as part of a special init or copy constructor. If I can manage that trick, then I could have a hope of embedding TK or wx widgets into a world of prototypes. I've continued to look at other languages in terms of how the approach some of these issues, and came across this little idea: http://www.paulgraham.com/popular.html The best writing is rewriting, wrote E. B. White. Every good writer knows this, and it's true for software too. The most important part of design is redesign. Programming languages, especially, don't get redesigned enough. To write good software you must simultaneously keep two opposing ideas in your head. You need the young hacker's naive faith in his abilities, and at the same time the veteran's skepticism. You have to be able to think how hard can it be? with one half of your brain while thinking it will never work with the other. The trick is to realize that there's no real contradiction here. You want to be optimistic and skeptical about two different things. You have to be
Re: [Edu-sig] PySqueak: More on Croquet and 3D
kirby urner wrote: Computer games will often emulate both aesthetics, as does ordinary fiction. We're accustomed to a mix of first and third person. You put it perfectly. And I think that is what bothers me about Croquet in a sense as a proposal for the interface (especially for kids). The Croquet approach chooses to focus all interaction with the system through a first person 3D world on the computer display, with third person applications perhaps within that (e.g. a simulated sheet of 2D graph paper in that 3D world). I am more accustomed to think of the computer as displaying third person information, and then sometimes I'm willing to suspend disbelief for a first person interface within a window on that third person desktop. Even if the window takes up the entire screen (or all screens :-), I know the third person perspective lies underneath it if I stop that application. Ignoring the RD aspects of Croquet (it's a good effort, breaks new ground, etc.), right now, I don't think computers (and interface technology) are not going to be close enough to 100% reality to make it worthwhile to channel all our interactions with them *first* through a first person 3D view. Certainly, if we get the Holodeck (with smell and force feedback) I'll revise that opinion. :-) And so also, from a perspective of priorities of making Squeak-like or Self-like things happen using Python in a learning (or developer) context, I think the Croquet aspects are less important than the interactive 2D tools aspects. By the way, the seventeenth proof of concept of Prototypes in Python with the rudiments of a tree browser for 2D Morphs (though the browser is in wx): http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_017.py?view=markup Anyway, I think the degree of realism needed, and in what dimensions, is very application-specific. That's why it's dangerous for the OS to weigh in too heavily with a graphical view. [snip] I don't imagine oil executives want cartoony avatars on screen, but having all present gaze upon a shared view of some new drilling area, complete with high def representations of rigs, pipelines (current and projected), equipment and crews, makes the meeting more effective and productive. You're absolutely right here. I think 3D is a great thing for visualizing data to understand issues and help solve problems, and a great way to communicate whatever the 3D representation chosen (realistic to whatever degree or even totally schematic or even mathematically abstract). And I can even see the value of ActiveWorlds type 3D with avatars for occasional meeting or even specific projects. To be clear, and to agree here, I have nothing against 3D. I was playing with VTK and the Python bindings for it the other day as on possibility for an underlying toolkit for a PySqueak, and can see the real value of it for looking at scientific data in general using Python. And I can see further how working in 3D could be very motivating to learn programming (if the package makes that easy to do, such as VPython or Alice attempts). And I think Croquet is a wonderful attempt to make it easy to do 3D collaborative applications. But, in considering Croquet as the evolution of Squeak as a kids programming environment I see an implicit intent based on my interpretation of Alan Kay's intent (perhaps in error?) that Croquet is what we should all use all the time when we are at the computer. I think that implicit intent is what bothers me, because, perhaps conditioned by experience (?), I think approaching the computer (as it exist now and for the next ten to twenty years) expecting a third person experience is better (i.e. more flexible, less disappointing, more effective for most tasks) than approaching it expecting a first person experience (where that first person experience will be missing things for the foreseeable future). Anyway, a philosophical point of interface design for me to muse over some more. --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] PySqueak: More on Croquet and 3D (was: Just ran...)
kirby urner wrote: All good RD Paul. In my book, these are some of the deep issues, and finding the right combination of libraries is not an easy job. Regardless of the ultimate fate of your particular project, you're adding to your repertoire plus carving out the basis of some kind of graphical framework others might use, and that's a positive thing. Thanks for the kind words. Also, I am forced to wrestle with the issue of what are my specific subgoals here (thinking of a PySqueak which is easy for beginners to use and experts want to use as well)? They sort of are, roughly speaking: * to have Self prototypes in Python as an option (check, though inefficient :-), * to have a Self GUI in Python (brooding over), * to port our 3D educational software to Python and this system (half done, the translating to Python part, but need to settle on widgets), * and to make Python development with running systems as interactive and fun to use as that of a modern Smalltalk (just scratching at the network debugging approach outlined earlier, but also already have the reloader window I use with Jython), * 3D simulated worlds in Python (less importance now to me, but of potential long term interest in terms of simulation). I've been trying out the latest version of Croquet some more as I ponder this 3D and widget issue. I think I am getting past the Wow factor -- though it still remains pretty neat. Of course, as always, I was impressed more by watching the Alan Kay presentation videos like of drawing a fish in 2D and having software make it 3D and swim away than by using it myself. http://video.google.com/videoplay?docid=-9055536763288165825 Ignoring some walkbacks and exceptions when starting some of the demos, par for the course for my experience Squeaking, what I am left with is the same feeling I get when I watch pretty good 3D modeling of people -- which is sometimes a bit disconcerting (in a bad way). :-) To explain, when you see cartoons of people, or mechanically rendered sprites of people with no serious attempts at skin texture or hair luster, you think, wow this is cool, and it is fun to look at. In my mind, that is something like using 2D apps or the command line. It does cool things its own way, and you can respect that. You get the immediacy people here talk about, and having no (or few) expectations about what it should do base don reality, nothing feels wrong (although it may still be confusing). But, when you look at images of people rendered in 3D that is pretty good (say 99%), they often look like corpses, because they are good enough to set in motion a whole bunch of reality based expectations we have for how other people should look, while not meeting them. Slightly drab hair? Maybe they are sick? Skin that looks like rubber? A sign of death. For more on this, see: Realistic Human Graphics Look Creepy http://games.slashdot.org/article.pl?sid=04/06/10/1327236 http://www.slate.com/id/2102086 [article discussed] So, by analogy, when you make fairly realistic 3D environments, but not 100% realistic, you may be worse off for trying, because you raise expectations you can not fulfill, and the differences make people unconsciously feel uneasy, creepy, or frustrated. To be clear, I'm trying to make an analogy here; Croquet as a 1.0 beta demo does not attempt realistic human avatars, just a silly bunny rabbit avatar which looks cute. My point is about the 3D world aspect versus the real world. So, in this case, with Croquet and 3D, perhaps more realism is actually a worse experience. And perhaps that unconsciously drives some of Alan Kay's interest in better 3D rendering? Yes, in theory you can get really good, but until you get there (when? 2020? 2040?), the results are sometimes almost more disappointing the closer you get to realism. I think Croquet may be facing that in the 3D realm. It activates expectations, like moving in 3D, but then you are confronted with how awkward it is to use the mouse to virtually walk. You see a cube of blocks that invites you to take one, but when you put it back, there is no gravity to make it drop back into place, so it just oddly floats there. A slip of the mouse and the rabbit falls off the green carpet, to where? And it takes a bit of slogging to get back to anywhere interesting. I can see portals, but I can't shortcut click to them; I need to proceed slowly to them, and if I could click, and I suppose there is some trick perhaps, then I break the experience. Obviously, specific popular 3D games solve many of these problems within the game in a fun suspension of disbelief way, and can be entertaining for twenty hours or so, and even leave you wanting more, e.g. a recent favorite of ours: Beyond Good and Evil http://www.gamespot.com/ps2/adventure/beyondgoodevil/ but, they do not seek to be the comprehensive life-time-of-use experiences that Croquet is implicitly claiming to be for right
[Edu-sig] PySqueak: Which 3D package should I use?
Well, I've finished a simple 2D proof of concept with prototype inheritance and some user interaction of dragging (using wx): http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_010.py?view=markup (Just dragging five related squares around, but shows basic prototype ideas in a Pythonic? style, i.e. initially you drag a parent and children move, then you drag a child and it no longer tracks the parent x,y as it has a private copy of x and y after dragging.) So, now I'm thinking of making a simple 3D version. But what 3D library to use? This has been discussed here before, for example: http://mail.python.org/pipermail/edu-sig/2003-April/002789.html but I wanted a current perspective three years later (if it has changed). The (enviable) problem is that there is so much to choose from now! See this list for example: A small collection (72 packages) of pointers to Python software for working in three dimensions http://www.vrplumber.com/py3d.py Which should I use from all of those 72 packages? Obviously, that depends on my needs. In the past, we bundled our own 3D graphics engine (a 3D turtle) into what we wrote, but it does finally seem like 3D graphics are common place. So, I want to go with the best current standard, and that seems to be OpenGL. In the short term, for PataPata (my PySqueak) proof of concept tests, I just want something 3D-ish that I know other people will have an easy time installing alongside their regular Python 2.3/2.4 distribution. First, I just want to put up some 3D objects that people can drag around. That's fairly simple. But later, I want to pop up GUI elements (menus, lists, editors) to support people doing Self-like things. That's harder. So, here are the longer term needs: * Python bindings (obviously :-) * OpenGL based (to get hardware acceleration). * Good current level of support and longevity. * Easy installation and configuration on Mac OS X, Windows, and GNU/Linux. * Existing support for at least the rudiments of GUI widgets in the 3D. * Not a moving target. :-) [Though perhaps I could compromise on that point if it was very cool.] I'm OK with it being complex as I plan on hiding that. I already know 3D graphics, e.g. have written my own 3D turtle and learned 3D on the SGI, though that was all many years ago, but still, I'm rusty. License really doesn't matter to me as long as it is free in a FSF sense and can be in the free part of a Debian distribution. Being lazy, and short on time, it would also be nice if it already easily handled issues like managing a world of 3D objects and knowing which was clicked on (and where). Here is an overview of that issue: http://pivy.tammura.at/documentation/pycon That issue of easily displaying 3D objects and then mapping from mouse clicks back to what is clicked on are key to the application in the long term, if I were to emulate any of what Croquet can do. It would be superb if it had widgets with openGL (lists, text, etc.) with Python bindings. Even for that, using GLUT, there are a few choices on the vrplumber page above. I have not used any such packages. I don't want to emphasize that too much though. I'm OK with working with simpler components. So it doesn't have to have everything. And it is possible I might just punt on that for now and have a separate 2D GUI for that sort of stuff. If displaying 2D widgets in 3D makes the selection of 3D graphics packages harder, even though Squeak has it, I'm OK right now even with a compromise that the 3D environment might have control panel objects that when you got close and clicked on them you got a separate 2D window in wx or TK on your system where you could do the usual GUI things (with sliders, etc.). In general, right now I'm fine with having a system that mixes 2D and 3D windows for different activities, though I'm sure how to do that best may be an issue, and I can see the merit of having everything in 3D to make it easier to share visible state across multiple users. Anyway, I'm wondering if I should just go with PyOpenGL, or maybe the OpenGL Context, at the start, as being fairly easy to install with the least dependencies? (I already have that running on my Debian GNU/Linux machine, though with some issues.) But other choices like VTK as a base or maybe even using Blender somehow certainly look intriguing. And, looking through recent discussions, maybe I should look harder at Soya, at the very least to get a sense of how they used various technologies? http://home.gna.org/oomadness/en/soya/index.html (Looks like it is very Python oriented, but Tom Hoffman suggested it was a tougher install...) Still, there is so much to choose from. For example, SLUT addresses issues I'd have down the road with Croquet style networking: http://slut.sourceforge.net/ From there: Slut is a programming framework for generative, synthetic, interactive, network-enabled graphics. And from:
Re: [Edu-sig] PySqueak: more on the cultural divide among paradigms
John Zelle wrote: [Thoughtful outline of important design point (and differences in priorities) snipped.] I know I'm asking a lot, but I also think it's all doable. This to me would be the foundation for a better than Squeak Python environment. The saving the state issue seems secondary to this basic foundation. How can we even talk about saving the state of widgets that we don't own. On saving the state of non-Python widgets we don't own, in theory, a well written widget set like wxWindows should support queries on all the states of all widgets. Still, in practice, sometimes they assume you will remember externally what state you set something to, especially if they pass the value on to another layer (like the OS). For example, what if a bitmap is somehow converted into a native representation and the original discarded (not sure this is a problem, just making one up)? But I think those cases could be ignored at the start? And then treated as bugs in the widget set API? Clearly the most common things for having a list or text box selection or label, those should all be queryable. But, having not tried to do this, there could easily be unexpected gotchas, especially moving across multiple widget sets. I know in years past I have had this problem of missing accessors when writing code for applications that want to restore their exact window layout on reopening. And clearly, you could not move a saved image to a platform without bindings (and probably the same version of bindings) for the widget set the image was saved using. But in any case, while this is a vexing problem, and likely entails writing lots of widget specific code for each widget set, essentially it just involves creating a function for each type of widget that knows how to query and restore its state. However, obviously, that is a lot of code, and then it has to be maintained, and perhaps special cases ad widget sets changed. So, mostly doable I think (especially with something like wx, where you can submit changes to the project to fix access bugs), but a pain. But I agree that if you design your own widget set using Python code, and it is represented by Python objects, then any major concerns about this save/restore issue go away. And I don't think this is reinventing the wheel as much as one might think, becuase any project with a compatible license coudl be looked at to get ideas or code for these basic widgets. For example, Lazarus and FPC if you can live with the LGPL license (and I conveniently have written a Delphi-Python translator that does 80% of the translation work. :-) And I'm thinking now that even just the basics (using native fonts, like with a wx canvas) might be good enough for a proof of concept system, since you can do a lot quickly with a just text, icons, lines, and colored boxes (even without embedding dynamically generated bitmaps and bitblit!). You can build a whole development environment with mainly lists and menus (a wrapping text box for code is the hardest part). But it will probably look like the first released (1.13?) version of Squeak (until a lot of more work gets done). :-) --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] PySqueak: Self as the source of many ideas in Squeak
Ian Bicking wrote: Zope went down that path with through-the-web development with the ZODB as the image. I think everyone agrees that didn't work. Smalltalk has pursued that with more vigor, but I was never comfortable with the image. In some ways you can read my comments as me figuring out just why I dislike the image model. Well, everyone? :-) Check out http://www.1010wins.com/ for what was, last I heard, a major Zope site. Still, a lot of peopel agree with you, so there are clearly issues here. For all I know, that group is unhappy? I myself like images you can build from text when you want to, but that has never been the focus of most Smalltalks (and isn't for Squeak so far). But, I think a truly Pythonic approach might insist on building objects from text, although it is true that we have pickle, which uses text, but not as a Python program. I think it's important to figure out, because the image model seems very compelling for an education environment. And John also made some of those points indirectly. I think from a classroom standpoint, teachers generally want to be in control of what the student sees, at least at first, and they also have short classes (45 minutes) where they do not want to waste time on configuration. So, preparing an image for kids and seeing it pop up exactly like you made it, whatever the hardware (like Squeak can do) is a big win in a classroom setting. Of course, I'm not big on conventional classrooms :-), but I think images are desirable for independent or informal learning as well, which can happen in fits and starts, where you might do something intensely for days and then not revisit something until months later. And it would be nice if everything was just the way you left it. Also, as a developer of (hopefully open) educational simulations, I see the value in being able to deploy the simulation as an image which people could then modify to their own needs. So this is an area of overlap regardless of educational paradigm. Granted though, if you want to learn about the details of the machine you are on, or the notion of a software stack, like Kirby pointed to a week or two ago, in terms of getting into the specifics of GNU/Linux, then images are hiding stuff you might want to make visible. (Of course, you could open a terminal window from your running image. :-) I think a big issue with images is that they presume that you will put in the time to learn the tools assembled in the image (assuming the image is mainly about learning programming) rather than use some older ones you are comfortable with already. It is much easier to type text on the command line or use your favorite text editor than to learn an IDE (especially when you are learning a new language at the same time). But the value of learning an IDE can be immense in terms of letting you manage complexity far beyond what you can do with a text editor. It is funny how we can all accept that learning to play a musical instrument like the flute might take years of concentrated study to even get a good tone out of it, but we expect computers to be engaging on a minute by minute basis. Or, we just accept that learning to touch type takes days of practice. But computer IDEs? Do they really need to be like video games, engaging and addictive from the first quarter? John Holt wrote on this when he talked about hard fun (also mentioned here recently in another context I think) and how playing music, considering the suffering involved to get good at it, could hardly be described as fun, but there certainly is something there for many people that keeps it engaging as a transcendental experience (as a sense of flow). Still, I think people here are right when they suggest typing at the command line an doing text processing produces feedback that keeps people engaged. The question is, can a graphical IDE do that, and I think the answer with Self might usually be yes. I think the answer with Squeak is sometimes no though, but I have real experience with that, and have still never used Self. :-) Still, the E in CP4E is about Everyone, so I can see the value in trying to make things accessible to broader audiences. My hope is that both the expert and the novice can be satisfied by a better system, and I think Self (or to a lesser extent Squeak) helps show that way, prudcing a system I can love as an expert, but (taking their word for it, at least for Self :-) I think novices can warm to quickly as well. That gets back to the point I made on innovation -- satisfying both needs at once (e.g. expert and novice both love it) rather than compromising somewhere between them (e.g. not so hard for novices, but not so interesting for experts). I can see the value of all this from the GUI side, with various desired display options defined in the class or prototype. But again, Python object are (or should be :-) constructible from scratch without calling a
Re: [Edu-sig] PySqueak: Self as the source of many ideas in Squeak
Ian Bicking wrote: Some things other people have done (like Logix: http://livelogix.net/logix/) makes me think that this could be done in CPython now, with just some fiddling in the compile process. I think the Python object model (which can't easily be changed) is already flexible enough for this. And ignoring some syntactic details you could do this in current CPython. Interesting concept, to put it mildly. And also interesting under future work they say: http://livelogix.net/logix/future-work.html Although Python has provided a great launch pad for Logix, we may switch to another platform at some point. Efficiency and security are two areas that are somewhat lacking with a Python foundation. What are the alternatives? Maybe Mono, maybe Parrot, maybe C--, maybe LLVM... I know that is one of the reasons I still think about doing something (at least proof of concept) in Jython -- because it can piggy back on the Java JVM security model, and I might also consider writing a low level routine for handling networked programming in Java (if speed was an issue, after doing it all first in Jython). [But, I've also been looking at working with the Idle codebase too, by building on its RPC functionality.] Still, the less I can mess with the syntax the better, I think. That's why I lean towards just having one Prototype class. I think that Ian's suggestion is the most sensible strategy for proceeding in that direction and continuing to maintain community interest in a PySqueak inclined towards Self-like prototypes and a related GUI for constructivist educational use (and other general use as well). And if metaclasses turn out to not be the best approach, still anything simple which preserves the Python syntax while giving the new features (say, having all prototypes inherit from a common class which overrides __getattr__ and __setattr__ to simply look into the instance to find data and behavior?) I think it could be easier than that. I think a lot of the more declarative programming I do really has prototypes underneath it. (Ironically in Javascript I never find a need for prototypes, except to simulate classes.) Of course, you probably don't have a Self-like environment for Javascript. :-) Or is there one? I've never done much with JavaScript. I did once listed about 100 reasons to use VisualWorks Smalltalk over C+++ without having to talk specifically about object-oriented programming issues -- just focusing on the environment and the libraries and the VM and issues like garbage collection and integrated fine-grained version control. Anyway, I tried to follow your example, but I am still left confused as to how it is easier than creating GUI tools that manipulate all instances of just one Prototype class? Your example still seems focused on making classes. With one class, a few lines of code to search for values through parent slots and you're done? Essentially, for any prototype-ish work, one would just work with instances of this one class. Am I missing somethgin vital here? Are you thinking about one class per one prorotype object? Is that for performance reasons? Consider: class Prototype: ... def __getattr__(self, name): ... print name ... x = Prototype() x.spam(hello) spam Traceback (most recent call last): File stdin, line 1, in ? TypeError: 'NoneType' object is not callable Of course it fails trying to call the None returned by default in __getattr___ because the code just prints the field name, but you see I could just have that __getattr__ method look into a field of the object and return the function, or if it was not there, then start looking into parent slots and recursing until it found it or gave up with a call to a does not understand function (itself hookable). I do think there might be issues to resolve in how instances of this class interact with other python classes. But I am not sure how complex those issues are, since everything to Python still looks just like a typical python class. All calls work the same way? Or do they? The issues might have more to do with the GUI and it being able to handle dealing with instances of other classes, but that could be done in the usual way such as with inspectors and such that Idle defines. A bit klunky, but probably serviceable as a start? Anyway, something to think more on. A proof-of-concept Prototype class and a GUI to manipulate it should not be that hard. (Famous last words. :-) Designing programming systems is so easy when you stop caring about performance (at least in the short term). :-) But the advice I was given long ago is, slightly updated, is: by the time you get it debugged and anyone has noticed it, computers will be fast enough to run it. :-) Anyway, are there compelling reasons why creating one class per prototype is useful or better? Or maybe I am just missing something here. Perhaps it is confusing in that we are talking about
Re: [Edu-sig] PySqueak: Self as the source of many ideas in Squeak
Ian Bicking wrote: This is all not to say that modifying Python source in a manner different than ASCII is infeasible. Only that source and runtime have to be kept separate to keep this process sane. Images -- which mingle the two -- have never felt sane to me; clever, but not manageable. Well, perhaps sanity is overrated. :-) And Smalltalk has been managing this for thirty years. :-) But it is true, it requires a bunch of special purpose tools. Changeset browsers. A change log. External source code control. Image cloners. and so on. Probably a Python that stored a running image as Python program files might need some specialized tools too. And I will go further and agree that I find mixing running application state (like what windows are opened or what the stack looks like) with application data (your email, your accounts receivable) is pretty scary too. But again, one needs some sort of tools to help you with that, and there is no reason some things can't be in the image and other things not in it. In a Smalltalk system, generally there is at least a file with library source code and a file with user additions to that as a current change log. Although in the case of Squeak, it can decompile methods (if it saves comments) even if you don't have the source code. One of the people on the project (Alan Kay or Dan Ingalls?) quipped something to the effect that a Squeak image was really a source code compression algorithm with a development environment thrown in for free. But, a Smalltalk image is generally saved as binary objects. But now that disk is cheap and cpu cycles plentiful, storing an image as python program files seems OK to me resource-wise. Unfortunately we do not have very good abstractions in Python related to source, so they have to be invented from scratch. The AST might help, but higher-level abstractions are also called for. For instance, you might define a color interactively in some fashion, and the color gets serialized to: import color color.Color(r, b, c) That color object might be immutable (probably should be), but the *source* isn't immutable, and the source means something. How can we tell what it means? I'm not sure anyone needs to ever tell what that means, except the Python parser when it reads in the code and runs it (in the context of other code it also loaded). Obviously when code is being written out which can reconstruct a current object tree, then the writing process needs to understand what it means by each piece of code, especially as it might refer to previously defined bits to shorten or make more readable the output code file. But since it is writing the code, there should not be any ambiguities of intent. The hardest issue perhaps becomes making the results look as close to human written Python as possible (say, using class to define a class instead of making a plain object and turning it into a class by setting fields). I can imagine a bit of interaction between the source and the runtime to do this. For instance, we might see that color is bound to a specific module, and color.Color to a specific object. We'll disallow certain tricks, like binding color dynamically, monkeypatching something into color.Color, etc. Ultimately figuring out exactly what color.Color is isn't *easy*, but at least it is feasible. Using existing introspection we can figure out some parts, some of the sorts of things that IDEs with auto-completion figure out. They can figure out what the arguments to Color() are and the docstring. Perhaps you are thinking about this from the point of view of something like PyDev parser, which reads Python code to syntax highlight it and perhaps provide code assistance. But, since the code has already been read, and we are manipulating the object tree directly, we know what everything means, because we just look at what the objects are directly by inspecting them. Granted, some of those objects represent code, and the code may be wrong or ambiguous or confusing from the users point of view, but that is ignorable by the code writer, which just writes out the snippet of code the way a user put it in. But, you can also imagine adding an editor or other things to that object; a richer form of __repr__, or a richer editable form than the ASCII source. Maybe there would be a flag on Color that says it can be called without side effect (meaning we can speculatively call it when inspecting source); and then the resulting object might have something that says it can be displayed in a certain way (with its real color), and has certain slots you can edit and then turn into a new Color invocation. I can see the value of all this from the GUI side, with various desired display options defined in the class or prototype. But again, Python object are (or should be :-) constructible from scratch without calling a class' init function. So, given
Re: [Edu-sig] PySqueak: Self as the source of many ideas in Squeak
Ian- Maybe we are still thinking about different things here. I'm going on the presumption that Python, like Smalltalk, have various roots which are things like (in Python) the loaded modules, the active threads and their stacks, and perhaps some other state. A Python world of objects is defined by these, since if any Python objects exist but are not reachable somehow, they can't effect the system. As I reflect on that, I can see how in theory outside forces that get a handle into object memory might make changes and such things might exist in other processes or threads, but that would just be a broken VM (or VM abstraction) to me more than a problem to solve. :-) So, going on this assumption that all Python objects of interest are reachable from these roots (even if some of the roots themselves might be only known to the VM, like the current thread?) then a recursive procedure can flow down through from these roots and write one big text file consisting of mainly: # big module import lots_of_stuff temp1 = object() temp1.__class__ = Point temp1.x = 10 temp1.y = 20 temp2 = object() temp2.__class__ = Point temp2.x = 40 temp2.y = 50 temp3 = object() temp3.__class__ = Rectangle temp3.origin = temp1 temp3.extent = temp2 modules.mymodule = object() modules.mymodule.__class__ = Module # or whatever? modules.mymodule.myrect = temp3 And so on. Now obviously this gets tedious, so an optimizing writer would instead produce: # module mymodule myrect = Rectangle(Point(10, 20), Point(40, 50)) But that's a matter of a smart writer, which I think is doable. Just think of it as like optimizing code (although maybe in reverse. :-) Now the problem you point out, that there may be several ways to reference an object is obviously a real one. But a smart writer should handle that (with a little handwaving by me. :-) But essentially, like with pickle, the writer would know it has to write the definition for a function out somewhere, and so it would pick a good spot, and then other references to that function could refer back to the first place it was defined. (Or it could be put in a temp variable which was later deleted after it was done being used.) Even if the writer picked a bad spot, the problem would only be that the code looked harder to read and understand, not that it would not recreate the same objects in memory that were written out (though perhaps at different locations; I'm presuming that would not matter -- if it did, then that might be a problem requiring VM changes or some fancy object creation order footwork, which would almost certainly mess up the code's readability). As I've just casually glanced at the CPython VM source code, and only just a bit more at the Jython code, I don't know enough off hand to see whether there might be other bigger problems. Anyway, I still don't see a show stopper (unless it is specific object ids or exact memory locations being important -- perhaps affecting dictionary hashes or some such thing?). Difficulties yes, maybe painful ones, but no showstopper so far as I can see to writing out running code as Python files (again, unless the above object ID issue). I can see that nicer source will likely result from tracking commands as the user defines them, as you suggest. But still, my focus isn't on readable source. That's more a nice to have feature from my set of priorities for GUI oriented construction and programming. What I am more interested in is, can the running program be changed, and can the changes be saved so they can be reloaded? So, our priorities may diverge there, but that's OK -- makes life interesting. :-) --Paul Fernhout Ian Bicking wrote: Interactive sessions are source. The OB1 I referred to is the actual object in memory, which has no real name, though it can be referenced directly in memory. Maybe a better example is something in HTConsole right now. Any function you can get your hands on in HTConsole is editable, in-place. So you can do: import random random.choice And you'll get a form that shows the source to that function, and lets you edit it. That works fine in-memory. But saving that is hard. There's actually lots of ways to get access to a function. When you get random.choice, you are actually getting access to a method of a singleton stored in the random module. When you edit that, you are editing the method. How do you represent that edit as source? Do you see that the function is available as random.choice.im_func, or random.Random.choice? Or a property, which might be available as SomeClass.some_property.fget. There's lots of paths to functions, and the function alone doesn't necessary know how to get to it. And functions are relatively easy; other objects can be much harder... items = range(5) The contents of items cannot be edited in place, because they are recreated dynamically. They can only be modified by later
Re: [Edu-sig] PySqueak: Self as the source of many ideas in Squeak
Ian- Thanks again for this pointer. I've added two more proof of concept files to PataPata. The second one demonstrates inheritance with a parent and two children, as well as graphically displaying the morphs. See: http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_002.py?view=markup I started trying to do it in OpenGL (which I have had working before) and got some errors so punted and chose wx and 2D for that. I don't like making initial proof of concepts that rely on too many dependencies. OpenGL remains a real possibility down the road, but this one problem just shows how installation issues can bite you (in this case, I had commented out the driver for it in my xorg.conf file when I was having other problems related to one of my two ATI cards having problems driving its secondary display head, and didn't care to restart X in the middle of my development to try fixing that.) The third P.O.C. demonstrates the problem your solution addresses. http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_003.py?view=markup I found two other variants of solutions on the web (differences include are who does the wrapping etc.), and I need to decide how best to proceed on that. Links to these three options including yours: http://svn.colorstudy.com/home/ianb/ruby_blocks.py http://zephyrfalcon.org/weblog/arch_d7_2002_11_16.html http://lists.canonical.org/pipermail/kragen-hacks/2000-September/000264.html [The latter two are more specific to Prototype inheritance in Python.] Going to be traveling much of next week, so probably not much more activity on this for a while. Frustrating to me as I think this is just picking up some speed. A little OpenGL, a few Self-like GUI widgets for inspecting values like in the movie of just rectangles and lines and text, using a wrapper approach for inserting methods into prototypes, adding a remote debugging process perhaps derived from Idle, making some program writing code derived from pickle perhaps, dropping in some bitmap and icon content from our garden simulator, and the result might be a nice proof of concept constructivist educationally-oriented system in a week's work or so. Obviously not everything, and with very rough edges, but something that could show the basic ideas. Sigh. With distractions, and part-time, be nice to get all that together by the end of June, if that, realistically. No promises though. Thanks again for your feedback. --Paul Fernhout Ian Bicking wrote: For direct assignment, you might find the magic_set decorator I wrote useful: http://svn.colorstudy.com/home/ianb/ruby_blocks.py (toward the bottom) It lets you do: @magic_set(foo) def spam(self): print 'hi' which handles the closure to add instance methods directly to instances (which doesn't work if done just through assignment), among other assignments. It uses the name of the first argument (self, cls, or anything else) to determine what kind of function you are trying to create. ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] PySqueak: Self as the source of many ideas in Squeak
In continuing to contemplate what are the essential ideas of Squeak in terms of using them in an educational environment resting on Python, I decide to revisit some of Squeaks' roots. Many of these are in Self, a prototype based programming language (and IMHO a constructivist one too). The main page for Self: http://research.sun.com/self/language.html I had read of Self, and met one of the key people once at a conference, and I was inspired by many ideas from those interactions, as well as work with NewtonScript (the native programming language of the Newton, also inspired by Self), but I had never seen the Self system in action. It turns out there is a 15 minute or so video on Self, linked to from here: http://www.merlintec.com:8080/Self Kirby, you mentioned the persuasive power of videos in another context, and I suggest viewing the high definition version of the videos there would be useful in seeing how a graphical environment for students could approach the immediate feedback of the command line, especially with most of today's students who are presumably already point and click mouse literate. The key principles mentioned in movie for Self's design are based on ideas from the physical world, and are summarized as: * Directness (everything is potentially visible and touchable) * Uniformity (you can consistently change everything) * Modelessness (always running, so no editing/running distinction) Self also demonstrates multiple people doing activities together in one (2D) environment. [BTW Neometron's Learningworks was about 3D communities using Smalltalk and was deployed a decade ago, which shows some other roots of Squeak/Croquet roots here.] From the paper here (first seen in a link below): http://research.sun.com/self/papers/programming-as-experience.html Finally, in designing Self, we have learned one lesson by making mistakes: examples can persuade the designer to include additional features which later turn out to produce incomprehensible behavior in unforeseen circumstances. This might be called the language designer's trap. Minimalism, simplicity and consistency are better guides. They benefit every programmer, not just the ones who need advanced features. We suspect that many of today's object-oriented languages could profit by dropping features. In my own work in Smalltalk development, knowing that Self existed, and having experience with prototypes in Newtonscript, I was often frustrated by Smalltalk not having Self's elegance. And I think many of the issues Self addresses (particularly eliminating a class side / instance side distinction) are very important to making programming easy to get into, as well as keeping it more fun. In the movie near the end they make the distinction between telling objects what to do (writing code) and just banging them around into position (which Self's GUI helps support, in addition to programming). By building in Morphic (the Self GUI paradigm) Squeak tries to get this Self leverage, but I think, given Squeak's use of Smalltalk (which has classes), Morphic always seemed to me to be rather inelegantly bolted on (this is not a slam at the developers, just an inherent problem of a class based programming system trying to work with dynamic constructivist material). One of the things I have always liked about Python is its use of dictionaries for storing values in instance objects. This is computationally inefficient compared to looking up things by position in an array as C or Smalltalk do, but it is more flexible in terms of taking any specific instance and adding more data fields to it, so it is efficient in a human-oriented way and can lend itself somewhat to this sort of prototype based work. So, another idea when thinking about PySqueak is: how can Python better support prototype based development? As well as: how can what we have with Python2.4/Jython2.1 now be used to do that in interesting ways? Now this certainly isn't a new idea, see for example these discussions: http://lists.canonical.org/pipermail/kragen-hacks/2000-September/000264.html http://www.thescripts.com/forum/thread30832.html http://www.prothon.org/ http://www.google.com/search?hl=enq=Prothon or Prothon's apparent successor, PyCS: http://www.prothon.org/pipermail/prothon-user/2004-August/003269.html http://pycs.org [However, the Prothon and Pycs links seem to be down right now, I read them through the Google cache just now as this project is new to me, perhaps an indication the project is ended?] These three key principles above, relating to a dynamic nature of the Self system, are probably needed to support any constructivist approach to software creation and use. But notice how they are the opposite of the principles behind something like C++ or other statically typed languages, which focus on data hiding, specialized interfaces, and set-in-stone compiled applications. Or as Alan Kay put it: http://www.smalltalk.org/articles/article_20040731a.html I
Re: [Edu-sig] PySqueak: Self as the source of many ideas in Squeak
Paul D. Fernhout wrote: Or, as Ian Bicking points out here in Initial thoughts on Prothon: http://www.artima.com/forums/flat.jsp?forum=122thread=41588 [with quoted text from Ian which had python metaclasses\n pasted in it by me by mistake.] Ian- Sorry to mangle your eloquent writing by accidentally pasting python metaclasses in the middle of it (up till 4am writing inspired by seeing the Self video, sorry). --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] PySqueak issues: image storage
In trying to further think through what would be involved in supporting Squeak-like (or just Smalltalk-like) capabilities for Python in constructivist education, on reflection, I think the single biggest issue is that of the Squeak/Smalltalk image. There are lots of other issues, but I am now thinking those are more easily solvable by just programming, often using existing Python libraries, than this one, which is more reflective of deeper issues. For those of you unfamiliar with the notion of a Smalltalk image, it is essentially this: you can pick save image from your running Squeak environment and the whole running vm's object memory is saved to one file. Then when you start up Squeak and specify your image file, everything is back the way you had it when you saved (in theory) -- windows, open files, open socket connections, everything. In practice, open socket connections and open files sometimes can't be reopened (the port may be in use for a server socket, or a server may be down for a client socket), files may have been deleted or locked and so can't be reopened, a database may have changed, and so on. (And making this work under the covers can be non-trivial.) But, as least, the system tries to put everything back the way it was, and it almost always does a perfect job for plain GUIs. What's more, you can bring this file to any machine on any OS and processor that runs a fairly similar version of Squeak (like moving Mac/PPC to GNU/Linux/AMD64), and just start it up and you are back where you saved. And here is the key point: you get all this for free when you work with Squeak. You generally don't have to use a pickle library yourself, or write object saving and loading code for your windows, or do anything like that. It just works. Why is the image so important for the novice user in a constructivist educational setting? If a learner is learning by building, then it stands to reason that tomorrow they would like to learn by building on top of what they have already built more often then they would want to start from scratch. Starting from scratch can be a good learning experience, no doubt, but it gets old if you do it over and over again. So, when a learner can save their image and reload it tomorrow, they are exactly where they left off. So, if they are in the midst of building a simulation by dragging graphical widgets around, then they just save it, and tomorrow there it is. And here is they key: they never had to write any saving or loading code to do this. And neither did the author of the underlying package they are using. This is a big thing IMHO. It lets the learner focus more on what they are doing without the distraction of how can I save and load this. Now, in practice, Squeak does save and load things outside the image. It uses files to store code, communicates over sockets, uses databases, and so on. In some ways, using an external file to save, say, your email seems much safer than storing it just in an image (which is a binary file and could easily get corrupted). To do that, an application has to use some explicit form of representing objects as text and reading them back in itself. If you want to share a small part of your image, like just the simulation you wrote, then it makes sense to be able to export that part (preferably as text) and share it (most smalltalk have some support for this equivalent to pickle or xml object writing). So the image isn't everything. But for the basics of where windows are, what widgets are in them, and what dynamic objects exist in the environment, it does a great job. So, where is the Python PySqueak problem? The graphics widget set is the biggest issue (sockets, files, databases, etc. are hard, but simpler). Smalltalk are designed from the ground up to do this. In Squeak's case, all the widgets are native, so their state is defined purely by Smalltalk objects. In other Smalltalk which use native widgets, the issues are thought through at the beginning on how the windows will be created and then recreated on reloading an image and that part is usually hidden from the user. And how to figure out what native GUI widgets are up on the screen and how to save that and reload it, all transparently to the user, is a non-trivial thing, and it varies from widget set to widget set. Since Python wants to be platform agnostic, and since there are a lot of widget sets out there (x, wx, tk, swt, swing, gtk, qt, mac flavors, mozilla and other web browser widgets, etc.), plus a lot of code written for them, that means a bit of a problem. I think in theory one could write widget set savers and reloaders that know enough about a specific widget set to walk the tree of displayed widgets and rebuild it. But, that is a lot of work that needs to be done for each widget set. And then, ideally, that all needs to work with existing widget using code not written to use a well designed library that hides
[Edu-sig] Slashdot article: Do Kids Still Program?
From: http://ask.slashdot.org/article.pl?sid=06/04/28/2236239threshold=2 From his journal, hogghogg asks: I keep finding myself in conversations with tertiary educators in the hard sciences (Physics, Astronomy, Chemistry, etc.) who note that even the geeks—those who voluntarily choose to major in hard sciences—enter university never having programmed a computer. When I was in grade six, the Commodore PET came out, and I jumped at the opportunity to learn how to program it. Now, evidently, most high school computer classes are about Word (tm) and Excel (tm). Is this a bad thing? Should we care? Do you think the desire to program computers has declined in the younger generations? If so, what reasons might you cite as the cause? Lots of discusssion related to the themes of edusig and CP4E. --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] PC terminology to end processes? (was Re: Tips ...)
kirby urner wrote: Learning to kill a process is pretty basic. I'll have kids start 'em just to kill 'em. They enjoy the sense of power this gives them. I see the value in encouraging kids to have a sense of their own power, but I have a script on my system (just for myself) which lets me type stop instead of kill. Even in a virtual world of computing, is teaching kids to kill a good message? Language does effect thought to an extent. http://en.wikipedia.org/wiki/Sapir-Whorf_Hypothesis I feel a bit the same way about some user manuals that go on about depressing or hitting buttons. Press is a better choice I think. Also, someday those processes might represent sentient AIs and attempting to kill them might have serious consequences. Perhaps good to to get kids thinking about the potential rights of any sentience, even now. :-) --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Bootable Python CDs?
I previously wrote: Then you would have a custom Python which would be useful for wandering faculty (assuming the admins let you reboot the machine, and it was configured to allowing booting from removable media). I just noticed this: http://wiki.python.org/moin/PythonCd Welcome to your Python CD! This is a bootable CD based on [Debian GNU/Linux and KNOPPIX. The special thing about it is that it has lots of Python stuff! Anyone used it? I'm curious: is it even practical to expect to walk into most modern educational computer lab in a typical school and expect to be able to reboot all the computers to run from your own Python CD? Do people's school computer labs typically allow a boot from removable media? I know it was quite possible to boot your own stuff when I ran an educational computer lab (or rather, impossible to stop. with those motherboards) but that was a long time ago (back in the days of 5-1/4 and Token Ring). I don't know what typical admin policies would be now. But todays' motherboards seem much more likely to have an option for picking the boot medium on reboot (but also more options to disable media booting which you would need to get into the BIOS settings to change). --Paul Fernhout ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Shuttleworth Summit
Guido- You are prudent to avoid politics in your public comments as the leader and BDFL for the free Python community (a double edge of celebrity, and you handle it well). And we would expect no less of you. :-) But the reality is politics is about resource allocation, including that done by a community of free and open source developers, so it plays into any design discussion (even if only done implicitly). Humans live and breath politics, even when they make a decision just to go code in a corner (which is not always a bad decision, of course. :-). Or, to paraphrase Carl von Clausewitz: http://en.wikipedia.org/wiki/Carl_von_Clausewitz Software is is merely a continuation of politics [by other means]. :-) [Though see the article for the rest of that story.] And perhaps Kirby and I are not so far apart in some ways. :-) Certainly almost anyone on this list is looking for something better than what we have now for math and science education, with the hopes Python can be a part of it. I am very impressed with what Kirby is able to do with using existing Python tools for education. I can just wonder how much more he could do in a more post _Voyage from Yesteryear_ context, where compulsory schools have withered away as we know them now. :-) http://www.jamesphogan.com/books/voyage/baen99/titlepage.shtml See also Hogan's _Mission to Minerva_ for more on an alternative vision of schooling (presented in passing): http://www.jamesphogan.com/books/m2minerva/baen04/titlepage.shtml If you are looking for a middle way for Python, then by all means, make something attractive for both unschooling and schooling. Or, as an approach, write something for constructivist open-ended unschooling (like we did with our Garden Simulator) and then get someone like Kirby write a curriculum guide for it for when teachers choose to use it in school. :-) Seriously though, I'd rather Kirby wrote such a guide than someone less inspired, and as long as school exists, you need someone like Kirby to interface with them and their ways of doing things. And if you follow some of Alan Kay's ideas, that is probably where you will end up. Consider what Alan Kay says here: http://www.squeakland.org/school/HTML/essays/dynabook_revisited.htm BC : So is the Dynabook just another potential learning tool? AK : It's just like a musical instrument. You don't need it. The most important thing about any musical instrument is that you don't need the damn thing in the first place. Because people all have got an instrument inside them. If you have a great musician and a bunch of children, you've got music, because that person can teach them how to sing. On the other hand, you can have the best instruments in the world, but if the music teacher is no good, nothing's going to happen. You can look for the music inside the piano, but that's not where it is. Same thing with the Dynabook. You don't need technology to learn science and math. You just absolutely don't need it. What you need to have are the right conditions. In music, if you've got the right conditions and you've got music happening, then the instruments amplify what you've got like mad. The best thing a teacher can do is to set up the best conditions for each kid to learn. Once you have that, then the computer can help immeasurably. Conversely, just putting computers in the schools without creating a rich learning environment is useless -- worse than useless, because it's a red herring. There's a sense something good is happening, when nothing real is happening at all. Marshall McLuhan made the point that one of the crucial things about printed books was that you didn't have to read them in a social setting, such as a classroom. People can pursue knowledge independently and from the most unorthodox, subversive, or just plain weird points of view. But that is rarely how things are taught in school. Most educators want kids to learn things in the form of belief rather than being able to construct a kind of skeptical scaffolding, which is what science is all about. The ability to explore and test multiple points of view is one of the great strengths of our culture, but you'd never know it by looking at a classroom. Science today is taught in America as a secular religion. But science is not the same as knowing the things learned by science. Science itself is a stance in relationship to knowledge. In order to do science, you have to give up the notion of truth. Because we don't know the world directly; we know the world through our mind's representational systems, which are like maps. Science is a map that is always incomplete, and so it can always be criticized and improved. And that's why it's so effective at, say, treating diabetes, or whatever. Because the map is incomplete, it can always be improved, and so it is the best way to deal with what is. One of the problems with the way computers are used in education is that they
Re: [Edu-sig] Moving forward an educational Python environment
Guido- It's really exciting to see the idea moving forward of Squeak concepts running on a stable Python base that all was under conventional free and open source licenses, and that Squeak-like technology could finally be in the free part of a Debian-based distribution. I'm certainly willing to throw my hat in the ring (not to discourage anybody else, though :-); however, see the end for some limitations. I'm posting this to the edusig list because people might be interested in commenting on these ideas or working them into their own proposals. I'm happy to privately send a resume (since we are talking funding here), but for now instead here are my initial thoughts on how I would approach this. Obviously, these notions could be refined by talking to other people (especially Squeakers) at the start. And tactics would also depend on who else wanted to help. Essentially they cover choice of language and technologies, and then a sketch of a development plan. The major parts of the development plan as I see it initially would include roughly in order: * adding more support for changing Python applications while they are running, * getting a Smalltalk-like language on top of Python that uses Python libraries, (optional, but Squeaker-friendly) * integrating in a HyperCard/PythonCard derivative, * stress testing the system by getting one or more major constructivist educational applications under it (like our Garden Simulator), * adding eToys and Logo support, * and finally moving into work on supporting 2D/3D Croquet-like capabilities (the last item being what would take a very long time, having future subplans, and so on). How polished any of those things end up being would be a function of how much other people get involved; I would see my initial goal to get the systems working together under Ubuntu and then hope others will see value in them and help keep them going as I take on a more coordinating role as time goes by (though I'd rather be coding when I can, especially in such a neat system.) === objective === The overall objective would be to capture the excitement Alan Kay conveys about Squeak Smalltalk, eToys, Croquet and so on, but do that on a stable and freely licensed Python base. The specific goal would be using Python to deliver constructivist educational activities, both helping people create 3D simulations and helping people use a variety of programming styles (code, icons, HyperCard, etc.). Integrated communications from multiple users is important in the full system, though perhaps not at first? The system should both be novice friendly and of interest to experts. As per my previous comments, overall I'd personally focus more on supporting constructivist self-education without a teacher's direct involvement or the need for a specific curriculum (beyond simple tutorials, etc.). However, I'd concede such a system in use within the classroom would be better than what schools have now, and it would be nice to have someone write school curriculum units related to it (though I personally would not want to make a lot of design concessions for school as opposed to home use, though I don't expect they are needed much anyway). === choice of Python === On Python vs. Jython: I'm quite happy to work mainly in Python and not Jython, despite my earlier (and see below) plugs for Jython. :-) One can make strong arguments for basing the project in CPython too. :-) I'd still argue though that if you want a browser plugin then using Jython somehow is the best way to go, and I would not want to put any effort myself on plugin support if the project was done in CPython (though would be still happy to coordinate that if someone pursued that). My thinking is that if plugin applets really mattered, we'd see more of them already with Jython. Once a good system is working, Jython could still be a web deployment vehicle for some parts of the system (like eToys or stand-alone simulations, though probably requiring a compatibility layer). I don't see IronPython as a good candidate because of the patent uncertainty etc. related to dotnet/Mono issues, especially if GNU/Linux is a first platform. === tool philosophy === Keeping with the Python philosophy, I would see this as a suite of tools which each might be supported by different technologies (including different GUI libraries). To keep this manageable, I would focus first on something that runs on top of Debian GNU/Linux. Ubuntu is such a platform, and would be the obvious development platform and test place for packages, though I currently run plain Debian, so I would have to switch eventually. However, I would keep in mind Mac and Windows support in a choice of cross-platform approaches (likely one or more of wxWidgets, SDL, and OpenGL, though I found the Mozilla idea intriguing too) and perhaps developing a compatibility layer for some parts of the system. But making cross-platform support a priority would only come in as others committed to be at active
Re: [Edu-sig] Shuttleworth Summit
kirby urner wrote: I've read some Gatto and know about unschooling. But how does that tie in to your advocacy for Jython, for example? No direct link. I just think Jython is great technology considering Java's (technically) undeserved success in the market. :-) Also, if you want browser plugin support for Python, Jython already has it running as a Java applet, and that will cover more versions of more browsers than anything we can realistically hope to support with another flavor of Python. If plugin support is not important, then CPython seems a better choice to me for an educational Python with the least licensing and deployment and dependency issues and with the greatest current support. And what does this sentence even mean: Mark sets out to do good; my worry is how many Bucky Fullers the curriculum he plans is about to grind to ruin. In the context of the previous statement there, and if you consider Gatto's points about just about every inner-city kid he taught being a potential great success at contributing something to society, as well as the actual success of a place like the Albany Free School with kids who have problems at other conventional schools: http://www.albanyfreeschool.com/overview.shtml it means that schooling centered around the current needs of the curriculum instead of the current needs of the student actively harms the potential of most kids. And, as Gatto suggests, modern schools were designed to do just that -- to be levelers, not amplifiers. In order to level someone, you need to grind them down one way or another to fit some standard. :-( Today Bucky Fuller might have been placed in a special ed class and then likely put on Ritalin for obsessing about those dried peas and not paying enough attention to the teacher in class. Drugged up and labeled a failure from kindergarten, he might never have developed enough self-esteem to think great thoughts (or make them known to the world). Granted, schools do try to raise others up to the standard (but usually fail miserably at that anyway, which is OK, because it failures paradoxically justifies the need for schooling, because the kid is usually blamed). As Gatto points out, the ironic thing when we say schools are failing, is that the reality is that schools are actually succeeding at what they were designed to do. They were designed mainly by industrialists http://www.johntaylorgatto.com/historytour/history1.htm to make most people into compliant factory workers and consumers. Ideal consumers and factory workers from an industrialist point of view are not skeptical people -- thus the focus on science as a collection of facts, not a way of skeptical thought. The problem is just that the purpose to which they were designed in a very public way two to three generations ago (with ultimately the buy-in of most people at the time) is no longer the purpose which we now desperately need them to fulfill (which is now to create citizens for a dynamic and technology oriented 21st century) We are facing a variety of specific issues resulting in part from the very success of consumerism and industrialism, and it is often that the success of one generation turns out to be the problem of the next as conditions change in part from that success. For example, the US had a lot of productive factories for two generations, so now the problem is more what to do with all the stuff we have (including how to power it and recycle it sustainably). I can't understand your logic yet. The commitment is to bottom-up curriculum development, not one guy (not me, not anyone) imposing some top-down compulsory must learn thing, except insofar as we tie to the pre-existing national curriculum for South Africa. Hundreds of years ago, most kids learned what they needed to know from family and community, though some wealthy people had one-on-one tutors for their kids. The notion of sticking a bunch of kids the same age together in a room and expecting them to all learn the same thing at the same time is only in the last century or so, and it is clearly not how children learn best, since kids are ready to grasp ideas at very unpredictable times. It is a waste of a child's and a teacher's time to try before they are ready -- whether reading, writing, arithmetic, or other things, but that waste is exactly what an age based curriculum demands. So no curriculum, even a bottom-up one that expects kids to learn something in a specific year (let alone in a specific month or day) is going to be good for kids overall. Enough such interactions grinds down kids into tiny fractions of what they could of been (and it is not too good for the teachers psyche either); it makes many kids actively hate education, or at least hate and fear specific subjects (often math, but also often reading). Boredom by itself isn't torture and is an important part of life, but forcing kids to be in boring situations they
Re: [Edu-sig] Shuttleworth Summit
Guido- A fair enough request. Summary: Schooling is not the same as education. Any country seeking to develop is not going to improve itself in the 21st century by adopting an outdated child management method called schooling -- which even in the USA has been discarded by the parents of about one to two million homeschooled and unschooled kids (and growing). Efforts to change schooling with open ended technology have a history of failure (e.g. Lego/Logo) as the school system micromanages them to neutralize their potential. Propping up such schooling systems may be ultimately counterproductive and simply prolong the suffering, as opposed to investing funds into newer ideas, like free schools or home-based unschooling. Ideally, instead of a school, put a free-admission science and technology museum and library as an educational resource center in every community which kids can visit whenever they want (100 successful demonstration centers might change public opinion). Focus investments where the solutions are coming from, not where the problems are caused. A future educational Python should focus more on being a good match for those new educational paradigms than trying to prop up the old failing one. So, design an educational Python evolved from Squeak ideals that is good for use in TuxLabs, Fablabs, science centers, libraries, and homes. If it is also helpful to kids at school, that would be a nice bonus. --Paul Fernhout A mantra for those who would help others who are disadvantaged with less likelihood of alienating them (especially in other countries): I help you not out of charity, but out of a realization that my own liberation is bound up with yours. I hope someday you pass on this gift to others when you are able to. Guido van Rossum wrote: Paul, Is there any way you could say this in less than 20 lines? As it stands it's way too long for me to read. I'd like to present Shuttleworth's POV in capsule. South Africa's educational system is bankrupt (not literally but practically). With limited means compared to the SA department of education (see the financials downloadable from tsf.org.za) Shuttleworth is trying to provide something useful for SA's poorest kids to prevent a whole generation from being lost. I severely doubt that whatever might fix the US educational system will work in SA. --Guido ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
