David,

You have good points,... bitrot happens ... libraries that are continuously used and maintained don't suffer bitrot. The larger the library the higher the likelihood that there are pockets of bitrot, no matter how popular ... So, I think that it is a worthwhile goal to attempt to achieve as small a base-image as is practical to keep bitrot in the core to a minimum... 

No question that resources have to be balanced .... I'm not advocating a wholesale commitment to creating a micro-image within the next 6 months:)...I do think that allocating some resources in that direction is a good thing and will have synergistic benefits.

The discipline involved in maintaining a modular system benefits the overall quality of the code. You mention Seaside and I think it's true that the commitment to making Seaside portable and modular has helped to keep the quality of the code high ... So it follows that applying that same discipline to the development tools and the core libraries would result in improved quality and creativity...

I imagine that NewSpeak development would have benefited from a migro-image, but maybe not ... Often Smalltalk-based language experiments alo involve vm changes so a micro-image isn't necessarily the only issue.

Dale

----- Original Message -----
| From: "David Corking" <lists at dcorking.com>
| To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Sent: Sunday, January 29, 2012 6:02:43 AM
| Subject: [squeak-dev] alternate base libraries was Re: Smalltalk for small	projects only?
| 
| Mkobetic's piece is absolutely germane: any application in any
| language is an image, so a focus on Smalltalk's image is a
| distraction
| for those who don't want it. Also - any language also has a 4GB image
| limit in a 32-bit x86 system. Meanwhile, other devs and admins come
| to
| the idea of freeze-dried objects through VMware/VirtualBox or
| filesystem and DBMS snapshots: where they are seen as extra value,
| rather than harmful. To get the benefit of images, you don't need to
| be able to replay every transaction or instruction from bare metal,
| just from a known stable state.
| 
| However, I would like to pick a bone with Dale's suggestion, if he
| will permit me. He said:
| 
| > when you have a micro-image as a starting point it is much easier
| > to consider and
| > use alternate base library implementations which in turns make it
| > easier to
| > move the language forward
| 
| I am uncomfortable with this, as the Pharo/Squeak experience suggests
| that most libraries that have been pulled out of the image and stored
| in Monticello (or its predecessors) to allow experimentation have
| suffered quickly from bitrot. I suggest that the bitrot has not been
| due to the development process, as it is quite easy to automate
| reintegration into release or trunk images, but instead that the
| Smalltalk community, at least the community of open source developers
| of the main images, is just too small .
| 
| Seaside, which runs in so many different Smalltalks, has been a
| success story, but my fear is that it may be the exception that
| proves
| the rule: it has a community of dedicated developers that makes sure
| that the entire library always compiles and runs on every release of
| Pharo, Squeak, VW and Gemstone.
| 
| It is true that things inside the image also suffered bitrot: for
| some
| there is a good reason for a loss of interest, and for others I think
| the small size and huge creative energy of the community may be the
| cause.
| 
| However, I don't think that in general that the community is big
| enough to support much language experimentation by this route. It
| seems to me that experiments like STEPS, Newspeak, Self, Strongtalk,
| Croquet and closure support have worked without a widespread
| diversity
| of base libraries in the rest of the developer community.
| 
| As far as I can tell, and I may be wrong, even the vast C and Java
| communities don't have a vast diversity of important libraries that
| they experiment with: on the contrary, migrations say from libc to
| libc2 or AWT to Swing need careful management. Libraries that don't
| get the support of the big vendors die all the time.
| 
| Just my 2p from my observations of community dynamics, as you know
| that I don't have a deep personal investment in any of the libraries,
| even my favourite Morphic/Etoys.
| 
| David.
| 
|