Convincing a harvester (was on SqF list)

Tim Rowledge tim at sumeru.stanford.edu
Mon May 5 23:32:01 UTC 2003


I almost completely agree with Andreas here.
> 
> <OT>
> I need to warn you about this. I've been thinking for a while now about the
> effects of having "everything easily loadable" but nothing actually in a
> release image. I strongly believe that the effect of this will be an
> arbitrary number of forks within a couple of months. Minimalism is not why
> people buy into Squeak - it's because Squeak is a _rich_ environment. At the
> point where Squeak itself is an empty shell various people will make up
> their own versions and introduce their own idiosynchracies. If any (worse:
> more than one) of those is widely accepted it is effectively a fork. If it
> isn't, I'd expect that we'll loose a lot of potential users as they would
> then see Squeak as "just another development environment" which it really
> isn't.
> </OT>
...But this bit I think I can put a better face on. I believe that we
are anticipating having a set of prebuilt images for each release (in as
much as that makes sense) so that there is a very-nearly empty kernel,
then a fuller typical developer image made by loading a bunch of
packages and then the 'normal' image made by loading all the packages
that represent pretty much today's image. This _should_ provide both a
usseful system for people playing with tiny systems and for 'normal'
people. It will of course also allow the possibility ofa quite variant
fork being built.

> * RegExp
I'm sucking the plugin code into the latest VM code package so this
should be standard in the vms soon
> 
> * Closure primitive support
Likewise; at least some more serious experiments can then be done by
peopl that don't have the inclination ortime to build a new vm.

> * BMPWriterPlugin
Likewise

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
I just found the last bu



More information about the Squeak-dev mailing list