<br><br><div class="gmail_quote">On Sun, Jan 29, 2012 at 3:02 PM, David Corking <span dir="ltr"><<a href="mailto:lists@dcorking.com" target="_blank">lists@dcorking.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Mkobetic's piece is absolutely germane: any application in any<br>
language is an image, so a focus on Smalltalk's image is a distraction<br>
for those who don't want it. Also - any language also has a 4GB image<br>
limit in a 32-bit x86 system. Meanwhile, other devs and admins come to<br>
the idea of freeze-dried objects through VMware/VirtualBox or<br>
filesystem and DBMS snapshots: where they are seen as extra value,<br>
rather than harmful. To get the benefit of images, you don't need to<br>
be able to replay every transaction or instruction from bare metal,<br>
just from a known stable state.<br></blockquote><div><br></div><div>+1 </div><div>To me it seems backwards to ditch the live objects in the image in favor of versioning source code. What is it about the live objects that can't be trusted and brougth to a sane state ? Why must the system be rebuilt from a tiny core ? </div>
<div><br></div><div>As you say, virtual images are becomming more used today because it's to time consuming to rebuild the system for every change. Most bigger systems try to emulate a image to save users time to get back to a known state. (Windows uses system restore points and Mac TimeMachine.)</div>
<div><br></div><div>Most of the time developing I want better tools to inspect the state of the system and work with the live objects rather than abandon a image and restarting. </div><div><br></div><div><br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, I would like to pick a bone with Dale's suggestion, if he<br>
will permit me. He said:<br>
<br>
> when you have a micro-image as a starting point it is much easier to consider and<br>
> use alternate base library implementations which in turns make it easier to<br>
> move the language forward<br>
<br>
I am uncomfortable with this, as the Pharo/Squeak experience suggests<br>
that most libraries that have been pulled out of the image and stored<br>
in Monticello (or its predecessors) to allow experimentation have<br>
suffered quickly from bitrot. I suggest that the bitrot has not been<br>
due to the development process, as it is quite easy to automate<br>
reintegration into release or trunk images, but instead that the<br>
Smalltalk community, at least the community of open source developers<br>
of the main images, is just too small .<br>
<br>
Seaside, which runs in so many different Smalltalks, has been a<br>
success story, but my fear is that it may be the exception that proves<br>
the rule: it has a community of dedicated developers that makes sure<br>
that the entire library always compiles and runs on every release of<br>
Pharo, Squeak, VW and Gemstone.<br>
<br>
It is true that things inside the image also suffered bitrot: for some<br>
there is a good reason for a loss of interest, and for others I think<br>
the small size and huge creative energy of the community may be the<br>
cause.<br>
<br>
However, I don't think that in general that the community is big<br>
enough to support much language experimentation by this route. It<br>
seems to me that experiments like STEPS, Newspeak, Self, Strongtalk,<br>
Croquet and closure support have worked without a widespread diversity<br>
of base libraries in the rest of the developer community.<br>
<br>
As far as I can tell, and I may be wrong, even the vast C and Java<br>
communities don't have a vast diversity of important libraries that<br>
they experiment with: on the contrary, migrations say from libc to<br>
libc2 or AWT to Swing need careful management. Libraries that don't<br>
get the support of the big vendors die all the time.<br>
<br>
Just my 2p from my observations of community dynamics, as you know<br>
that I don't have a deep personal investment in any of the libraries,<br>
even my favourite Morphic/Etoys.<br>
<span><font color="#888888"><br></font></span></blockquote><div><br></div><div>I agree on most of this. It's hard enough to bring in stuff from Squeak Source but to keep code up to date on current images is painful. Especially if you don't own and can commit code to the Squeak Source project. I sadly often give up on using code because of that. </div>
<div><br></div><div>Karl</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888">
David.<br>
<br>
</font></span></blockquote></div><br>