[squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean)

Bernhard Pieber bernhard at pieber.com
Mon Jun 29 00:03:36 UTC 2009


Hi Igor,

First of all: Thanks for taking so much time discussing with me. I get  
the feeling that somehow my point of view is frustrating you. That is  
not my intention.

Am 29.06.2009 um 01:01 schrieb Igor Stasenko:
> I don't know how you quoted my mail, but gogle thinks its not quoted .
> So its became unsorted.
Sorry about that. I am using Apple Mail.

>> 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.
I concede that some of the maintainers may well have been too  
optimistic. Well yes, I can remember the situation. I did a small  
refactoring once and the code was let's say quite in need of  
refactoring. Maybe I even broke something, however I tried hard not to.

>> 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.
I agree it is more work. Maybe even much more work. Terribly  
frustrating. However, impossible? No!

> And again, where do you find so dedicated people, who will spend
> hundreds of hours trying to improve the code?
Good question. Let's say someone is willing to spend 100 hours. If he  
spends the same 100 hours caring about backwards-compatibility he is  
much slower. I agree. On the other hand he might keep a contributor or  
better yet win one because one cool feature still works. I concede  
that it is difficult to assess that tradeoff. We definitely seem to  
have very different feelings about which factor is bigger.

> 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 totally agree here. And I not at all against refactoring. Quite to  
the contrary!

> 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.
I do care! I have very, very high quality standards! Relly! Ask my  
collegues! ;-)

> 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.
Some may have criticised those unfairly so that one might say they  
were "burned as heretic". I must say, I don't think such exaggerations  
are helpful. But please concede that I have not done that! On the  
contrary, I wrote:
>> 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.

> 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.
I am afraid you did not convince me. I do think that maintaining a  
full image is better. However, I feel there is still a  
misunderstanding. That full image should consist of well defined  
modules. I don't think those two things are necessarily contradictory.  
However, thanks again for bearing with me!

Peace,
Bernhard




More information about the Squeak-dev mailing list