[squeak-dev] Forks, forks, forks

Ralph Johnson johnson at cs.uiuc.edu
Thu Jul 2 07:06:46 UTC 2009


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

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



More information about the Squeak-dev mailing list