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

Dmitry Dorofeev dima-sender-3c337a at yasp.com
Wed Sep 7 16:42:22 CEST 2005



radoslav hodnicak wrote:
> 
> 
> On Wed, 7 Sep 2005 seaside at fbeausoleil.ftml.net wrote:
> 
>> Hi !
>>
>> radoslav hodnicak said the following on 2005-09-06 19:40:
>>
>>> Loading postgres client 0.9.2 into clean image and then glorp 0.3.138 
>>
>> *should* work, I tested it.
>>
>>
>> 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 ?
> 
> 
> ...
> 
> that's not what I'm saying. Loading into clean image is just the process 
> of eliminating other factors that might lead to failure. If it doesn't 
> work after loading into clean image, then it's a problem for me (I'm the 
> glorp port maintainer). You don't need to delete your work to get other 
> parts working, although sometime you might have conflicting changes when 
> it comes to system classes.
> 
> 
>> 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.
> 
> 
> This question comes up every so often, and indeed images are strange 
> concept to many people who look at smalltalk for the first time. 
> However, you just have to realize that no matter what programming 
> laguage you use, at some point you end up with parts of memory where 
> your data and code resides.
> 
> Consider writing program in C. You write it, compile it, link it and end 
> up with binary file that is then loaded into memory by operating system. 
> It is sort-of like smalltalk image, with the difference that it's one 
> way - from disk to memory.
> 
> In smalltalk, interactivity and direct access to everything is the 
> "prime directive". That's why you can change the memory image with 
> normal tools (this includes loading or creating new code), that's why 
> you can inspect and view everything in it, that's why you can save it 
> back to disk and restore later.
> 
> I suspect one could always build a new image from files and throw it 
> away at exit. But I think it would lead to similar "object blindness" 
> java/c++/... programmers develop, because for them objects are just some 
> lines in header files. They never had their objects under microscope in 
> inspectors, telling them what to do, watching them change and yelling at 
> them when something didn't work out as planned :-)
> 

And I can express the same idea from different point of view.
It is possible to look at Smalltalk environment as at OS running on your computer.

Clean image = power on your box and INSTALL OS. This is kinda clean image! and ready to install
and run new programs. In Smalltalk you create classes and objects, so you can 'run' them.
It is quite stupid to install OS every time you need to add new program. But Windows
tend to be broken if you install/deinstall a lot of software frequently. 
Same is with Smalltalk image. Untested package may break your OS or image. 


Now modern OSes (and laptops) has option to save the full state of the 'image' to HDD. 
Seems like it is named hybernate in Windows. It is exactly what Smalltalk do. And i never heard users
uncomfortable with hybernate. But programmers still curious about 'image' concept :-)

On a server side i found 'image' concept a natural thing. Services are running nonstop, in
the same way as Smalltalk image. If i need to shut it down, fine. I can start from a point
a stopped it at. I call it start and go! Also it is quite comfortable to come in the morning,
load your image and see your debugging session right in the state it was last night. IDE for
C/Perl/Java etc only mimic features which Smalltalk provides due to image concept.

-Dmitry.


More information about the Seaside mailing list