[Seaside] [OT] Why use an image file ? (was Re: Seaside & Ruby Rails Compared)

Tony Garnock-Jones tonyg at lshift.net
Thu Sep 8 13:14:38 CEST 2005


seaside at fbeausoleil.ftml.net wrote:
> Please, I don't want to offend anyone !  I understand the concept behind 
> the image, and I *really* want to like Smalltalk, but the image thing 
> has stopped me every time.  What I probably need are references as to 
> *why* it is considered better to use an image instead of plain old files.

The problem is not the image, it is a problem to do with naming called 
the problem of "ambient authority". Classes, global variables, and state 
are all addressed by a flat namespace, and the names are not 
well-chosen. The same problem is suffered in Java, although to a lesser 
degree, even though their naming scheme is hierarchical, because class 
equivalence is based on class names.

A modular smalltalk, where names for objects were just mnemonics for the 
benefit of the programmer (the real "name" for a class might be a GUID, 
or might even be based on its structure - leading to a structural 
equivalence relation between classes, rather than a nominal one...), 
would go a long way toward solving these problems.

Separate modules (or even separate *versions* of the same module) could 
be isolated from each other to prevent interference, or could be 
introduced to each other to allow collaboration. At the moment there is 
no choice: all code and objects in the image are visible to all other 
code and objects, via global variables. If a new version of a module is 
loaded, it replaces the old one, even if it's slightly incompatible.

So what's going on is that the image-based nature of Smalltalk is 
exposing a deeper problem of naming, which is present in most other 
programming systems too, but which is usually obscured by shallower 
problems which take up everybody's attention.

I guess with the notion of the image, Smalltalk has solved the problems 
that take up so much of programmer time today, and lets them concentrate 
on harder problems that programmers in lesser systems haven't even 
really begun to notice yet :-)

Another way of looking at it is that Smalltalk has no notion of process 
isolation, which "real operating systems" have had since almost the year 
dot, and that it's suffering for it in the same way DOS suffered for its 
lack of process isolation. Remember TSRs? The problems we had with those 
are exactly the problems plaguing current Smalltalk systems.

Tony
-- 
  [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
    [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
  []  [] http://www.lshift.net/ | Email: tonyg at lshift.net


More information about the Seaside mailing list