[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
|