[squeak-dev] Re: What is Forking Squeak

Igor Stasenko siguctua at gmail.com
Wed Dec 10 00:53:52 UTC 2008


2008/12/10 Hilaire Fernandes <hilaire at ofset.org>:
> Where I found Squeak is dramatically failing is at the core level.
> The list you have been writing is from projects at the periphery of Squeak.
> All those project are forks of Squeak, and each fork is the symptom of a
> difficulty for cooperation at the core level. I don't know why, I just see
> as all of you the symptom.
>
> The result is diluted energy, duplication of effort, incompatibilities, all
> the badness you got from fork.
>
> Try to imagine each Python based projects as a Python fork, you will hardly
> saw that as proof of success. More like a proof of failure.
>
> I think most of the problem come from the legacy of Squeak. Was Squeak
> designed to be a plate forme to develop on top of it other software? I don't
> think so. More like a great toy but it hardly scales when you want to do
> serious things. Then of course the complete lack of leadership in the
>  Squeak community does not help to aggregate...
>
> Frankly I am suprised Squeak is still alive, is it? But in fact it does not
> matter as there are many forks out there.
>
>

+1 :)

That's why i think 3.11 team does right job.
We don't need just a yet-another-prebuilt-image, because it again will
lead to another fork (for those who don't see it - look at 3.8-3.10
fate).
We need tools for building images and integrate fixes/new/custom stuff easily.

Also, i think we should focus on making easy to plug-in / easy to
plug-out code with a little restriction(s) on kernel.
While its easy to say, hard to do - people who tried to refactor a
code to remove some global from use know what i mean. :)
I dreaming, to have image where i can load a compiler into image as
separate package, same for morphic & other stuff.


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list