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=en&q=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 invented the term Object-Oriented, and I can tell you I did not have C++ in mind." This statically compiled approach culminates brilliantly in something like OCaml, http://en.wikipedia.org/wiki/Ocaml since if you want types with the least pain and syntactic clutter, OCaml can infer many of them for you. C++ or OCaml are pretty much about specifying everything in advance and locking down the system, assuming it will never change at runtime, to get the most out of memory and computer cycles focused on a narrowly defined fixed problem. This is not to say C++ or OCaml can't be used to make open systems (say, by defining a Smalltalk or Common Lisp or Python virtual machine in some way), but openness at runtime is clearly not what those languages are about. Now there are places for that sort of efficient and effective closedness, but it is a very different philosophy from creating open systems like Self, or Squeak. Python clearly potentially can be used in a Self-like or Squeak-like open way, and some core development tools rely on that, but in practice most of the time Python seems not to be used that way. Perhaps this is due to, as a speculation, that most people come to Python from a C/C++ background, which is why they liked the "f(a, b, c)"-style syntax as opposed to keywords (Smalltalk) or lots of parens (Lisp). Clearly, if most Python development had a long legacy of being oriented around that sort of open and dynamic constructivist principle, with the size of the Python community and its technical skill, we would probably already have a dynamic environment better than Squeak for all the things Squeak does. :-) So, as I reflect on this, the roots of not having Squeak on Python *already* may have more to do with Python community culture and history and mindset than Python limitations. One can of course hope that a successful PySqueak project in that direction will prove to be a "better mouse trap" and the Python community will flock to it, although that may not be realistic, speculating about the Prothon and PyCS sites being down. And as it pointed out here by Sjoerd Visscher: http://lambda-the-ultimate.org/classic/message11653.html "Flexibility is nice, but useless when the libraries are implemented in one programming style. That programming style will be the only natural style of the language." I want to underscore and emphasize this difference between these two philosophies of programming language design, because it seems that the directions proposed for mainstream Python, if anything: http://www.artima.com/weblogs/viewpost.jsp?thread=86641 have been in directly the opposite direction to Self, to a Python with static typing (including RPython). So, frankly, there very well simply be an insurmountable cultural barrier here. And there is nothing wrong with that -- static types are a valid way to generate code that efficiently uses memory and computation to solve a specific well defined purpose (like a well specified Python VM or any other well specified problem). However such a focus will remain at odds as far as I can see with the notion of a living and evolving population of objects system, which is at the core of a constructivist vision of education or programming. Hopefully a diverse Python community could productively use both paradigms in language variants, so an RPython for certain specific tasks, and a proto-Python for everything else (or at least, some forms of educational use)? Unfortunately, the more one sees a path diverging from Python as it is commonly defined (towards, say, a Prothon? direction) the quicker interest in a PySqueak will evaporate, if it has not already. :-) Because then it is just some quirky side variant. Still, there are niches in the Python community, like with Jython, where a slight change in direction may be more feasible, at the very least as a proving ground of sorts (Jython sometimes has its own identity crisis of whether to track CPython or strike out on its own, usually resolved in favor of tracking.). So, again, in thinking what Squeak on Python might mean, as opposed to aping Squeak, Python could build on its strength of using dictionaries internally and support a more prototype based environment like what Prothon or PyCS tried to move towards, making it more similar to Self than the derivative (in that sense) Squeak (which still uses classes). Coupled with a self-like GUI, I think that would better support constructivist educational needs. Of course, then one can ask, is this just reinventing the Self wheel and is that worth doing (to potentially gain Python community advantages, which might be questionable if the approach deviated in any significant way from mainstream Python)? It would seem clearer that the most leverage would be gained if Python (or Jython) as it is now (or with at best trivial changes) could be used to support Self-like features, and thus realize some of the constructivist ideals also embodied and further popularized in Squeak. Or, as Ian Bicking points out here in "Initial thoughts on Prothon": http://www.artima.com/forums/flat.jsp?forum=122&thread=41588 "[After mentioing Prothon syntax changes from Python...] I actually wonder to what degree prototypes could be implemented in Python with metaclasses. While some of the syntax would currently be crufy with Python (e.g., you'd have to create a function, then assign the function to an object), that's kind of a separate issue. The bpython metaclasses asic object model in Python feels like it should be replaceable, especially since we already have both new and old style classes. I think it's still a bit hard to think about these with the syntax getting in the way or otherwise being distracting, but feel like the potential is in there somewhere. If it could be hacked onto Python instead of developed entirely separately from Python, it could make Prothon much more interesting from the perspective of practical programming. Ultimately it would probably have to be like Stackless -- a patch against Python implementing some necessary changes to syntax. But that's a more viable development effort, and one that's more likely to percolate ideas into the main Python interpreter." 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?) Ian, any recent thoughts on that? I would speculate that part of the general interest of the world in HyperCard was that it to some extent worked in a direct-manipulation protype-based way. Perhaps that similarity resonates with you as well? --Paul Fernhout _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
