[Edu-sig] Refocusing on Capabilities (was PySqueak)

[Paul D. Fernhout]

kirby urner wrote:
> About your prototyping experiments:  I'm interested in learning more 
> about Self and would gladly attend lectures on same, at OSCON or 
> wherever.  Then I could better follow your logic.

Save yourself the airline fair :-) and just watch online:
   http://video.google.com/videoplay?docid=5776880551404953752
or:
   http://www.smalltalk.org.br/movies/
At least to see the basics.

For textual statement of the key issue, see:
   http://en.wikipedia.org/wiki/Self_programming_language
"The problem: Traditional object languages are based on a deep-rooted 
duality. Classes define the basic qualities and behaviours of objects, and 
instances are a particular object based on a class. ... Unless one can 
predict with certainty what qualities the objects will have in the distant 
future, one cannot design a class hierarchy properly. All too often the 
program will evolve to need added behaviours, and suddenly the whole 
system must be re-designed (or refactored) to break out the objects in a 
different way. Experience with early OO languages like Smalltalk showed 
that this sort of issue came up again and again. Systems would tend to 
grow to a point and then become very rigid, as the basic classes deep 
below the programmer's code grew to be simply "wrong". [My note: I think 
Squeak got to that point of rigidity long ago. :-) ] Without some way to 
easily change the original class, serious problems could arise. ... In 
general, such changes had to be done very carefully, as other objects 
based on the same class might be expecting this "wrong" behavior: "wrong" 
is often dependent on the context. ... The problem here is that there is a 
duality, classes and instances. Self simply eliminated this duality. ... 
This may not sound earth shattering, but in fact it greatly simplifies 
dynamism. If you have to fix a problem in some "base class" because your 
program has a problem, simply change it and make copies of that new object 
instead. No other program will see this change. ... This dramatically 
simplifies the entire OO concept as well. Everything might be an object in 
traditional system, but there is a very fundamental difference between 
classes and instances. In Self, there isn't."

Now this perhaps paints an overly rosy picture of the solution. In 
practice, how libraries are written and what tools you use make a big 
difference too. And Python's use of namespaces make possible management of 
some of these issues in a different way. Still, I think there remains of 
core of truth to this, at least as a sense of the overall "tone" of 
development. You really need to see it in action, like with the video, to 
really grasp what is possible and what is different about, at the very 
least, the GUI development paradigm (which in some ways is not that unlike 
Delphi or VB, but applicable to even regular objects).

> My layman's question, after reading your posts, is:  why not just keep
> Python pythonic and Self selfish?
> 
> In other words, Python already has a very strong paradigm, very simple 
> to learn.  Why mess with that?  I guess I'm a purist in that regard. 
> But that doesn't make me a language bigot, as I fully respect the right
> of other languages to define themselves around equally strong, yet
> different, paradigms.  I'm also biased towards OO.
> 
> That doesn't mean I think the lambda calculus people can't hack their 
> own brands.  They already do, and quite successfully by the look of 
> things.

This is a good question and a good related comment.

In general, you are right of course. And I understand your point about
language bigotry. I agree, and I think it is not bigotry to say a language
does certain things well, and if you want to do those things well and
easily, stick with its  mainstream approach. Languages have cultures and
paradigms, and you swim against them at your own cost (especially in terms
of productivity).

Still, I wonder if dominant paradigms in the future will be mainly OCaml
(or a derivative) as a better C, and something derived from Self (maybe
with Python syntax) as a better Smalltalk. I understood the value of OCaml
much better when I stopped thinking of it as a Python or Smalltalk
replacement but instead as a C/C++ replacement. I'm not even sure the
OCaml community sees themselves that way; they almost certainly don't. :-)

