[squeak-dev] alternate base libraries was Re: Smalltalk for small
lists at dcorking.com
Sun Jan 29 14:02:43 UTC 2012
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
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.
More information about the Squeak-dev