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

Paul D. Fernhout pdfernhout at kurtz-fernhout.com
Sun May 7 17:08:35 CEST 2006


Ian Bicking wrote:
> Zope went down that path with through-the-web development with the ZODB 
> as the image.  I think everyone agrees that didn't work.  Smalltalk has 
> pursued that with more vigor, but I was never comfortable with the 
> image.  In some ways you can read my comments as me figuring out just 
> why I dislike the image model.

Well, everyone? :-) Check out http://www.1010wins.com/ for what was, last 
I heard, a major Zope site.

Still, a lot of peopel agree with you, so there are clearly issues here.
For all I know, that group is unhappy?

I myself like images you can build from text when you want to, but that 
has never been the focus of most Smalltalks (and isn't for Squeak so far).
But, I think a truly Pythonic approach might insist on building objects 
from text, although it is true that we have pickle, which uses text, but 
not as a Python program.

> I think it's important to figure out, because the image model seems very 
> compelling for an education environment.

And John also made some of those points indirectly. I think from a 
"classroom" standpoint, teachers generally want to be in control of what 
the student sees, at least at first, and they also have short classes ("45 
minutes) where they do not want to waste time on configuration. So, 
preparing an image for kids and seeing it pop up exactly like you made it, 
whatever the hardware (like Squeak can do) is a big win in a classroom 
setting. Of course, I'm not big on conventional classrooms :-), but I 
think images are desirable for independent or informal learning as well, 
which can happen in fits and starts, where you might do something 
intensely for days and then not revisit something until months later. And 
it would be nice if everything was just the way you left it. Also, as a 
developer of (hopefully open) educational simulations, I see the value in 
being able to deploy the simulation as an image which people could then 
modify to their own needs. So this is an area of overlap regardless of 
educational paradigm.

Granted though, if you want to learn about the details of the machine you 
are on, or the notion of a software stack, like Kirby pointed to a week or 
two ago, in terms of getting into the specifics of GNU/Linux, then images 
are hiding stuff you might want to make visible. (Of course, you could 
open a terminal window from your running image. :-)

I think a big issue with "images" is that they presume that you will put 
in the time to learn the tools assembled in the image (assuming the image 
is mainly about learning programming) rather than use some older ones you 
are comfortable with already. It is much easier to type text on the 
command line or use your favorite text editor than to learn an IDE 
(especially when you are learning a new language at the same time). But 
the value of learning an IDE can be immense in terms of letting you manage 
complexity far beyond what you can do with a text editor.

It is funny how we can all accept that learning to play a musical 
instrument like the flute might take years of concentrated study to even 
get a good "tone" out of it, but we expect computers to be engaging on a 
minute by minute basis. Or, we just accept that learning to touch type 
takes days of practice. But computer IDEs? Do they really need to be like 
video games, engaging and addictive from the first quarter?

John Holt wrote on this when he talked about "hard fun" (also mentioned 
here recently in another context I think) and how playing music, 
considering the suffering involved to get good at it, could hardly be 
described as "fun", but there certainly is something there for many people 
that keeps it engaging as a transcendental experience (as a sense of 
"flow"). Still, I think people here are right when they suggest typing at 
the command line an doing text processing produces feedback that keeps 
people engaged. The question is, can a graphical IDE do that, and I think 
the answer with Self might usually be "yes". I think the answer with 
"Squeak" is sometimes "no" though, but I have real experience with that, 
and have still never used Self. :-)

Still, the "E" in CP4E is about "Everyone", so I can see the value in 
trying to make things accessible to broader audiences. My hope is that 
both the expert and the novice can be satisfied by a better system, and I 
think "Self" (or to a lesser extent "Squeak") helps show that way, 
prudcing a system I can love as an expert, but (taking their word for it, 
at least for Self :-) I think novices can warm to quickly as well. That 
gets back to the point I made on innovation -- satisfying both needs at 
once (e.g. expert and novice both love it) rather than compromising 
somewhere between them (e.g. not so hard for novices, but not so 
interesting for experts).

>>I can see the value of all this from the GUI side, with various desired 
>>display options defined in the class or prototype. But again, Python 
>>object are (or should be :-) constructible from scratch without calling a 
>>class' init function. 
> 
> 
> I don't understand what you mean here?  Most objects aren't 
> constructible from scratch.  Many objects are immutable, and can only be 
> recreated, not modified.

OK, good distinction. But the immutable ones are (always?) recreateable 
from code? And the rest can be made by creating a bare object "object()" 
and filling in its dictionary?

I get errors when I try that though:
 >>> x = object()
 >>> x
<object object at 0xb7e503b8>
 >>> class Foo:
...   pass
...
 >>> x.__class__ = Foo
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: __class__ must be set to new-style class, not 'classobj' object
 >>>
I do not yet understand that error.

I guess, there might also be objects that wrap external resources like 
sometimes handles to bitmaps where those resources could not be accessed?

In Smalltalk, this is handled in part by the distinction between "new" and 
"basicNew", e.g.:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-May/057790.html
where "new" may call initialization methods with various side effects 
(often just "self basicNew initialize"), but "basicNew" just gives you the 
object of that class without much data in it (so you can call initialize 
yourself or do something else). The message "basicNew" is what is used 
typically by Binary Object Streaming systems when objects are recreated, 
then they fill in the fields from what is in the file.

>>So, given that a writer can inspect an instance and 
>>just write out all the fields in its dictionary and their values it seems 
>>like we can write out any object (though perhaps it may need to 
>>recursively write out parts of embedded objects first, and then perhaps 
>>patch up circular references at the end).
> 
> 
> You mean pickle?

Well, a pickle-like system that writes out (hopefully readable) Python 
program code, yes.

> There's a bunch of pieces.  

Thanks for the elaboration on this. I need to think more on these points 
you raise.

Still, it seems your focus here in what you outline as outstanding issues 
is more on reading and preserving and otherwise handling human written 
source code or the complexity of a large multi-module textually defined 
program (which is understandable for you are writing an IDE in a sense, 
where you want to give the user/developer help *before* the program is 
running) then reading and preserving objects (where source code may be 
just part of what is stored, and the user/developer is given help *while* 
the program is running). Perhaps the difference is that with an IDE you 
care more about how the objects are going to be created (given you are 
helping the user to write programs to do just that), whereas with saving 
and reloading an image I just care about anything that works and is 
marginally understandable for debugging the save/load process, expecting 
the coding to be done within the IDE on a fine grained basis (i.e. you are 
just look at one function at a time in a browser, like in Smalltalk, 
rather than scrolling through a file). Not to say producing clean readable 
Python programs as images isn't a good goal down the road for me, but 
clearly with an IDE it is your upfront goal. I think an innovative 
convergance comes if a new system with an image works well enough that 
people would choose using it to program over just editing long text files.

--Paul Fernhout


More information about the Edu-sig mailing list