Python is stuck in the middle there, and sometimes that is a great place
to be (especially at the right time), and sometimes it isn't (especially
if times change, in part due to its own success). I feel Python as a
community right now as it contemplates its own evolution is torn between
types and prototypes. Like Squeak, it has developed its own approach
to solving the type problem by having a mini-language in the PyPy project,
but, while I think it is a neat thing to try, I am left wondering if
perhaps it might be better to just use something like Ocaml for that
purpose. As an analogy, I read there was a Basic English that all
aircraft pilots and control tower operators were supposed to learn
of a hundred or so English word to allow any pilot
to land at any airport. Worked well for all the non-native English
speakers, but the people who had problems with it were surprisingly
the native English speakers, because they has problems remembering
what they could say and what they could not. So, perhaps,
except for a single purpose of maintaining a VM, a language like
Squeak's slang or RPython will never have the value that
something like OCaml will have as a general tool. So, back to
my point of maybe types and prototypes being dominant paradigms, with
types implementing performance critical stuff and prototypes supporting
everything else. So, I see this PySqueak work as being a step into that
future of Prototypes and types, but I'm working on the Prototype side, not
to slight the types side. OCaml and relatives seems to have that nailed,
because they are able to infer types, so you get the benefits of types
without as much syntactic clutter. And clutter means programs that are
harder to read and thus harder to maintain (which is why Java fails as a
productive language in practice, even when you have tools to write the
boilerplate for you; we really need a tool for Java that hides all that).

But, still, to agree with your sentiment, who would want to use a buggy
new system that in addition to all of Python's warts (*)
   http://www.amk.ca/python/writing/warts
then adds in on top of that new paradigms and other clutter to learn? And
makes difficult to use the old ways, which are well documented and well
known? That is always the inventors or innovators' dilemma. There is
always a strong constituency for the status quo, and so a new idea has
many strong enemies and few half-hearted friends. And I think that is
one reason I tend to start over from scratch on language projects; if no
one is going to use it, then I might as well write it the way I want it to
work then adopt someone else's compromises and legacy choices (which even
they may no longer be happy with). On the other hand, progress is often
most quickly made by focusing on one specific issue (though not always),
so in this case focusing on prototypes gets me more mileage than focusing
on syntax (which is the hardest thing for most people to learn it seems).

Having agreed somewhat, still, as one inventor (Edison?) was quoted:
"What is the value of a new baby?"

Python as it is solves whole classes of problems well (text processing,
file handling, sockets, gluing C libraries, but lots more).
Still, it has weaknesses, especially for entry-level GUI programming.
Compare it to HyperCard which met many of CP4E's goals twenty years ago:
     From: http://en.wikipedia.org/wiki/HyperCard
"HyperCard was a huge hit almost instantly. Many people who thought they
would never be able to program a computer started using HyperCard for all
sorts of automation and prototyping tasks, a surprise even to its
creator." Or from:
   http://www.wired.com/news/mac/0,2125,54365,00.html
"The result is both simple and powerful. Fifth-graders get to grips with
HyperCard in minutes, building databases of their Pokemon cards. Cyan, the
game publisher, used it to create fiendishly complex games like Myst and
Riven."

Makes me wonder why Python is still struggling with questions of what is
the best GUI development tool for it? Or why we think CP4E is needed given
Python exists? Is just a better IDLE what it is all about? What is
missing? PythonCard is a great step in the right direction. But, I think
part of what is missing in Python is the prototype-like notions which are
behind HyperCard or Self, or even Delphi or VB GUI development, to a 
lesser extent. (HyperCard has a English-like language too, but
I'll ignore that here, taking a more formal programming language syntax as
a given.) Python also fails in practice with modifying programs while they 
run, which becomes a big issue for intermediate-level programs and their 
programmers.

In this case, here are two big arguments for "Self" and a
prototype oriented mindset. One issue it tries to address is something
that by now you may take for granted but may still be a stumbling block
for new programmers, which is how people usually reason from particular to
general. And so they may be better off learning to program a particular
object then to program a class of objects. So, in Logo, teaching "Fred"
how to draw a spiral may be easier than thinking about a "Fred" class of
objects that all draw spirals. You say Python has an easy paradigm to
learn, but I think that is not quite true. Python has many inconsistencies
and warts (consider the fraction email I just posted) and is approachable
to many people in part precisely because they learned C or BASIC first
(e.g. infix functional notation), and are looking for something better and
more fun and powerful. (**) I feel adding stronger support for Prototypes, 
if not at the language level then at the tools and library level, would 
potentially help make Python more approachable for beginners. And I think 
the Self claims are in that direction. Still, Self is not the only 
approach to prototypes, see for example:
   http://www.dekorte.com/docs/protos/
And consider the statement there: "Prototype-based languages are object 
oriented languages where a new object instance is "cloned" from existing 
live object (a prototype) instead of being constructed by a class. This 
makes the language simpler by requiring one less data type and solving the 
infinite regress problem of classes (if you use a class to create an 
object, what do you use to create a class?). It is also ideal for systems 
such as GUIs where the pattern of creating one object by copying and 
modifying another is already handled by the language itself."

