updates vs. images -- limiting squeak to code

Jonathan Kelly jonkelly at fastmail.fm
Sat Oct 15 03:51:53 UTC 2005


Disclaimer: This is very much a "from the side-lines" comment, as I've 
barely done more than dabble in smalltalk / squeak ...

Alan Grimes wrote:
> Michal wrote:
> 
>>So de facto, if you kill smooth upgrades (which is what we are talking
>>about), you come close to killing the use of squeak for non-code
>>objects. Modifying my initial reaction slightly: please don't kill
>>updating images, unless you have solved the issue of "easy transfer
>>[of] this stuff from image to image". (Though I suspect that when
>>you've solved that, you've also solved the initial problem about
>>upgrading code ;)
> 
> 
> mee tooo!
> 
> I still consider my 3.7 image to be my "workhorse" image because I
> havn't figured out how to migrate everything I was doing in it over to
> 3.8...
> 
> I have about half a dozen squeak images these days, each of thim has
> non-overlapping functionality. I was thinking of making a post to the
> list myself on this subject.

It's this very impression I had of sqeak that's holding me back from 
saying, "Yeah, I want to use smalltalk". It seems to me that part of the 
problem is that an image doesn't contain code, it's infected by it. I 
will admit I probably haven't got into the headspace yet, if there is a 
headspace, and there's obviously a lot I don't know, but I'm finding 
less and less reason to think using smalltalk for my next project (and 
it's a large project) is a good idea, if obviously very intelligent 
people have difficulty managing code and staying current. Maybe "staying 
current" is just another not so important mind set, but it's the one I 
have (and almost certainly one the client has) ... :)

This is just my impression of things, and just offered as potentially 
useful information to people who may be interested.

Cheers,
Jonathan.




More information about the Squeak-dev mailing list