[Tutor] Modifying Source Code while Program is Running

Ed Singleton singletoned at gmail.com
Sat Nov 26 11:38:30 CET 2005

On 25/11/05, Alan Gauld <alan.gauld at freenet.co.uk> wrote:
> > Just had a quick look at Smalltalk, and at first glance the overview
> > of the ideas behind it seems amazing, but the language seems quite
> > ugly, and it seems to be very IDE led.
> Adherents will defend its simplicity but I confess I strugglred for
> a long time with SmallTalk before learning to love it :-) And yes
> it is IDE led although the IDE can be 'removed' when deploying
> applications. But much depends on the implementation, my favourite
> for PCs is Dolphin SmallTalk from ObjectArts. Its not a traditional
> SmallTalk (ala Xerox SmallTalk 80) but very much one for the '90's

I'm definitely going to investigate it further, as it does seem
interesting, but I remember the first time I looked into Python, I
read the tutorial and was quite bemused as it didn't seem like I'd
learned anything.  It was all so obvious that I didn't feel there was
anything to learn.

As it was I was able to very quickly plunge much deeper and end up
asking lots of difficult questions that in any other language you
wouldn't approach for many years.

> > This immediately seemed to me to be a case for classes.
> > You provide a way for a user to create a new class by
> > subclassing the page class (from their point of view
> > probably through adding a few new fields to
> > a form).
> That might be part of the problem, if you think of a class in terms
> of its data attributes then that is nearly always the wrong starting
> point. Classes express behaviour, the data is only there to support
> the behaviour. Thats why methods are polymorphic but not attributes.

If classes express behaviour, then what expresses the structure of the
data?  (ie what attributes there are going to be and what values they
are likely to accept).

You need (the option of) a data definition in order to generalise. 
Using my web server example from earlier, you need to be able to say
that for any type of page, whatever it's attributes, you can create a
web form to search for that type of page by iterating through it's
attributes and creating a relevant form field for each type.

> So you think of a class having an interface and users extending
> or modifying the behaviour, not the data. If you follow that route
> you might find you don't need to write self modifying code,
> you simply load new classes with a common interface into an
> existing hook structure.

I definitely had the opposite in mind.  The behaviours of all the
classes would be the same (and would be fairly simple, a method for
rendering the page with a template, a method to update the data based
on a form submission).  Users would basically be able to change the
data structure (add and remove attributes).

> > However it doesn't really seem that Python is suited to this.  Indeed
> > it doesn't really seem that Python is suited to a persistent
> > environment.
> What makes you think that? Most persistent environments
> (ie long running server processs) are written in C/C++ (or
> maybe Java nowadays) which are far less dynamic than Python.

I'm sure Python is quite possibly the least worst at this, but that
doesn't make it good at it.

> > Having a program running for a long time (months) is
> > possible certainly, but it seems to be fighting against the language
> Not at all, at least no more than in languages like C which require
> recoding, recompiling, stopping and then restarting the server to
> make changes. Thats why a simple framework with loadable
> modules it usally preferred to self modifying code!

Again, I'm sure it is better than C, but I definitely have had the
feeling that this is not something the language was designed for, and
that not many other people seem to be trying it.


More information about the Tutor mailing list