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

[Ian Bicking]

Paul D. Fernhout wrote:
> 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?

There's a general consensus in the Zope community that through-the-web 
editing and putting application code in the ZODB wasn't a good idea.  So 
they've moved on to other means of development, mostly with files on the 
disk.  At the same time, they've also moved away from the ideal of a web 
development environment accessible to beginning programmers, which was 
at least an early Zope goal.  Though Plone is probably the exception to 
both of these.

My impressions -- direct and indirect -- of what happens with typical 
projects stored in the ZODB, is that they just had all of the normal 
software engineering problems.  But they weren't able to take advantage 
of all the work people were doing in other environments -- version 
control, Python's code layout (modules, packages, etc), and all the 
other tools developers use.  And maybe that's the only problem (though I 
think there are others).  On the measure of tools alone Smalltalk should 
be fine, as they've written their own full stack of tools, even though 
at the same time they pretty much isolate themselves from the mainstream 
of tools.

I also hate the idea of extending Object, which is common in Smalltalk 
(and Ruby, with no image), and my distaste for that might tinge my 
feelings on images.  Zope didn't add that, but it has its own ways of 
introducing that same kind of complexity that I dislike.

>> 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.

I think there's a lot of practical problems with that.  What happens 
when you find a bug in the image?  How do you figure out where code came 
from?  Is it system code, teacher code, peer code, your own code?  If 
you edit system code, you've made your image incompatible with anyone 
else's image, and anyone who imports your change will probably be 
corrupting their image.

And when you have this big ball of an image, the student has to choose 
which line of continuity they want -- do they keep their code, or throw 
it all away for the next class?

I'm all for making tight bundles of code with controlled environments; 
that's important for everyone, not just classrooms.  But there's another 
line of control, which is how you integrate new packages into that 
environment, and how you extract packages, and how you update packages. 
  A classroom should be as ready to do all of these things as 
professional programmers, because they actually share all the same basic 
needs -- fixing bugs, applying workarounds, sharing code, making code 
reasonably portable (if only, for instance, to allow the teacher to run 
it in their own environment).

Software engineering tools and methodology can be hard to adopt (even 
for professional programmers), but there's also a lot of good ideas in 
there that apply much more widely than just software.  So I think it's 
worth keeping all those processes in mind.

> 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. :-)

Programming is definitely hard fun, and like music some people are very 
much drawn to it and overcome all the hardness without being that 
bothered.  That probably describes the majority of the open source 
community.  But most people don't pursue music that seriously, even 
given the opportunity -- hard fun isn't very fun for most people and for 
any particular domain.  I don't know if everyone has a hard fun that's 
right for them, or not.  I wish everyone had something, but 
unfortunately I suspect that enjoying hard fun is itself something that 
not everyone is prepared to do.

> 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.

you can't turn a new-style class into an old-style class by reassigning 
__class__, but otherwise you can mess with that attribute pretty freely 
(or mess with __class__.__bases__).   object() also happens to not 
accept attributes, though any subclass of object will.  I'm not sure 
what the justification is for that.

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

Yes, that's very common.  In general pickle-able objects can be 
recreated; you can do the same basic thing with the new module, like 
new.instance(Foo), and then update its __dict__ -- remembering that 
assigning to attributes might not work, since those attributes might be 
properties that expect the __init__ to have been called.

The object may register itself or do other things in __init__ as well, 
so it's really hard to be sure you are doing the right thing.

Really, it's all the same issues pickle has, and pickle also has some 
special methods so that most objects can be made pickleable.  Some 
things like open file objects just can't be pickled at all, ever -- 
though often you can make a pickleable wrapper that fulfills some more 
abstract purpose, and use pickle's hooks to keep from trying to pickle 
that objects entire __dict__ (which probably contains the unpickleable 
file object).

>> 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.

In part I want to avoid a disconnect between the two styles of 
development.  This was another problem with Zope -- people would start 
with the image/ZODB development, and then it was a really big leap to 
get to the file-based development.  So there was two classes of Zope 
users, and they didn't always understand each other.

Also, I don't want to have to recreate version control tools, or 
Python's module system, or the ability to share code freely, or any of 
that stuff.  I think a good way to avoid any problems with these tools 
and processes is to just stick to conventional program representations.


-- 
Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org