[squeak-dev] Re: [Pharo-project] Just a little point

Keith Hodges keith_hodges at yahoo.co.uk
Tue Jul 7 17:47:54 UTC 2009


> If find it weird that 2 Smalltalk implementations/communities, so
> close to each other like Squeak and Pharo, go to great lengths at
> flaming each other... 

No they don't, it's just me.

Please don't tar the mostly polite squeak-dev with my brush.

I spent a lot of time working on stuff that pharo could use,
particularly because a lot of it was Stephane's idea in the first place,
going back to August 2006.

My two main points of contention are Monticello and SUnit but as you can
see there are others.

Monticello:  I put a LOT, read LOTS of effort into joining the 3+
Monticello forks into one, and assuring that it loads in to all forks of
squeak, as a strategic approach for the whole community to have common
tools everywhere.
Pharo has made that effort a waste of time, simply because they wont use
or contribute to the merged uber-Monticello.

SUnit: I put a second lot of effort into improving SUnit so that it
could support multiple forks of squeak simultaneously. I also wrote a
non Gui test runner for automated testing. SUnit is a public resource
and is maintained in a public repository. Pharo have needlessly forked
SUnit.

Several things that wind me up, one is wasted effort, and another is
duplicated effort, and the third is making plans to duplicate effort on
purpose.
> that will only leave us isolated, both in our own camps ?  I'm
> puzzled!  What do I do if I like both?  Choose my camp or abandon them
> both ?
If you like both, then please encourage them to make parts that could be
common common. For example I maintain ProcessSpecific for Logging, Pharo
has integrated ProcessSpecific but has made no attempt to pick or offer
feedback to version that was maintained. This is one of numerous example
of subsystems that could easily be mutually maintained.

There are many initiatives in the pharo camp, that could be developed
and deployed into both camps. I spent all that time on Monticello in
order to ensure that this could happen, but pharo only develops
initiatives for itself, therefore Pharo is effectively planning for
duplicated effort.

One more example, Pharo could come up with an initiative to fix the
sources/changes file mess. This would be very benefitcial to me. However
its no good if I cant load it into squeak where a lot of my code runs. 
So at some point someone would have to duplicate the effort for Squeak.
All it would take is a little thought and planning.

When I took the initiative to write Rio as a replacement for
FileDirectory, I did it in such a way as anyone could benefit.
When I took the initiative to write Logging as a potential core feature
for Kernel/Server images I did it so that anyone could benefit.
When I wrote the TestReporter as a text based tool for testing I did it
so that anyone could benefit.
When I wrote Bob for automated image building and testing I have done it
so that it can build any image.
When I wrote  Sake for rake like functionality it loads into any image.
When I wrote Sake/Packges for managing packges dependencies I did it so
that any image can benefit.

I dont know what initiatives pharo has completed, but, and please do
correct me if I am wrong. I havent seen a single initiative from pharo
that has been developed and deployed so that everyone could benefit.

best regards

Keith






More information about the Squeak-dev mailing list