Kirby- Clearly we're both likely on the same planet, but just as clearly our priorities are different (e.g. I may want to permanently move off of it more than you :-). http://www.kurtz-fernhout.com/oscomak/SSI_Fernhout2001_web.html http://www.kurtz-fernhout.com/oscomak/AchievingAStarTrekSociety.html
And there is nothing wrong with that; there is a lot of value in diversity in a community. One of the marvels of free and open source software communities is that people work on stuff they like to work on, and others get to do the same. When those interests overlap, then great. When they don't, then also great, as the community is still trying a lot of different things, and the evolutionary results are visible to the community, and can be built upon as desired. It is frustrating to see all the duplicated and aborted efforts, but it is also exciting to see an unexpected effort (like Python once was) catch fire to its fuse and shoot up to the stars. Sometimes that work is coding; sometimes it is designing; sometimes it is just talking about priorities and values and history. Personally, I think the world has too much code already, and my mission is, in part, to get rid of much of it. :-) I read once you can measure the power of a new idea by how many bookshelves worth of books in the library it obsoletes; I imagine the same applies for code. Again, from: http://www.sysprog.net/quotprog.html "Fifty years into the First Computing Era some of us in the computing arena have come to realize we've made a false start, and for us to finally be able to produce lasting, correct, beautiful, usable, scalable, enjoyable software that stands the tests of time and moral human endeavor, we need to start over. (Richard P Gabriel)" Still, if I can leverage Python and the Python community to that end, then so much the better. Probably that will fail, but possibly worth the try I feel. Anyway, I feel there is room enough for your vision of a "PySqueak" and also for my vision of "PySqueak". And may the better version win, or split, or gain adherents, or whatever -- assuming "better" even makes sense to use when people have so many differing priorities and what is good for one purpose may be not so good for another. :-) To recap, as I see it, this PySqueak effort gained some traction when you and Guido cam back from the summit, having seen Alan Kay's presentation of Squeak and Croquet. I'm sure it was dazzling, as Alan Kay is a captivating speaker and Squeak and Croquet have a lot of really great features.(*) So, with the two of you, who provide a lot of the leadership on edusig, suitably impressed with the potential for dynamic interactive environments based on a prototype paradigm for use in education (as well as general programming), some discussion starts here. And I butt in, and say, hey, that's what I was talking about six years ago. :-) And so some further discussion ensues (complete with educational paradigm distractions :-). Now by all means, I think a popular and well supported open source Croquet-like 3D environment on Python would be a good thing. I believe that for the same reasons I think it was neat in LearningWorks, the original Python Alice (which I played with many years ago): http://www.cs.cmu.edu/~stage3/publications/95/journals/IEEEcomputer/CGandA/paper.html VPython, and other systems as well. And even in ActiveWorlds, which bills themselves as: "Home of the 3D Chat, Virtual Reality Building Platform". http://www.activeworlds.com/ and see "Python for ActiveWorlds"! http://www.crepuscule.com/aw/ But I could also add in many MUDs and MOOs and MMORPGs of various types (textual and graphical of various sorts, including even franchised ones). These things are all really neat. And I can see how the could be motivating to some people to do some interesting learning. I'd love to have a good one to work with in Python to simulate life in a space habitat network, for example. And if Shuttleworth wants to help fund such a thing, I'm not above taking some of his money as a subsidy :-) if it otherwise links in with also advancing some of my own constructivist agenda items (though they clash somewhat with his school-based approach). Clearly, and I think correctly for his plans as he sees them now, his strategy, reflecting your emphasis that Python-as-it-is can do a lot of neat educational things, is a very good one. I might quibble with the school orientation, and while wishing him success expect him to need to revise those plans someday for reasons previously outlined, but it is his money. Certainly I come with my own set of baggage (re unschooling and free schooling) so I can acknowledge there are probably many better or more compatible candidates than I, just on the basis of that, to work closely with a Shuttleworth activity targeted at schools (and, of course, there are much better Python programmers out there than I too). And no bad feelings should someone else get paid to do that work. Good for him/her. Frankly, Mark would probably be better off spending his funds on any new development in South Africa anyway (where his money is based), where he could hire more developers for the cost of less US ones, plus these developers would become greater assets to the SA economy (though he made it clear in the email Guido forwarded that he had little interest in spearheading a major development effort of any sort, anyway). So, I think we can discount the Shuttleworth Foundation as the major player in PySqueak. Not inconsequential, and not unimportant, and of course not uninstrumental (such as by bringing Guido and you and Alan together), but just not dominant (at least, right now). As you say, they are happy with what they have right now, and see the major need just making curriculum guides using existing tools. Good luck to them with that, and I hope it works out well despite my reservations, etc. And I'm sure that may be their (initial) attitude towards a PySqueak. But, even if that foundation fully underwrote the full-time cost of a developer or project manager working on a semi-volunteer pay-scale (which does not even seem to be what they proposed) the effort will only succeed with buy-in from members of the Python community (and possibly members of the Squeak community). So the question then becomes, what makes sense to various people in the community willing to volunteer time to do some coding, contribute ideas, write documentation, draw icons, submit bug reports, testing, provide advice, and so on towards PySqueak? Who are these people? Well, right now, you are still stuck with just me. :-) http://sourceforge.net/projects/patapata [no code there yet] And hopefully someday, some others. And, we all might never agree, but maybe some useful things will hopefully come out of that anyway. :-) Or, more seriously, given that those other 3D Python technologies exist and have not set the world on fire, and Jython exists and has not set the educational applet world on fire, and ActiveWorlds and LearningWorks and so on exist and have not set the world on fire (in such a way you personally are willing to dump Python just to have 3D worlds), and given that Squeak and Croquet exist and you would rather reinvent them in Python than retool in Squeak Smalltalk (a few weeks for you, I'd say, tops, doing a medium sized app, to be feeling comfortable), given all that, I question that another stab at 3D worlds on Python will set the educational world on fire (especially as you can apparently even script ActiveWorlds with Python already, though obviously that is not the same as Croquet). All that is very neat, yes. Fun to do, yes. Worth taking money for to put food on the table and honorably do what you said you'd do, yes. Useful as a vehicle to build other things on top of and a way to learn such a thing by working on it, yes. But, is reinventing Squeak-and-Croquet-as-it-is-in-Python something to knock yourself out for if you think some other more basic issues are more important, then, no. And I fall into the "no" camp in that sense. Porting Squeak and Croquet (or a 3D engine) to Python, when I could just use Squeak and Croquet and OpenGL, seems like not the most fun or productive thing I personally could do with years of my time (others might like it more, and find more value in it for them, of course). But, approaching it as I outlined, trying to take the best of the *ideas* from Squeak and Croquet and Self and constructivism and trying to bring them to a Python platform in a Pythonic and hopefully better way (and with special emphasis on unschooling and informal science education), or in essence, to "burn the disk packs" and try to out-Squeak Squeak, now that begins to sound worth trying (for me). And if approached respectfully, I think Alan Kay's group as well as the Self group could be some part of that. I'm sure by now after about a decade of Squeaking that Alan's group knows (at least intuitively) more about the limitations and disappointments and frustrations of what they were trying to do with Squeak and Croquet than anyone (whether they will list these and admit them, given a need for hype for funding, is a different story). Something I myself wrote on that topic in 2000 to the Squeak list: "Belling the cat of complexity" http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-June/001371.html And, IMHO, for me, it is still worth trying to make a better-than-Squeak constructivist system with Python even if it is harder and more likely to fail than porting Squeak-as-is to Python, because it is IMHO more likely to succeed in the world if it really works out, more than a "me too" Squeak clone in Python, which without a community that likes it and uses it, will just wither. And Squeak already has the community (though Art has some strong words written to this list on the compromises involved to get there, which are starting to reshape my views on this). Getting a community is much harder (for me or any programmer) than writing code. Which actually is an argument for me to, say, jump ship to, say, Self or Squeak as it is, but let's ignore that, based in part on the fact that for me, I see Python skills a having a significant potential current and future commercial value, as Python is up and coming, whereas Smalltalk, sadly, is on the ropes :-( (Ah, but the good old days with Smalltalk were very good indeed :-). Still, part of my writing here is to think in public about whether any aspect of this project makes sense for me (as opposed to, say, just switching to Self). I might still decide it does not make sense for various reasons, not the least of which might be if the edusig community and its culture really don't want something like Self built on Python. [I am at least heartened by a few people's comments here, Ian's especially.] Of the development plan I outlined for a PySqueak approach, the last part, the focus on 3D worlds, was of much less interest to me than the other parts. To me, what makes Smalltalk great is the ability to debug and inspect and reprogram anything you see, and the beauty of Squeak, in part as a reflection of "Self", is in the power of constructivist ideas relating to the GUI, although going beyond that. I don't want to ignore the other neat technological ideas in Squeak ranging from direct pointer object IDs to the underlying network OS ideas, but they come second in my opinion to what makes Squeak attractive. Without the programmable interactivity, you are left with a scriptable ActiveWorlds, which we have now!. And also, for me, especially having read things here on edusig about the value of interactivity on the command line, about the value of learning different ways of doing things, and knowing about how "what you see is what you get" can be superseded by "what you see is really neat and useful", and even some off-list discussions with Art (Guido's comment comparing us prodded me to look him up :-), these all make me realize that while there is value in providing people a concrete 3D interface, I also think there is greater value in giving people a range of tools and representations, perhaps implemented by a different variety of systems. And, the 3D worlds can actually take away from a focus on the basics of programming. To fight that all by pushing "one 3D VM to bind them all" :-) in a "Snow Crash" sort of way http://en.wikipedia.org/wiki/Snow_Crash is just not going to work (at least anytime soon), and is definitely not the Python (glue) way. To paraphrase, the great thing about standard VMs is that there are so many versions of them to chose from. On a practical basis I agree with you that expecting to make progress changing the Python syntax in any significant way is unlikely to go anywhere. But I also think it is feasible to consider minor changes to Python to support better introspection or object building, although, frankly, I think a lot could be done with Python just as it is right now. Specifically, as I and others stated, one can extend the libraries, or write new libraries, or create a prototype base class, or use Python in new and unexpected ways (like writing image files as Python source), or one can push for new networking paradigms and standards (like Python apps having a low-level networked programming interface if started with a debugging thread). So, there is a lot of mileage one can get from those directions without touching syntax, and I think they remain to be explored in depth. But, without discussions on these points (even if sometimes just soliloquies), I don't think some of those ideas would emerge. And they would not have a chance to be archived for future reflection or Google searches, or commented on as stupid or redundant or insightful or whatever. I come to Python from Squeak and other Smalltalks (though I first learned OO with ZetaLisp on a Symbolics). And I find much to be missed from those days in Smalltalk, ranging from not needing superfluous periods between accessors [e.g. "f v append(poly verts[i])" instead of "f.v.append(poly.verts[i])" if Python dropped them] to simply always having a debugger I can code in at hand when an exception pops up anywhere. Python, its Occam-style indentational syntax (I learned Occam first), and above all its community, are so fantastic in so many ways that they make up for much of what is missing on a practical basis. But there still remain missing pieces. And when you see a presentation by someone like Alan Kay, he makes you very aware of them, either consciously or unconsciously. Still, Squeak misses things Python has too (like the "open source" license, and the stability, and the libraries, and the glue-like philosophy). So, I am coming from that perspective of getting those missing Smalltalk basics working first for Python (and ignoring historical syntax "bugs" like the superfluous period from C/Pascal syntax compatibility). Only then, using hopefully better tools for managing complexity, would I think more about crossing ActiveWorlds with OO scripting yet again or reinventing OpenGL to get a Python version of something like Croquet (should either of those really be needed, compared to working with existing Python projects). Frankly, if you just want Python Alice crossed with a MMORPG, then there are much easier ways to do it (and probably others potentially more interested in that, like the people who wrote Python/Alice or VPython or even one of the Python MUDs or MOOs). But if you want systems that make it easy for anyone, especially novices, to get involved with programming in Python (CP4E) then I think taking good ideas from Self and putting them in a Python context could be a big win, and is something I am interested in. Anyway, I think the "we" in your comment "we already have sufficient toyz" doesn't entirely speak for everyone. Clearly, I do not have "Self" in Python yet, which I want. (Or do I, so much is going on in Python?) Anyway, same planet, different outlooks. And that makes for an interesting (if sometimes stressful :-) world. --Paul Fernhout (*) The features in Squeak which are impressive are still mostly derivative in many ways, as I have previously posted on, although many of the derivations also trace back to Alan Kay and his group in the 1970s, so assigning such credit is a complex topic. kirby urner wrote: > As I understand it, PySqueak is not about changing existing Python > syntax. > [snip] > The PySqueak effort (badly named?) is more like the VPython effort. > Its aim is to give us a sophisticated back end graphics engine to dink > around with. > [snip] > This is NOT about Python changing significantly as a language, moving > to some new paradigm or yadda yadda. > > My info is the Shuttleworth Foundation is in no way holding its breath > waiting for these newer tools to come over the horizon, exciting > though these may be. > > In terms of going ahead with implementation, we already have > sufficient toyz. Curriculum writing is proceeding apace on that > basis. _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
