Re: [Pharo-project] [squeak-dev] Forks, forks, forks

2009/7/2 Eliot Miranda <eliot.miranda@gmail.com>:

On Thu, Jul 2, 2009 at 12:06 AM, Ralph Johnson <johnson@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.

Yes, and all Squeak forks could use such kernel as a base, except those who making own changes to VM. This is another reason for having a package-based development model. I remember we have discussed this before, but this idea & especially benefits which it could bring to us, were leaked from my mind :) P.S. can't resist CC-ing this to Pharo list. :)

...

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

-- Best regards, Igor Stasenko AKA sig.