[Cuis-dev] Why not to save the image?

[Vanessa Freudenberg]

It's a question of HOW you are using Smalltalk:

* if you are primarily using it as a Personal Computing Environment, then
saving the image is the way to go. I've used my main Squeak image for many
many years, including regularly fetching system updates (and having backups
of that image in case I need to backtrack out of too-hard-to-fix
situations).
* if you are primarily using it to write source code to share with others,
starting from a fresh image regularly is a fine choice.

I personally used my heavily customized image even for collaborating with
others. Monticello makes that reasonable (I had a good amount of
"*codefrau-override" methods in my system which let me keep modified
methods even while being able to publish updates to these "dirty"
packages). That does require keeping in mind those differences though.
Working in a clean image certainly has less room for accidentally
publishing stuff that shouldn't be published.

Vanessa

On Wed, Aug 2, 2023 at 10:03 AM Ezequiel Birman via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> This is the sort of conversation I´d love to see as marginal comments when
> reading that particular paragraph in The Cuis Book.
>
> Please have a look at https://web.hypothes.is/ for something that is
> production ready and that could serve as a starting point.
>
> --
> Eze
>
> El mié, 2 ago 2023 a la(s) 14:50, ken.dickey--- via Cuis-dev (
> cuis-dev at lists.cuis.st) escribió:
>
>> On 2023-08-02 01:22, Szabolcs Komáromi via Cuis-dev wrote:
>>
>> > I just wondered whether something peculiar to Cuis warrants this
>> > definitive statement. But as turned out the book has a strong implicit
>> > engineering perspective and saving the image doesn't have any hidden
>> > side effect compared to the other Smalltalk implementations. Hilaire
>> > added my comment to the end of the code management chapter of  The Cuis
>> > Book. Hopefully this makes the validated but implicit engineering
>> > standpoint of the book more explicit for future readers.
>>
>> The experience of using image based languages (Smalltalk, Actor, ..) is
>> that the ability to save and reuse an image, over time, leads to cases
>> where one cannot reproduce a system from source.  This is bad for
>> sharing and bad for commercial products, where source control is
>> important to maintaining an investment.
>>
>> In one project I was working on, I noticed development images getting
>> out of sync and people "debugging" to find image differences.  This
>> despite source control.  The fix was to disable saving images!  People
>> hated me for about a week for doing this, but realized that starting
>> from versioned sources and a fresh image each day meant that they really
>> did save their work each day to the version control system and it saved
>> us, as a group, much time.
>>
>> This became especially important when we trained up a sibling team in
>> Taiwan.  Each day we saved our stuff in the US and wrote up what needed
>> to be done next.  The Taiwan team worked during our night do do that and
>> the next morning that stuff was magically done and we had another
>> chunk/step to work on.  Distributed development can work essentially
>> 24/7 if you have good communication and can prime the pump.
>>
>> This particular project was done in Actor -- basically a Smalltalk IDE
>> but with C syntax -- no relation to Actor Semantics.
>>
>> My experience is that image save based development leads to accidents of
>> history -- times when one ends up with images which may work but are not
>> easily reproducible from source.  One way to avoid the problem is to get
>> in the habit of _always_ reproducing from source.
>>
>> Like eating well and exercising.  You can have a milkshake once in a
>> while, but have one with every meal you are in trouble.
>>
>> Best to establish and keep good habits.
>>
>> $0.02,
>> -KenD
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230802/2abec132/attachment.htm>