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

Igor Stasenko siguctua at gmail.com
Mon Jun 29 01:03:51 UTC 2009


2009/6/29 Igor Stasenko <siguctua at gmail.com>:
> 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.
>

So, i wonder, what you found so repulsive in Pharo's statement,
proclaiming that they are not backwards compatible.
Neither kitchen-lovers do.

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



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list