2009/7/2 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> 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.

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.