On Thu, Jul 2, 2009 at 12:06 AM, Ralph Johnson <johnson at cs.uiuc.edu> wrote:

> The tendency to fork is a product of all Smalltalks, not just Squeak.


as others have observed in the current spate of discussion the need to fork
can be minimised or avoided altogether by providing a small kernel image
that can load packages, and getting into the habit of writing one's
application as a set of packages and regularly building them up into an
image (nightly, weekly) starting from the kernel.

This approach also allows the VM and image representation to evolve (and
even fork!) because the kernel is amenable to transformation.  So one can
create different forms of the kernel image with exactly the same apparent
image contents, but with object representations adapted for specific uses,
such as an extremely compact representation for embedded applications and a
simple one for performance and normal development, and one can have purely
interpreted VMs for hostile or memory-limited machines (iPhone does not
allow one to enable execution permission on mmap'ed memory) and JITs
for performance and normal development.

IMO it is also easier building up a kernel than carving it out of a
monolithic image to architect the necessary modularity support to allow
packages to be loaded that make major transformations such as adding a GUI
and replacing a standard i/o stack dump with an interactive debugger.

I hope that if such a beast becomes available that the community will make
the effort to port to it, which involves packaging their code, and we can
branch to our heart's content because images will be constructed not
constricting.

There is a company in town that developed a commercial product on
> VisualWorks 2.0.   They customized it heavily.  It is a sound
> generater, in fact the world's fastest synthesizer in which you can
> specify each waveform.  It is used by musicians and for sound effects
> in movies.  All the programming is done by two people.  It provide a
> very nice UI in which you drag and drop sound objects to create your
> piece.  When you say "play", the sound objects are converted into code
> for an array of DSPs, which execute the code to play the sounds.  The
> process is nearly instantaneous.
>
> This company made a fork over ten years ago, and last I heard, had not
> caught up.  They would like to run their software on Unix.  It only
> runs on PC and Macs, and I think they have hacked the VM themselves to
> run on newer OSs.  The binary, that is.  But it was just too much
> trouble to convert their image, and didn't seem like it provided
> enough benefits.
>
> There are still a lot of companies running VSE applications in spite
> of the fact that it hasn't been supported for a decade.
>
> One of the great things about Smalltalk is that it is so open.  You
> can change everything about it; the way the compiler works, the UI,
> the programming environment tools, what it means to send a message to
> an object that is not understood.  You can change arrays, strings,
> booleans.  Of course, if you do this then you are not longer
> compatible.  If you hack Behavior and ClassDescription then the odds
> are that your hacks will not be compatible with other people's hacks.
> Every time a new version of the platform comes out, you'll have to go
> back and make sure none of your hacks are broken.  Often they will be.
>
> Sometimes it is worth the pain.  But often people just fork.  They
> will lose all the nifty new features that come out, but it just isn't
> worth the trouble to keep up.
>
> I think the reason there is so much forking with Smalltalk is that
> application programmers don't have to depend on vendors.  They can
> craft the environment to suit their own needs, and don't need to
> depend on someone who doesn't really understand their needs.  There
> are disadvantages to forking, but it is easy and there are enough
> advantages that people will continue to do it.
>
> So, we need to learn to live in a world of forks.  Seaside shows how
> it can be done.  Squeak and VisualWorks, after all, are different
> forks from the original Xerox Smalltalk-80.
>
> -Ralph Johnson
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090702/d72cac5e/attachment.htm