The second big area is the "fragile base class problem" or more generally
the issue that people want to customize their images or programs, yet that
messes up anyone else who want to import the code. By having a culture of
working with prototypes, one is more used to customizing specific set ups,
and then having tools which help one integrate customizations. One is more
used to splitting off a set of base classes and doing different things
with them in an experimental ways, then all the careful work that goes
into maintaining one common set of classes (Even if ultimately one may
prefer to minimized the number of base classes one works with). I think 
work in that direction is a way to get the benefits of something like 
Squeak as a platform without all the drawbacks of continually having old 
code fail with every new small release.

Still, in Python's defense (or condemnation :-) in practice it doesn't
have a class side equivalent to Smalltalk. You can make one using wrapper
functions, and you can use shared class variables, but in general, Python
programs don't do things in the class way Smalltalk does. And since much
Python code is written in text editors, there is also not the issue of a
class side / instance side set of two buttons which every Smalltalk code
browser has and can lead to confusion. Python has been creeping more in a
class direction, but in practice Python code isn't written that way. So,
in that sense, Python is already a lot more Prototype oriented than
Smalltalk, plus Python supports instances having their own ad-hoc methods,
so again more prototypish. However, even if Python does support this sort
of development, in practice, Python examples are written in a more
class-oriented way. And Python tools as well. A big part of what I am
exploring right now is more how to make a library of Self-like Morph
prototypes which can be used to build interfaces in a more Self-like way.
Squeak introduced Morphs, but then made them into classes (and badly
factored ones at that), which I think lost some of the power.

By the way, here is a PataPata (PySqeuak) version that allows wx Widgets 
as Morphs (with some wrapping, which is only trivially done at this stage 
as a proof of concept for Buttons, TextEdits, and Sliders),
http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/PataPata.py?view=log

I already have hit a wx bug with the version I use where Buttons
don't display drag feedback because they capture mouse drag events when
clicked, e.g. the same as probably here:
http://groups.google.com/group/comp.soft-sys.wxwindows/browse_thread/thread/121a5068724c613/e077cfa418cbd5d3?lnk=st&q=wxwidgets+button+mouse+events&rnum=7&hl=en#e077cfa418cbd5d3
I can drag wx sliders or text fields correctly though.
I saw the same problem when trying the latest version of PythonCard, but
now think it is wxGTK not PythonCard.

This new version uses a more generalized notion of properties than earlier
versions in order to be able to wrap foreign widgets (though not Python's
properties, which were too limited in some respects, and also would have
not worked in Jython 2.1). Still, with this wx bug (I see no way around
it, but that is par for the course when using native widgets or a C
library), plus the extra layer of indirectness wrapping in properties
requires, I am left wondering if I should just go push ahead with drawing
my own widgets, perhaps building on wx OGL or one of the other widget sets
people have made like Pyxel.
   http://bellsouthpwp.net/p/r/prochak/pyxel.html
If I do my own widgets, then I could fairly easily make everything work as 
a Jython-based Java plugin, which would be a neat deployment vehicle. And 
if I keep the advanced property support, then wx or TK widgets are always 
a possibility for someone who wants them.

--Paul Fernhout

(*) and there are several not listed there I could mention, though I still
agree with the author there that: "When viewed next to the large number of
things which Python gets right -- a small language core, strong but
dynamic typing, reuse of the idea of namespaces, always using call by
reference [I think he means value], indentation instead of delimiters --
these flaws are small ones, and I can easily live with them".

(**) For another example, if you look at it from a
documenting-intent point of view, Smalltalk's keyword syntax (e.g. Window
showAtX: 10 y: 20." ) makes reading programs much easier than reading
functional syntax where arguments have no hints (e.g. "Window.show(10,20)"
) and reading programs is what most programmer's spend most of their time
doing. :-) So, if you really want programmers to have happy lives,
teach everyone keyword syntax. :-) Of course, I am living with Python's
functional syntax in order to gain some of the other benefits of it, but
that doesn't mean I am happy about that aspect of it, or that I think it
is good for beginners either. Actually, another Python wart is that
variable names in a function definition become part of the API (e.g.
"myfunction(x=10, y=20)" which is a gross violation of the notion that a
function definition, including local variables, should be independent of
specifying how it is called.)