[Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak

[Paul D. Fernhout]

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