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

> Am 28.06.2009 um 23:09 schrieb Igor Stasenko:
>
> 2009/6/28 Bernhard Pieber <[hidden email]>:
>
> 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?
>

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

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

> 2009/6/29 Bernhard Pieber <[hidden email]>:
>> Am 28.06.2009 um 23:09 schrieb Igor Stasenko
>>
>> 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.
>

> On Mon, 29 Jun 2009 00:34:50 +0200, Bernhard Pieber wrote:
>> I tried to explain in my response to Igor that I think the opposite  
>> is true. We lost a lot of people because we did not value their  
>> contributions to the full image enough.
>>
>> Peace ;-),
> Sure (peace ;) so we have lost for contradicting reasons, as well.  
> Okay then, now wearing my project manger hat:
>
> and now?

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

>
>>
>> Earlier someone wrote a nice list of packages that aren't working
>> anymore... many of these packages weren't replaced. Worse: many
>> packages appear in Universes (for instance) but cannot be loaded
>> (example: try to load Monticello 1.6 and you'll have an infinite loop
>> while trying to load Monticello 1.5. Then you may ask: what you want
>> Monticello 1.6 for? Like for installing Balloon3D from Universes ???
>> But then B3D is broken too...at least in Scheduler...).
> Which is why there is a [hidden email] to discuss
> these very same issues.
>
> If you dont tell anyone you have a problem, then how can you expect it
> to be fixed?
>

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

> 2009/6/29 Bernhard Pieber <[hidden email]>:
>> 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.
>

> 2009/6/28 Göran Krampe <[hidden email]>:
>> Possibly true, but Smalltalk, Squeak, Etoys and even Croquet have been
>> around for quite some time now - and we haven't seen any real explosion yet.
>> Croquet was meant to "explode" but hasn't. So I am not holding my breath for
>> "the day Squeak gets popular" :)
>
> Sometimes being popular means doing normal things. Smalltalk is an
> unusual programming language (in the sense of mainstream) with an
> overly eccentric environment in Squeak. Then there are Croquet, Etoys,
> and so on. It's hardly a break through if it's only "more" eccentric
> than eccentric. Don't you think?
>
> The look-and-feel is designed for children. It's colourful, joyful, it
> bleeps and blink. How many professional developers are children? How
> many children are on this list? Enough with that already! Can we have
> a normal look-and-feel? A professional look-and-feel. =)

>
> Squeak is stuck in some time warp, where the surrounding world is on
> stand still. It should however consider that we are living in 2009 and
> have needs of 2009. We need a different usability, developer tools and
> we have different goals. For example, Squeak hardly support the
> requirements of my distributors, which makes it overly challenging for
> me to consider Squeak as our platform of development.
>
> Squeak doesn't need a killer app. It needs to be spruced up and put
> back on track. Honey moon is over, it's time to get real.
>
> Regards,
> Ian.
>
> --
> http://mecenia.blogspot.com/
>
>

> Em 28-06-2009 21:34, Keith Hodges escreveu:
>>> Earlier someone wrote a nice list of packages that aren't working
>>> anymore... many of these packages weren't replaced. Worse: many
>>> packages appear in Universes (for instance) but cannot be loaded
>>> (example: try to load Monticello 1.6 and you'll have an infinite loop
>>> while trying to load Monticello 1.5. Then you may ask: what you want
>>> Monticello 1.6 for? Like for installing Balloon3D from Universes ???
>>> But then B3D is broken too...at least in Scheduler...).
>>>    
>> Which is why there is a [hidden email] to discuss
>> these very same issues.
>>  
> Excuse-me. Perhaps I informed in the wrong list (remember posting it
> here about some months ago)...
>> If you dont tell anyone you have a problem, then how can you expect it
>> to be fixed?
>>
>> Keith
>>
>>    

> Em 28-06-2009 21:40, Igor Stasenko escreveu:
>
> (...)
>
> Automagically by you, since you currently a release team member and
> must pay attention to every bit of code ever written for squeak :)
>
>
>
> (...)
>
> Not the case for any kind of summoning. But there should be some level of
> testing. At least to detect dead links to repositories and to detect
> orphaned packages. If a package is orphaned long enough, there should be a
> policy for tagging and moving it to a special place... Regarding to orphaned
> packages I like Fedora model for announcing it and seeking for new
> maintainers. I also think that their model for responsibility delegation
> chain (it is far from perfect and sometimes not quite "democratic" but works
> most of time) is quite reasonable.
>
> But I guess that open software community is quite rich of good examples for
> maintaning distributed development.
>
> This discussion resembles other inside Fedora community: what should be
> in/out of a distro and how to maintain it. There are three proposals:
> Squeak, Pharo, Cuis. I'll tell you what I don't like in Pharo/Cuis
> proposals: they resemble me Brazilian way of solving things: you have
> something that's just not working as you wish. Instead of correcting the
> circumstances that lead to the problem, people start a new project saying:
> "now everything will be all right". Later the so called solution is
> suffering from the same problems and people launches a newer project to fix
> what went wrong with the predecessors.

> I think there's nothing fundamentally wrong with squeak. The question is how
> to organize things. How to classify things as "core", "contributed" and "3rd
> party". How to keep things up to date. How to obsolete things.
>
> It may be boring, but I think that many things could be formalized.
>
> First there are the leadership meetings on Wednesdays. The agenda of the
> meetings as well as their minutes could be placed at the
> www.squeak.org/Foundation. There should be a place where people could
> suggest topics to be included in the agenda. I know that much has been done
> via e-mail lists but for people (like me) who have to deal with large
> amounts of email these lists may be unpractical. Besides, keeping things
> public is a good way for letting people decide if they want or don't want to
> use squeak.
>

> As this discussion (about future of Squeak & Pharo) made clear, it is urgent
> to define what is in and what is out of Squeak. Since there's a real concern
> about back compatibility and as things are getting big and sometimes
> non-maintained, I would suggest that documenting things is essential.
>
> In my opinion, it would be interesting to create a mechanism for
> responsibility delegation regarding to maintenance. Regarding to
> distributions it would be interesting to create a mechanism for evaluating
> the suitability of packages to be included (like looking that the packages
> don't have dependencies outside the distribution and things that can lead to
> a situation where it is impossible to assure their maintenance). I don't
> think that a situation where a single person is responsible for a critical
> part of a distribution is acceptable: whenever such situation is identified
> the leadership should seek for additional people.
>
> In my opinion, it would be good if some sort of financial/corporate support
> could be granted. It would allow to have people involved in "non exciting"
> tasks. Again: corporate support doesn't translate in any kind of servitude
> and it can help to grow the universe of Squeak users. Besides, good
> marketing is essential: if you get good media it is more likely you'll be
> granted more and better projects... more people will pay attention to you.
>
> Just a last thing about croquet. It was meant to rock but didn't... I tell:
> (1) poor documentation (how in hell I use it???) (2) lack of marketing
> (yeah... even inside university good marketing is essential). Many people
> just didn't figured out what it was meant to (3) performance issues
> (intensive use of GL, etc).
>