2009/6/29 Bernhard Pieber <bernhard at pieber.com>:
> 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!
>
Let me illustrate another thing:
- making a little change in a big image
vs
- making a little change in an isolated module

when you doing first, how you can be sure that you didn't break
anything? by testing things which working with it?
But this is only for things, which is included in you fat image. Okay,
it may work. But can you be sure that your changes will work as well
for every existing package for squeak? No! So, its a controversial to
say , that ANY change in a fat image is backwards compatible. There is
no such thing.

Instead, if you changing something inside a module - you either making
changes in private areas, then it is guaranteed to be compatible with
any users of your module, or changing the protocols - then inevitably
the communication gets in a game and its your straight responsibility
to announce to all interesting parties what has changed and how they
could adopt to new version of your module, if they want to upgrade to
it.

> Peace,
> Bernhard
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.