PySqueak: more on the cultural divide among paradigms
In discussing with my wife some of the ideas of my previous post (on "Self" as the source of many ideas in Squeak) a greater clarity has emerged for me on a programming paradigm issue (in large part due to her input related to her own related experiences with some people resisting prototype-style approaches in application design and others embracing them). Our best Physics and Psychology (taken together, as interpreted by me :-) right now suggests the universe is a sea of subatomic particles in relation to each other in complex ways (determining how those relations change in the future). "Objects" (and Platonic "classes" for objects) are fictions our mind uses to try to make sense of all that complexity. So too, the notions of "class" and "objects" are fictions we programmers invent to get a handle on the raw sea bits of computer memory as they change over time from computational rules applied to them. But they are also fictions we try to apply to the real world when we write accounting systems as well. And they often break down, as illustrated in depth in the late William Kent's book _Data and Reality_. http://www.bkent.net/ We often use the term "Abstraction" to point at this problem (or even cover it up), but that doesn't capture the whole notion, since it that word is often used with the intent that there is one abstraction, as opposed to the notion that the abstraction is just one possibility we chose because it was useful at the moment for specific human goals. So, as far as computer language paradigms go (and teaching people about them), there are then two sets of issues. One relates to modeling the "real world" (because computers are often used to do that) and one relates to getting a handle on "telling the computer what to do" (because you can't do the first without the second). These are somewhat related issues (after all, we are in some sense building models of the real world even when they are about programs running on VMs), though they are still distinct issues in my mind. In terms of increasing levels of computing machinery, we have something like: Machine -> Assembly -> Functions -> Classes -> Prototypes -> Relations In terms of world modeling done by a human mind about the world, we have somewhat the reverse, in: Classes -> Objects(Prototypes) -> Relations -> Reality [Kent outlines an idea for a relation programming system called ROSE or STAR, and I have worked towards something similar in my Pointrel ideas, but the common metaphor is an "entity-relational" model of data). http://en.wikipedia.org/wiki/Entity-relationship_model There of course may be other levels, or even a branching tree, and one might organize these differently, if say, you build a Smalltalk on top of Self, so this is all a big simplification to get one started thinking about this issue. Simplifying greatly even further, it has been the history of computing to move away from the machine to what is often called "higher levels" of abstraction. While it has been the history of (western) Physics to drill ever deeper into the notion of perceptions of reality starting from the perception of Platonic ideals (or classes). Integrating perceptions across these levels is not that easy. Forth does is somewhat for computing though IMHO, a tiny language that can easily be extended to support various paradigms. And here is the cultural divide: when a person is at one level of understanding of all this, it is very hard to convince them of the value or even feasibility of the other levels they may have no experience with. This notion is inspired somewhat by my reading "Future Shock Levels" by Eliezer S. Yudkowsky: http://yudkowsky.net/sing/shocklevels.html "The use of this measure is that it's hard to introduce anyone to an idea more than one Shock Level above - and Shock Levels measure what you accept calmly, not what you know about.") But clearly thinking about levels of understanding is a common teacher-type curriculum design thing to do. And, these other levels may (at least initially) impose discouragingly large cognitive and computational burdens to try out. So, it is just very hard to get someone used to thinking hierarchically about classes of birds that such distinctions are somewhat arbitrary if you truly understand taxonomic issues. Or further, that the very notion of a specific individual bird is a convenient fiction the mind invented for surviving in and making sense of the universe (instead of modeling the bird and its environment at a horrendously detailed quantum level, plus modeling the minds goals in such a way if such was possible). Or, looking at this issue from programming point of view, one can implement Classes in C, but they seem slower for the standard problems C is used to solve. Or one can implement Morphic and prototypes in Smalltalk, but they feel like a kludgey add on. Or one can implement relations with prototypes, but they will certainl at first seem inelegant and slow. [As an aside, I have a prototype of a Smalltalk-like VMs in C and Python that uses a entity-relational model of triads of data for their cores; inefficient yes, but elegant IMHO, and it turns out easy to reach into remotely, or have one simple unified browser to study system state, or be able to imagine the system running backwards for debugging.] There may also even be a personality effects related to feelings about authoritarianism and control, or where one falls on the "meshwork vs. hierarchy" preference landscape. http://www.t0.or.at/delanda/meshwork.htm For a (personal example), having some Dutch roots myself, yet being an outsider to Holland, I can see in that culture a paradox of both pride and success in being a permissive society, while at the same time pride and success in being a society influenced by some fairly strict religious ideals (including compassion) as well as pressures towards conformist behaviors. (This is true of all societies to some extent, but walking around Amsterdam is a very graphic example of this. :-) Or as is said in the intro to "The Portable Henry James" edited by John Auchard (my wife is reading it; I just glanced at it. :-): http://www.amazon.com/gp/product/0142437670/103-1147318-5179869?v=glance&n=283155 "The divide between a culture of individual freedom and a culture of tradition -- H.G. Wells identified communities of will, and communities of faith and obedience -- is a great divide, and it is a persistent and deep one in Henry James, as it should be, even though many Americans in the novels scarcely seem to notice. In the tales and novels it often is the exact place where things tear asunder, a place of broadly political crisis that stubbornly refuses reconciliation -- at least without the virtual annihilation of one side or the other". Beyond how this currently effects Dutch politics relating to immigration and integration issues, I think that factor is at play somewhat in Python's evolution too -- as the Python community is IMHO one that, with Pythons success in gaining broad interest, is currently struggling to reconcile both supporting a desire for prototypes and a desire to move in a strict static typing direction. :-) It's hard to do all these ideas justice in a few word, and I've probably lost many people trying to follow this by now who firmly believe objects really do exist they way they see them, but suffice to say, Python right now sits somewhat straddling the boundary between modeling data as classes and prototypes. Squeak is also at that boundary, less so as a language, but more so as a library and environment when it tries to patch Morphic prototype widgets on top of Smalltalk classes. So, in terms of moving PySqueak forward, the question is, whether to try to push a little like Squeak does, or to push even further, like on to entire prototype systems or even relational systems. Python has better support for prototypes than conventional Smalltalk since Python already uses a dictionary for instance variables as opposed to Smalltalk which uses an array of slots where the slot<->name correspondence is managed by a class. So if Python were to gain something like Morphic widgets, they would probably fit much more nicely into Python than they ever would on Smalltalk. (Ignoring the dominant paradigm determined by library code issue mentioned previously.) Still, Python doesn't try to do a entity-relationship model directly. So, one can ask, is it worth trying to do as Squeak specifically does (Morphic), or try to see the higher ideal of Squeak pushing up another level (Classes -> Prototypes), and try to go it one better (Prototypes -> Relations)? The Self video shows that once you do have a working prototype based system, making a Smalltalk with classes is fairly easy, and what more, actually runs faster than a typical Smalltalk. So too, perhaps a successful entity-relational language might be able to do prototypes easily and more quickly? In the triadal systems I work on (essentially a long list of items which are three pointers: P1 P2 P3) and a few operations on that, http://www.kurtz-fernhout.com/pointrel/ prototypes and classes merge naturally as useful approaches to many problems. But obviously, such a push risks drifting much further from any unifying vision driving interest in something like PySqueak, yet at the same time, it is less "reinventing the wheel", and more "burn the disk packs" to go beyond full steam ahead. At least in my own explorations of computation, trying to make systems that are more entity-relational has been what I have for two decades felt driven towards, informed by a certain conception of Physics and Psychology. But, the new insight from me is to see these two spectrums of (again): Machine -> Assembly -> Functions -> Classes -> Prototypes -> Relations and: Classes -> Objects -> Relations -> Reality and how human personality and cultural and economic pressures help determine individual choices about where to program and think on these spectrums. It's not an easy thing to wrestle with. Yet, as I learned from one smart person who had studied the patent literature, innovative progress comes from a successful attempt to reconcile seemingly opposing needs both at the same time (e.g. cheap and fast), rather than just compromise between them (e.g. cheaper but slower -- compromise being just engineering, or politics, as usual). As far as I am concerned, Squeak was a step backwards from Self in many ways (while forward in others, especially marketing and adoption-wise in an educational setting), as Self elegantly reconciles needs for prototypes and classes in a way that Squeak Smalltalk compromises with. Will PySqueak be a compromise or an innovation (or both)? It remains to be seen. Trying to keep this short, but failing. :-) --Paul Fernhout
On 5/5/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote:
compromises with. Will PySqueak be a compromise or an innovation (or both)? It remains to be seen.
Trying to keep this short, but failing. :-)
--Paul Fernhout
I think we may be on different planets but I'm not sure. :-D As I understand it, PySqueak is not about changing existing Python syntax. Python syntax is controlled by Guido working with pydev people, and is moving towards Python 3000, so-called. The changes are incremental and have nothing much to do with the PySqueak effort. 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. Given this engine, Python developers might write apps friendlier to young children, using animation and almost-no-typing-needed interfaces. We could compete with the newer Logos, which leave the older ones in the dust, visually speaking. The very same engine would have lots of applications in an adult context as well. This is NOT about Python changing significantly as a language, moving to some new paradigm or yadda yadda. In my view, Python is a mature language undergoing consolidation, is not on the brink of some major overhaul. True, it's being reimplemented in C# for some platforms, as it was in Java (with Jim's leadership in both cases). The new graphics engine I envision might well be an outgrowth of that Mono/.NET effort. Only time will tell. In the meantime, we already have working, Ubuntu-compatible versions of Logo, Squeak and Python. 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. Kirby
kirby urner wrote:
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.
I thought there was some idea about an IDE, ala Squeak; or at least I assume this is what Paul was thinking about. Is any IDE or interactive environment planned, or just a graphical environment? If it's just a graphical environment, then why not VPython? Or Soya3D? (Incidentally there's several Summer of Code proposals for Soya3D). Or PyGame, or some library sitting on top of PyGame. Or PythonCard. Or, heck, HTML. To me, the IDE experience of Squeak or a Logo (not including UCB Logo, of course) is far more interesting and unattained by Python than any particular graphic capability. Which is where the IDEish ideas come about, which seems like what was motivating Paul. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
On 5/5/06, Ian Bicking <ianb@colorstudy.com> wrote:
kirby urner wrote:
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.
I thought there was some idea about an IDE, ala Squeak; or at least I assume this is what Paul was thinking about. Is any IDE or interactive environment planned, or just a graphical environment?
I was thinking the low level API to the graphics engine would then allow developers to build their various IDEs, much as GTK does, except the widgets would be more 3D. The source code for these IDEs could be Python, but if multiple language bindings are supported, could just as well be some other language. In my view, a generic graphics engine that doesn't hard-code or hard-specify a particular IDE would give us more freedoms. But there'd have to be an event model and so on, so a lot of thinking about how to support graphical IDEs would be a part of the engine. Kirby
On 5/5/06, kirby urner <kirby.urner@gmail.com> wrote:
On 5/5/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote:
compromises with. Will PySqueak be a compromise or an innovation (or both)? It remains to be seen.
Trying to keep this short, but failing. :-)
--Paul Fernhout
I think we may be on different planets but I'm not sure. :-D
As I understand it, PySqueak is not about changing existing Python syntax. Python syntax is controlled by Guido working with pydev people, and is moving towards Python 3000, so-called. The changes are incremental and have nothing much to do with the PySqueak effort.
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.
Would a VPython implemented on top of PyOpenGL be useful? Right now VPython lives in its own world and doesn't play nice with native windows, or PyGame, or OpenGL, or X3D, or OS X, or... The argument for making writing it the way they have it to get the performance necessary for physics demos. Meanwhile, Python has gotten faster, machines have gotten *much* faster, and PyOpenGL is getting faster by moving to a ctypes-based implementation. Would a pythonic 3D API, a la VPython, that plays well with others be a valuable component for the Squeakification of Python? Or are we talking apples and oranges (pythons and rubies)?
Given this engine, Python developers might write apps friendlier to young children, using animation and almost-no-typing-needed interfaces. We could compete with the newer Logos, which leave the older ones in the dust, visually speaking.
How intricate an engine are you thinking? VPython is still fairly primitive in its primitives, but a more open version might be extensible to read data from X3D, 2nd Life, SketchUp, AvMotion (character animation), etc.
The very same engine would have lots of applications in an adult context as well.
I know I'd love to have a 3D environment that was both easy to use, and extensible.
This is NOT about Python changing significantly as a language, moving to some new paradigm or yadda yadda.
In my view, Python is a mature language undergoing consolidation, is not on the brink of some major overhaul.
True, it's being reimplemented in C# for some platforms, as it was in Java (with Jim's leadership in both cases).
The new graphics engine I envision might well be an outgrowth of that Mono/.NET effort. Only time will tell.
In the meantime, we already have working, Ubuntu-compatible versions of Logo, Squeak and Python.
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.
But Guido has committed that a Squeak-like GUI platform would be welcome. So we are talking about extending the libraries to be more encompassing. I agree about not extending the syntax (any more than is already happening for Python 3000). --Dethe
Kirby
On 5/5/06, Dethe Elza <delza@livingcode.org> wrote:
Would a VPython implemented on top of PyOpenGL be useful? Right now VPython lives in its own world and doesn't play nice with native windows, or PyGame, or OpenGL, or X3D, or OS X, or... The argument for making writing it the way they have it to get the performance necessary for physics demos. Meanwhile, Python has gotten faster, machines have gotten *much* faster, and PyOpenGL is getting faster by moving to a ctypes-based implementation.
I think VPython grooves on having a very minimalist API. The documentation is only a couple of pages, if that. It's really designed to be friendly to like a CS0 new user, and does a pretty good job of that (I've certainly appreciated having it installed at PSU, where I teach pythonic mathematics).
Would a pythonic 3D API, a la VPython, that plays well with others be a valuable component for the Squeakification of Python? Or are we talking apples and oranges (pythons and rubies)?
Looking at Croquet and the latest Logo, I'm seeing 3D as the way we're going, which disqualifies PyGame except as it's a window to OpenGL. My understanding of OpenGL is it could certainly do the job, but we might want to develop a new API for it, more suitable for coding event-driven IDEs. But maybe that's already part of the spec. I know Blender codes all its control widgets inside the OpenGL context. Pretty strange looking, but so is Squeak.
Given this engine, Python developers might write apps friendlier to young children, using animation and almost-no-typing-needed interfaces. We could compete with the newer Logos, which leave the older ones in the dust, visually speaking.
How intricate an engine are you thinking? VPython is still fairly primitive in its primitives, but a more open version might be extensible to read data from X3D, 2nd Life, SketchUp, AvMotion (character animation), etc.
I'm thinking like a serious game engine, like lives behind Quake and Half-Life 2 and like that. Quaternions anyone?
The very same engine would have lots of applications in an adult context as well.
I know I'd love to have a 3D environment that was both easy to use, and extensible.
Me too.
This is NOT about Python changing significantly as a language, moving to some new paradigm or yadda yadda.
In my view, Python is a mature language undergoing consolidation, is not on the brink of some major overhaul.
True, it's being reimplemented in C# for some platforms, as it was in Java (with Jim's leadership in both cases).
The new graphics engine I envision might well be an outgrowth of that Mono/.NET effort. Only time will tell.
In the meantime, we already have working, Ubuntu-compatible versions of Logo, Squeak and Python.
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.
But Guido has committed that a Squeak-like GUI platform would be welcome. So we are talking about extending the libraries to be more encompassing. I agree about not extending the syntax (any more than is already happening for Python 3000).
--Dethe
I was at the meeting with Alan Kay from where he first sent out the call (not to this list). I think many elements of Squeak intrigue him. But exactly what "Squeak-like GUI" means is not yet well defined. For example Squeak isn't particularly 3D (unlike Croquet), yet I think that's where we need to be heading with this engine we're talking about. Kirby
On Friday 05 May 2006 17:54, Dethe Elza wrote:
Would a VPython implemented on top of PyOpenGL be useful? Right now VPython lives in its own world and doesn't play nice with native windows, or PyGame, or OpenGL, or X3D, or OS X, or... The argument for making writing it the way they have it to get the performance necessary for physics demos. Meanwhile, Python has gotten faster, machines have gotten *much* faster, and PyOpenGL is getting faster by moving to a ctypes-based implementation.
Would a pythonic 3D API, a la VPython, that plays well with others be a valuable component for the Squeakification of Python? Or are we talking apples and oranges (pythons and rubies)?
I've been thinking about just this sort of project. My hunch is that a Vpython in Python is now very doable using PyOpenGL. By building on OpenGL, most of the heavy graphics lifting can be done on the graphics card (even cheap ones are ridiculously fast these days). The OpenGL API is now standardized and stable for development, as long as one sticks to basic features for which hardware acceleration can be taken as a given. But OpenGL is not a modeling API, it's purely for drawing things. We need a higher-level standardized scene graph layer (ala VPython). This combination would make the entire graphics stack down to hardware Python based. VPython as it stands is very nice, but it is not extendable in Python. Want a more realistic shading model? No can do. Texture mapping? Out of luck. Stereo-modes? (well OK, but I had to do that in C++ ;-). It might be that something like the PyOpenGL Context code base could be used as a starting point. Along-side the modeling layer we need a good OpenGL-based gui toolkit as well. You really can't build a decent GUI in something like VPython. It would be nice if solid, good-looking applications could be built entirely on Python w/o having to introduce some other C/C++ dependencies. Relying only on OpenGL would give us a truly portable GUI kit (except for a very thin layer that glues it to the underlying windowing system ala GLUT). It could have a consistent, though not necessarily native look and feel anywhere OpenGL runs. I'm willing to give up native look and feel provided the toolkit looks great and has really snappy performance. Another approach would be to make the GUI themeable, so folks could easily implement themes to mimick standard native widget sets. Basing on OpenGL should provide these abilities. The entire X-library has now been impelemented on OpenGL, there's no reason in principle a decent OO gui framework couldn't also be built there (and there are already some candidates out there to use as models). <<snip>>
I know I'd love to have a 3D environment that was both easy to use, and extensible.
Exactly. I agree that Vpython in Python would be a great start. <<snip>>
But Guido has committed that a Squeak-like GUI platform would be welcome. So we are talking about extending the libraries to be more encompassing. I agree about not extending the syntax (any more than is already happening for Python 3000).
To me, it seems that a 2D/3D persistent scene-graph API paired with a GUI toolkit, both based on PyOpenGL is the obvious first step toward this goal. Alone, it would not really be very Squeak-like, but a Squeaky IDE needs the ability to describe a persisitent view (2D or 3D) as a basic starting point. On top of that foundation others can build the ultimate constructivist educational platform...or just some neat, useable 2D and 3D applications. Others could work on extending and improving the whole shebang without having to know any C or C++. The only question in my mind is how do we get started in making this vision a reality? I'd love to dive in and start working on it myself, but realistically, I've already got a lot of committments (writing is *$&% hard work :-). Where do we go from here? Ideas Dethe? By the way, how is the non-Fink port of Vpython for OSX going? We could really use that right now. My Mac students don't want to mess with Fink just to do a few Vpython projects. -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle@wartburg.edu (319) 352-8360
On May 6, 2006, at 11:25 AM, John Zelle wrote:
To me, it seems that a 2D/3D persistent scene-graph API paired with a GUI toolkit, both based on PyOpenGL is the obvious first step toward this goal.
As a former video games programmer, you definitely want to use OpenGL for the hardware acceleration. But I'd like some clarification on what this goal is. It seems like a lot of people are talking about lots of cool technology, but I've not read what we are trying to do with it. And of course we wouldn't want to build a technical solution in search of a problem. Everybody is talking about a new 3D GUI and IDE. What exactly are we trying to achieve by building a new GUI? What is wrong with existing Windows/X/Mac GUIs for an educational project? If we were talking about UI research then developing a new GUI system might be interesting, but for educational purposes, it seems like we have enough to do to achieve educational goals, without trying to redevelop a GUI system. -Winston ______________________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com learning by creating - video game courses for kids in new york
Everybody is talking about a new 3D GUI and IDE. What exactly are we trying to achieve by building a new GUI? What is wrong with existing Windows/X/Mac GUIs for an educational project? If we were talking about UI research then developing a new GUI system might be interesting, but for educational purposes, it seems like we have enough to do to achieve educational goals, without trying to redevelop a GUI system.
-Winston
I think your questions are on the money. If you've seen one of Miguel's demos of the new Novell desktop, you'll know we're already moving to more 3D motifs at the level of OS GUI, complete with the rotating cube between the six desktops, with a Quicktime movie able to wrap around an edge while still playing (flashing back to an OSCON). I think we'd like to be able to call up a writing surface, able to take source code, from within a 3D world, such as by unscrolling a canvas-like object plucked from a metallic tube, textures and everything. And as we've seen in Squeak, when every graphical type object has a strong shared set of base methods, then even buttons can be grabbed and tilted (not just depressed). Per recent Mono or .NET presentations of IronPython: so you want every button on your GUI calculator rotated counter-clockwise by 45 degrees? No problem. That's just the trend in GUIs these days, with GNOME very much a trailblazer (wow, svg screen icons!). So the engines I'm envisioning at some level might just be the next generation OSs of choice, and their accompanying GUI session managers. If sufficiently integrated and interoperable (we have a ways to go), we might call this Squeaky clean. Think Emacs = eToy. But I don't think we can stop there. More specialized apps, on top of the OSs, will provide their own vocabulary of 3D components (objects), be they widget type, animal type, or whatever. You'll be able to script their behaviors and interactions, oft times by typing, as the base source continues to be lexical (versus say hieroglyphic, which more characterizes the desktop icons level). Such applications entail an event model, lots of hooks, and mechanisms for persistence across sessions. The OS offers an API for all of this, yes, but not always at a high enough level. By design. Managing some "higher level" is not really the OS's job. A layer of "education applications" wrapped around various spatial geometry animation engines is reasonable to anticipate, plus I expect many of them will come with Python bindings, although not necessarily exclusively (any number of languages should be enabled to play, by giving them some shared target language -- precisely the intent of the .NET design, and Parrot's). Kirby
I cropped and blogged my previous post and added some hyperlinks for the benefit of readers who might want more decrypting of this particular alphabet soup, other allusions. http://worldgame.blogspot.com/2006/05/blabbing-on-edu-sig.html Kirby
Winston Wolff wrote:
On May 6, 2006, at 11:25 AM, John Zelle wrote: But I'd like some clarification on what this goal is.
I don't think there is total agreement on that (or ever will be). Speaking for myself, my goal it to support educational constructivism on the Python platform, inspired by "Squeak" and "Self", but going beyond those in a Pythonic way. I mainly want to support support "unschooling", "free schooling", and "informal" education (though other uses are possible, of course, like in the classroom). And here is a sourceforge project to that end: :-) http://sourceforge.net/projects/patapata/ The mailing list is now active here: https://lists.sourceforge.net/lists/listinfo/patapata-discuss
Everybody is talking about a new 3D GUI and IDE. What exactly are we trying to achieve by building a new GUI? What is wrong with existing Windows/X/Mac GUIs for an educational project?
Take a look at this video on the "Self" programming language and environment to see part of what inspires me: http://www.smalltalk.org.br/movies/ But if you just want the overview, consider: http://research.sun.com/self/papers/programming-as-experience.html Now, Squeak and Croquet have their own twist on this as well producing other ideas worthy of consideration. Lots of resources on the web on those and related issues are linked here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-September/095155...
If we were talking about UI research then developing a new GUI system might be interesting, but for educational purposes, it seems like we have enough to do to achieve educational goals, without trying to redevelop a GUI system.
UI Research? :-) Croquet is about five years old. Squeak is about ten years old. Self is about twenty years old. Smalltalk is about thirty years old. Key aspects of these development environments are still missing in mainstream Python development IMHO (e.g coding in the debugger, graphically manipulating data structures, fine grained version control, prototype-oriented development, modifying running programs, effortlessly saving a living world of objects, transparently drilling down through the system, easily coordinating multiple developers using all the above tools on the same object space, and so on). Not to say you can't do a little of some of these with existing tools in Python, of course. It's more a matter of degree and integration. It certainly generally is not easy. As a developer, I want as many of these features as possible under a Python GUI and IDE to develop extendable educational simulations. As an educator, I think learners will benefit from them as well, whether they are learning to program or learning to master the content of a simulated microworld. Now obviously, when one tries to think about doing these older things on a newer platform like Python, with its own culture and strengths and weaknesses, some R&D is required to adapt them to that new framework. And of course, while one is doing that, it would be interesting and motivating to think about doing something even better than what went before, rather than simply reinvent the wheel (or port it :-). But, as Kirby rightly points out, Python-as-it-is is quite serviceable for self-education, and so are existing GUIs. If you are content with that, then go for it! --Paul Fernhout
On Saturday 06 May 2006 11:40, Winston Wolff wrote:
On May 6, 2006, at 11:25 AM, John Zelle wrote:
To me, it seems that a 2D/3D persistent scene-graph API paired with a GUI toolkit, both based on PyOpenGL is the obvious first step toward this goal. <<snip>>
But I'd like some clarification on what this goal is. It seems like a lot of people are talking about lots of cool technology, but I've not read what we are trying to do with it. And of course we wouldn't want to build a technical solution in search of a problem.
Everybody is talking about a new 3D GUI and IDE. What exactly are we trying to achieve by building a new GUI? What is wrong with existing Windows/X/Mac GUIs for an educational project? If we were talking about UI research then developing a new GUI system might be interesting, but for educational purposes, it seems like we have enough to do to achieve educational goals, without trying to redevelop a GUI system.
Kirby has already weighed in with his grand vision. My goals are much more modest (though not necesarily in opposition). Winston is right that there are lots of great tools available now, an embarrasment of riches so to speak. We can and should plunge ahead with educational materials. Still I have an itch that is currently not scratchable, and I think requires reinventing the wheel. I am looking at Python as a learning environment for computer science, as a platform for building compelling educational material (e.g., bringing VR to the classroom), and as a sandbox for all kinds of experimentation. Here's what I don't have now: 1) An easy to use 3D environment (ala VPython) that is extendable in Python. When I need realistic materials or textures, I want to be able to add that without having to wait for the C++ gurus to put it into their library for me or having to wade into that muck myself. 2) A solid, easy to program cross-platform GUI toolkit that integrates with #1. I cannot now reliably develop, say, on Linux and expect that my students with various flavors of Windows and Macs will get the same experience. Educational apps/IDEs/enviroments need to be rock solid, snappy, and consistent across platforms. We really don't have that now. There are always extra layers and external dependencies that get in the way. Maybe PyQT4 will solve this one? 3) A simple to use GUI builder (ala Visual BASIC, but more basic ;-) for #2 to take the tedium out of widget placement. 4) For CS education (and all those interested in knowing how computers really work), it would be great if the Python graphics stack went all the way down to the machine (actually OpenGL) level. Like Squeak, but using hardware acceleration. Then everyone has a ticket to play just by learning Python and showing some curiousity. Can we program a modern 3D game, for example, in Python? Or is knowledge of C++ the price of admission. I don't know, and I'd like to find out. I think #4 is where I part company with Kirby. I'm not looking for some machine-level 3D libraries that are scripted via Python (or another high-level language, ala Alice). I want the snake all the way down, and I want the underlying graphics engine to be installed everywhere Python lives with OpenGL, so that I can count on it. 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." -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle@wartburg.edu (319) 352-8360
On 5/6/06, John Zelle <john.zelle@wartburg.edu> wrote:
I think #4 is where I part company with Kirby. I'm not looking for some machine-level 3D libraries that are scripted via Python (or another high-level language, ala Alice). I want the snake all the way down, and I want the underlying graphics engine to be installed everywhere Python lives with OpenGL, so that I can count on it.
I should be quiet and study Panda3D for awhile. http://panda3d.org/ That may be what I try teaching through Saturday Academy in the Fall. Kirby
I just looked at Panda3D. The export restrictions in the license are troublesome. Another obvious drawback in the intro is the reference only to Windows and Linux, not Apple. I do not know if that might change with Apple moving to Intel. Sigh, for a Linux or Windows lab in the US, it looks nice, but for our general community projects, platform and country independence are important.. Andy kirby urner wrote:
On 5/6/06, John Zelle <john.zelle@wartburg.edu> wrote:
I think #4 is where I part company with Kirby. I'm not looking for some machine-level 3D libraries that are scripted via Python (or another high-level language, ala Alice). I want the snake all the way down, and I want the underlying graphics engine to be installed everywhere Python lives with OpenGL, so that I can count on it.
I should be quiet and study Panda3D for awhile.
That may be what I try teaching through Saturday Academy in the Fall.
Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- Andrew N. Harrington Computer Science Department Undergraduate Program Director Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin@luc.edu Chicago, Illinois 60611
Sigh, for a Linux or Windows lab in the US, it looks nice, but for our general community projects, platform and country independence are important..
Andy
I haven't studied the license carefully. I did notice a version for Ubuntu in the downloads section. Anyway, I think experience with Panda3D will help me think about these issues we've been grappling with of late (Python vis-a-vis stronger graphics) -- whether or not this tool becomes widely adopted in say the TuxLab setting. Thanks for your heads up though. The wrong licensing does have a way of killing an otherwise promising initiative. Kirby
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
[snip] John Zelle wrote:
I've been thinking about just this sort of project.
That's a relief, sometimes I think I'm the only one thinking in this direction.
My hunch is that a Vpython in Python is now very doable using PyOpenGL. By building on OpenGL, most of the heavy graphics lifting can be done on the graphics card (even cheap ones are ridiculously fast these days). The OpenGL API is now standardized and stable for development, as long as one sticks to basic features for which hardware acceleration can be taken as a given.
But OpenGL is not a modeling API, it's purely for drawing things. We need a higher-level standardized scene graph layer (ala VPython). This combination would make the entire graphics stack down to hardware Python based. VPython as it stands is very nice, but it is not extendable in Python. Want a more realistic shading model? No can do. Texture mapping? Out of luck. Stereo-modes? (well OK, but I had to do that in C++ ;-). It might be that something like the PyOpenGL Context code base could be used as a starting point.
Yes, these are exactly the issues I run into with VPython (that, and having to run it on OS X in linux-emulation mode).
Along-side the modeling layer we need a good OpenGL-based gui toolkit as well. You really can't build a decent GUI in something like VPython. It would be nice if solid, good-looking applications could be built entirely on Python w/o having to introduce some other C/C++ dependencies. Relying only on OpenGL would give us a truly portable GUI kit (except for a very thin layer that glues it to the underlying windowing system ala GLUT). It could have a consistent, though not necessarily native look and feel anywhere OpenGL runs. I'm willing to give up native look and feel provided the toolkit looks great and has really snappy performance. Another approach would be to make the GUI themeable, so folks could easily implement themes to mimick standard native widget sets. Basing on OpenGL should provide these abilities. The entire X-library has now been impelemented on OpenGL, there's no reason in principle a decent OO gui framework couldn't also be built there (and there are already some candidates out there to use as models).
By making VPython play well with other OpenGL-based systems we should be able to get this "for free" or nearly so. For one thing, The 2D system Cairo has an OpenGL backend called Glitz, and folks are definitely using Cairo to build GUIs.
I know I'd love to have a 3D environment that was both easy to use, and extensible.
Exactly. I agree that Vpython in Python would be a great start.
Yeah!
To me, it seems that a 2D/3D persistent scene-graph API paired with a GUI toolkit, both based on PyOpenGL is the obvious first step toward this goal. Alone, it would not really be very Squeak-like, but a Squeaky IDE needs the ability to describe a persisitent view (2D or 3D) as a basic starting point. On top of that foundation others can build the ultimate constructivist educational platform...or just some neat, useable 2D and 3D applications. Others could work on extending and improving the whole shebang without having to know any C or C++.
The only question in my mind is how do we get started in making this vision a reality? I'd love to dive in and start working on it myself, but realistically, I've already got a lot of committments (writing is *$&% hard work :-). Where do we go from here? Ideas Dethe?
I have taken a stab at reimplementing VPython in PyOpenGL, but ran out of motivation. I have some outstanding time committments for my hobby-coding time for the next month or so, but would be willing to take this up again. Certainly the OpenGL context work would make a good starting point, at least for tips and examples, even if the final result was not built on that. There is also an open-source X3D engine which might be useful for an example state machine. One of the reasons I periodically get excited about Python bindings to 3D engines like Blender, Ogre, Panda3d, etc., is that I hope that they will provide a better basis to build a new, inclusive VPython on than raw OpenGL, but I think that is just wishful thinking and I should roll up my sleeves and Just Do It.
By the way, how is the non-Fink port of Vpython for OSX going? We could really use that right now. My Mac students don't want to mess with Fink just to do a few Vpython projects.
Their build system defeated me. I finally gave in and installed the Fink version, which pulls in Gnome, among other things (632 MB to access the OpenGL that is *built in* to OS X). It took many hours to install, requires X, and brings my system to a crawl when I use it. I think my time might be better used porting it to Python than trying to fix their autoconf-and-Boost madness. As you say, simplicity is what makes VPython shine, and the system doesn't actually do all that much. It's a shame that the simplicity ends when you try to build it. --Dethe
-- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle@wartburg.edu (319) 352-8360 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
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/p... 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.
On 5/5/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote:
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.(*)
It wasn't like that. We sat around long tables and talked. No one had more than five minutes to do any kind of projected presentation thing. Croquet was mentioned in passing but never shown. Just wanting to keep the picture at least a little bit accurate. There's a wiki page with official notes, links to photographs Guido snapped with his cell phone (I'm disguised as a round looking man with shaggy gray hair). For another picture of me see here: http://mybizmo.blogspot.com/ scrolling down to Spring 2006. Kirby
kirby urner wrote:
On 5/5/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote:
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.(*)
It wasn't like that.
We sat around long tables and talked. No one had more than five minutes to do any kind of projected presentation thing.
Croquet was mentioned in passing but never shown.
Just wanting to keep the picture at least a little bit accurate.
Thanks for setting me straight on that. --Paul Fernhout
participants (7)
-
Andrew Harrington -
Dethe Elza -
Ian Bicking -
John Zelle -
kirby urner -
Paul D. Fernhout -
Winston Wolff