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.
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@dcorking.com | To: "The general-purpose Squeak developers list" squeak-dev@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. | |
On Sun, Jan 29, 2012 at 3:02 PM, David Corking lists@dcorking.com wrote:
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.
+1 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 ?
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.)
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.
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.
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.
Karl
David.
Karl Ramberg wrote:
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.
Wow! I didn't suspect that one cause of bitrot was so simple. SqueakSource is much easier to deal with than its Squeak predecessors, and it is easy to create a local or public clone where you can keep a sane set of patches until the project owner adopts them.
Is the problem perhaps the sequential nature of loading source into an image? (I may be doing it wrongly, but I often find I try deal with conflicts while a library loads, before I get a chance to fully grok it and figure out a sane way to resolve missing dependencies, name changes and so on. I may be much quicker than Karl to give up.)
Another 2p with a similar caveat. David
squeak-dev@lists.squeakfoundation.org
-
Dale Henrichs -
David Corking -
karl ramberg