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

[Paul D. Fernhout]

Kirby-

All good points. And we definitely need a better infrastructure given 
continual population growth -- especially one doing more with less, and 
doing it in a more resilient and sustainable way. I think that is also one 
of the pushes towards prototypes in "Self" -- the Self authors describe an 
attempt to address the fragile base class problem and make software both 
more flexible and more resilient (as well as more consistent).
    http://en.wikipedia.org/wiki/Self_programming_language

And, along those lines, more updates on the PataPata (PySqueak) project:
   http://sourceforge.net/projects/patapata

There is now a screenshot of the 25th proof of concept at:
   http://sourceforge.net/project/screenshots.php?group_id=165910
That should give a sense of what the whole thing does so far as the demo 
is only one window (although there are also popup menus you can't see).

Note: Under Gnome, you need to change Window manager preferences so that 
ALT does not drag windows (choose the Windows key instead). I have not 
tested it under other platforms, though wx (2.6) should run on Mac and Win.

You may notice by looking in the browser (yellow part) of the screenshot 
that I made a design decision to implement multiple-inheritance (of 
traits) but using a list of name strings rather than direct pointers, so 
any prototype you want to use as a parent needs to be given a name under 
"world.worldGlobals[]". Personally, I find the most important part of 
programming to be documenting *intent*, and so I thought the explicit 
naming requirement was OK. I've always been dismayed at the potential of a 
Self-like approach to create a real mess otherwise. (Forth us another 
language system that fails at documenting intent too, though it does most 
everything else right.) These named prototypes take the place of classes, 
but without the class-side / instance-side divide of Smalltalk.

The twenty fifth proof of concept now can load and store Python source 
files of prototypes (essentially by just writing a "define_prototypes()" 
function and exec-ing it back in). There are some limits that embedded 
Python objects you want to store must implement a 
useful-for-reconstituting __repr__ string (though it does handle nested 
dicts and lists out of the box). You can finally add and remove prototype 
fields from the inspector, create new methods and edit them, and it now 
has an interactive shell plus some other polish. See the code at:
http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_025.py?view=markup

An example of the Python source file it can write and read (demonstrating 
the idea discussed a couple weeks back of using Python source instead of 
pickle files to save widget state) is here:
http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/some_output_prototypes_written_by_poc25.py?view=markup
You don't need it to run the P.O.C. 25 demo though; that is still 
self-contained. [This example file is missing a few world methods I added 
afterwards.]

The system is still limited to two widgets though (Morph and TextMorph). 
Adding more widgets is a bigger undertaking and realistically will likely 
entail splitting the prototype into multiple files, which I have been 
avoiding.

Also, functions defined in the interactive shell (as opposed to defined in 
a file or defined using the inspector) don't have source code available, 
which would be a problem when you save them. Not sure how to fix that 
easily without changing wx's shell.py. But that's not really what the 
shell is for as opposed to interactive testing or importing other Python 
files, so it's a minor problem for now. For now, best to stick to defining 
new prototype methods using the inspector or source files.

The system may finally be at the point where (in theory) one could use 
only the system to improve itself, though in practice messing with the 
wx-based GUI scaffolding by changing the main application source file 
would still often be easier. Everything is still in one Python file for 
ease of prototyping and people trying it, but at ~49K it's straining to 
break loose into various files and who knows what else. :-)  Anyway, I 
definitely feel it has reached the point where it is a useful tool for 
learning about prototype-based-programming in a Python context. Not my 
eventual goal, but a useful byproduct.

Amazing what is easily possible by building on top of Python and not 
getting sidetracked (as I usually do) by writing a new interpreter or 
messing with the syntax (at least, not at first. :-) Well, that and 
throwing performance and morph-loading-security to the winds. :-)
[It does point out the need for a Python VM with security flags one could 
set like Java has (e.g. can't write to most files, can't open most 
sockets, etc.), although I guess you could run under Jython to get some of 
that.]

Still no 3D yet, though. :-(

Say, Kirby, speaking of "data rich content", can you suggest any Bucky 
Fuller-ish or synergetics-type graphics or clip art under a 
free-as-in-freedom license somewhere on the web I could use to spice this 
demo up when I move beyond having everything in one file? Ideal would be 
graphics a demo could load from the web as a URL to keep everything in one 
file (though I probably should put them on another web server to be 
polite, though I don't expect anybody to really use it anytime soon). Even 
just graphics like the individual source items for the web page you linked to:
   http://www.grunch.net/synergetics/gst1.html
might be snazzy to just drag around as Morphs. Or perhaps I could try to 
use them to make a HyperCard-like stack with the proof-of-concept as a 
test and to motivate putting in related supporting features (including 
perhaps a Bitmap-from-URL-Morph and a Card-Morph and a 
Stack-Of-Cards-Morph). Also, if you have any pointers to 
free-as-in-freedom Bucky-related content I could throw in such a stack, 
that would be nice too. I'm mainly just looking for something that makes a 
nice demo with a dozen cards worth of interesting educational content and 
graphics. I could go with gardening (I've lots of stuff on that) but I 
thought Bucky stuff might be more fun right now.

--Paul Fernhout

kirby urner wrote:
> Good thinking Paul, about the balance between optimism and skepticism.
>  We do need to revisit old designs, and admit their weaknesses.
> 
> USAers still seem in denial about their infrastructure.  A lot of it's
> still good, but was meant to be maintained, not neglected.
> 
> My hope is that infusions of data rich content will help people feel
> more in the driver's seat, in terms of at least tracking what's going
> on.  Python-the-language is helping with this (at Google, other
> places).
 >
> [snip]
> 
> We want to get work done, and so we need to play, we need to make
> happen, and we need to keep track and recycle.
> 
> Python has those capabilities:  it reads like pseudo-code and so is
> suggestive and encouraging of playful exploration; in production
> settings it generally does a reliable job of handling real world
> responsibilities.  [snip]