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

[Ramon Leon]

> 
> You see, that's what I never liked about working with images. 
>  Maybe I'm 
> just old school, but if I have two or three projects going on in my 
> image, should I just delete my work just to get some other 
> part working ?

I'm not sure what others do, but as a squeak newbie myself, I've taken
to setting up a clean development image with all my usual libraries
installed as a baseline (Seaside2, SeasideAsync, ExternalWebBrowser,
LookEnhancements, Magritte, Mewa, Monticello, ODBC, Shout,
ShoutMonticello, ShoutWorkspace, SmallWiki2, KeyBinder,
Win32NativeFonts).  I never do work in this image, it's a starting
point.  So when I start a new project, I fire up that clean image, do a
save as to another name, and start working from there.  Makes it pretty
simple to scrap a blown image and start over with a known working
configuration.  Maybe there's a better way to do this, but I haven't
found it yet.

> 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 image isn't really comparable to files.  Files hold source code,
that's what the sources and changes file is, your source code, but the
image is essentially a serialized file of the current contents of
memory, the running program.  That means you could be in the middle of a
debugging session, save and quite the image, toss it on a keychain
drive, take it home and fire it up on another computer, even another
platform, and continue debugging exactly as if the program had never
stopped.  Files have no equivalent, and the image if freaking cool, way
cool.

It's better because when you create an object, it's just there, it'll
live as long as there's a reference to it and you don't need to think
about how to persist it, which means you can write your entire program
and get it working without thinking too much about persistence at all.
The image allows the illusion of infinite memory.  

I still program as if there were a backend database, using repositories
to hold my objects, which I keep as a variable on the class side. So I
could say something like: somePeople = Person repository
findByEmail('joe at bob.com').  This repository just keeps the people in a
dictionary or ordered collection or something, but when the need arises
later, you can swap it out for a real repository that persists to a real
database, after your program is working, and that's the real advantage
of the image, it lets you concentrate on the program and its behavior
rather than on the database until the last possible moment, hopefully
after the program itself has stabilized a bit and stopped evolving so
fast that the database would hinder development.  To sum it up simply,
the image lets you program really really really fast, database on the
other hand, slow you down, a lot.