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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Jul 1 18:02:29 UTC 2009


Hi Keith,
I understand some of your bitterness, but I think that's the destiny
of who involves in this community:
doing the hard work is hardly ever encouraged, and you get promptly
bashed for what does not work.

2009/7/1 Keith Hodges <keith_hodges at yahoo.co.uk>:
> Douglas Brebner wrote:
>>
>> I feel the Pharo people deserve a beer for lighting a fire under the
>> Squeak community and getting people motivated :)
>>
> The Squeak community was motivated before Pharo, and lots of work has
> been done in the past couple of years outside of Pharo to improve squeak
> for use in a commercial environment. My own contribution to this includes:
>
> Installer - DSL for building images
> SUnit-improved
> SSpec
> TestReporter - Text based SUnit runner
> MC1.5 - merge of all forks of MC
> MC1.5 Orphanage - out of order loading
> MC1.5 - extensions and overrides actually work.
> MC1.6 - initial coding for Atomic Loading
> Sake - aka. make/rake for squeak
> Sake/Packages - replace universes
> Bob1 (in ruby)
> Sake/Bob - automatic build/test server
> Logging
> LevelPlayingField
>
> If that lot don't constitute motivation, I don't know what does.
>
> What pharo managed to do was demotivate several people who had
> contributed, and their contributions were summarily ignored.
>
> For example, I regard the fact that Pharo started with 3.9 when there
> was no reason why they could not have started with 3.10, as a
> significant insult to Edgar and the rest of us that put lots of effort
> into 3.10.
>

You make a point here.
Pharo did have to redo most of (all ?) 3.10 anyway, that's a lost of time.

> As a second example I consider the fact that Pharo refuses to adopt or
> contribute to MC1.5 with a view to adoption. MC1.5 included a merge of
> several MC forks, and common tools are essential for cross fertilisation
> within the community. I take their actions as a demonstration that they
> are not interested in being community players or working with any
> broader community vision that I we or anyone might propose.
>

Things are not definitive. They can still adopt MC1.5.
On the other hand, there is also MC1.6 without Trait support and
MC2.0... So it might still be urgent to wait. Even if Pharo resources
are growing, there are still sparse wrt their own goals.

Also don't forget Pharo team wanted a solid base for starting rapidly,
and I perfectly understand that they preferred a less powerfull well
known solution from which they already knew the limitations to an
advanturous new one not completely stabilized, or at least unknown.

> We had a golden opportunity for the community to work together on the
> important tools, and the Pharo guys will not play ball, they will not
> join with any vision other than their own. This has the effect of
> DEMOTIVATING folks like myself who would like to see all of the
> community work together, and have been working towards that end for over
> 3 years.
>

Your work is valuable and is not lost. Things are not changing as fast
as we want it...

> They will not contribute to any of the above projects that are
> maintained in public repositories as a community resource. Instead they
> retain their own forks of SUnit and MC, etc.
>

That's a temporary pragmatic choice. They want to have control over
the process and cannot depend on too many thrid party hypothetic
achivements.

> This has driven me to the point of not being motivated to continue to
> contribute to MC, because the Pharo team are effectively vetoing the
> adoption of any future enhancements.  I cannot take pharo seriously as a
> commercial development tool, when it uses MC1 which doesn't cope with
> method extensions or overrides. (fine if you are in you ivory tower and
> writing your own code from scratch, but a nightmare if you try to patch
> up and maintain code that is not your own)
>

Hmm. IMO Maintaining code you don't own is a dead end anyway.
If that code evolves out of your control, then you get unwanted work
flowing and being downstream is not comfortable...
I experienced this with st-80/Objectworks because I deeply modified
the system...
(keyboard short cut, alternate fonts/emphasis, localization, bubble
help, code formatting etc...)

> In summary, I have regrettably discovered and continue to maintain that
> the attitude of the Pharo team is very rude indeed. I have pondered
> whether this is a cultural thing (i.e. traditionally the French and
> English don't get along). I have discussed it with my non coding friends
> and others and I have not managed to come to any other constructive
> conclusion.
>

Yes, you can take it as selfish, but I don't see anything cultural
here, and I doubt Pharo is only a french thing.

> So in conclusion, I personally regard pharo as a small academic research
> project being carried out on behalf of the smalltalk community. It's
> only valuable output will be the MIT licenced code that they produce.
> The lack of social skills in the pharo team is only surpassed by my own.
> As such this renders the pharo vision useless to any bigger concept of
> shared objective or values, and that's what I think squeak is really all
> about.
>
> Keith
>

That's already something.
Or isn't the greatest output to shake this community?

Nicolas



More information about the Squeak-dev mailing list