I don't know how you quoted my mail, but gogle thinks its not quoted .
So its became unsorted.

2009/6/29 Bernhard Pieber <bernhard at pieber.com>:
> Am 28.06.2009 um 23:09 schrieb Igor Stasenko:
>
> 2009/6/28 Bernhard Pieber <bernhard at pieber.com>:
>
> I agree with what Juan and K. K. Subramaniam wrote. Squeak needs a goal, a
>
> statement what it is supposed to be. One thing I miss from the old days is
>
> the kitchen sink image. Neither Etoys nor Pharo have the goal for delivering
>
> such an image. So that could be a good raison d'être: Show what can be done
>
> with Squeak, and show what is done with Squeak. Something inclusive, a place
>
> for showing off all the cool, interesting, blue plane stuff, which is
>
> possible with such a dynamic environment. This attracted me to Squeak in the
>
> first place, and I think it still has the potential to attract newcomers.
>
> I miss Connectors, MathMorphs, Alice, Games, ThingLab, Genie, Nebraska and
>
> all the other cool things that were once. But maybe it's just me. ;-)
>
> I'd like to ask, where those people who care maintaining these bits ,
> making them available for new squeak versions, improving them, adding
> new features and so on?
>
> If there none of them, then how do you think, why is that? And why
> people, who does not interested in this stuff at first place, must do
> anything to maintain it? Do they have nothing else to do?
>
---
> Maybe some of them were not interested in maintaining it further because
> someone else broke their code for no good reason from their point of view?
>

or maybe because they were too optimistic about that once their stuff
have been included once in the bloated image, they don't need to
support it anymore.
Now imagine the situation: each time you want to improve something, or
change it radically , you deemed to be too cautious about that,
because there are tons of things, which using this stuff, monkey
patching different parts of it, up to the point that there is
impossible to find out , where ends a basic interface and where starts
the custom extensions, added by different little-toy projects over a
years of bloated image existance.

> That's why i am totally agree with Pharo vision on that: they don't
> want unmaintained stuff in Pharo, that's why one of the Pharo
> milestones is to clean the Morphic from Etoys and other unmaintained
> stuff.
>
> Etoys is all but unmaintained. And Juan has tried to maintain Morphic as far
> as I know.
>
> And i share their approach on that: if you want your stuff to be able
> to work with base image, then provide a script/package/loader , or
> whatever is needed to load it into basic image and maintain it. If
> your package can't be loaded w/o errors, then it is your problems, not
> the problems of people who developed core image.
>
----
> I don't agree at all that that was a wise move. I think Squeak lost a lot of
> existing and potential contributors by saying: "If you want your code to
> continue to work in Squeak, you have to constantly adapt to our changes." I
> think that is what Stéphane Rollandin was trying to tell us. I am convinced
> that the separation of the base and the full image and the concentration on
> the base instead of the full image was the reason why forks were inevitable.
> Starting refactoring was necessary and a very important service for the
> community, but it had to have been done in the full image! My argument is
> basically that of Wolfgang Eder from July 2006:
> http://www.nabble.com/Proposal-for-a-Squeak-migration-meeting-ts4867570i120.html#a5260913
> That is still a very relevant thread today, by the way.
>

See my above part, why i think that refactoring a bloated image isn't
possible, not saying that its very error prone.
And again, where do you find so dedicated people, who will spend
hundreds of hours trying to improve the code?
Take a look at Morphic, to what state it was progressed. Tons of
methods (over 600 methods in Morph class).
Do you really think that we need all of them in most basic class? I
doubt that. It is a bloat, certainly.
If class requires so many methods, maybe its worth splitting it on
number of smaller ones? But who i am to teach you programming.

I can tell you what is happening , when no-one cares about maintaining
things separately, in good share: people is LAZY and tend instead of
learning, how things can be done by reusing the existing code, putting
own extensions to existing code, and in result we got classes with
over 600 methods. And no-one cares. But when someone raises a head and
trying to say, lets wipe it up - he get burned as heretic, because it
will break the holy backwards compatibility grail.
If those words didn't convinced you that maintaining & developing a
bloated images, instead of separate, well defined modules is road to
void, then nothing else can.

> Isn't that made clear to anyone these days: a days of bloated images
> which includes everything and where everything is working is passed.
>
> Obviously, it is not clear to me. ;-) Seriously, I have thought a lot about
> it and I am convinced that the kitchen sink image was Squeak's main
> attraction. The moment we lost it we started losing contributors.
>
> Because there are people who need to deploy stuff on server (to run
> Seaside or Wiki, or other services), and if you put bloated stuff
> there, and try to scale, the people around will start asking, why it
> consumes so much resources?
>
> Note, that I am not saying that the kitchen sink image could or should not
> be put together from a small image and nicely modularized packages. What I
> am saying is that if you clean up only the base image you will never be able
> to put together the full image because I guess many of the maintainers will
> not bother to repair stuff others broke. Worse yet, they probably will not
> bother anymore to create more cool stuff.
> See, I can follow your reasoning. And it sounds very convincing. Therefore,
> I am not blaming anyone for going that route. I am totally sure everyone had
> only the best intentions. Nevertheless I am totally convinced it was a
> really bad idea and it still is, because that way you lose contributions and
> contributors.
> Cheers,
> Bernhard
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.