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

Ramon Leon ramon.leon at
Mon Jun 29 20:29:05 UTC 2009

Stéphane Rollandin wrote:
>> Progress and backwards compatibility are fundamentally opposing 
>> forces, those insisting on backwards compatibility are the ones 
>> preventing progress. 
> Because they are opposing forces, we need to balance them. What you say 
> could be completed with: those insisting in progress are the ones 
> preventing actual software to be implemented.

Yes, and in Squeak, they are completely unbalanced, those wanting things 
to stay the same have won out over any major progress.  The eToys thing 
is a perfect example, it should have been ripped out a long time ago, 
the eToy community already forked.  The Squeak version is dead, and 
should have been removed but illogical resistance to change prevented it.

> What is the point of progress if you can't harvest it ? Don't you see 
> the drawbacks of a permanently moving target ?
> Stef

If you can't break compatibility, there is no progress, there is only 
stagnation.  The whole point of a version is to be able to break 
compatibility with previous versions, to make breaking changes, to 
correct mistakes of the past and make progress.  Harvesting is the wrong 
approach, it only works for small changes.  You don't harvest big 
rewrites, you upgrade to a new image and reload your code fix whatever 
your unit tests determine is now broken.

The idea of an ever evolving monolithic image that is continually 
patched into being current is just dead or dying.  What works today is a 
small core image and loadable packages with unit tests so images can be 
rebuilt anytime, especially between versions.  Unmaintained packages 
*should* die.

No one is forced to upgrade to the new version, if someone wants 
compatibility, they shouldn't upgrade.  If they want the latest and 
greatest, then porting their code to newer versions and fixing what they 
broke is the price they pay, it must be that way necessarily.  Otherwise 
there is no point in having new versions.

The drawbacks of a moving target are much less severe than the drawbacks 
of a stagnant and dying community which will be the end results of a 
attitude of not allowing breaking changes and progress.  People keep 
forking Squeak because the Squeak community is utterly directionless and 
resistant to change because that's the nature of any organization led by 
a committee elected by diverse groups of people who don't share a common 

Pharo is what Squeak should have been, a place for people who actually 
do the work to build what they want and not be held back by those who 
don't and just have strong opinions and don't want things to ever 
change.  The people actually doing the work should be the only people 
with any final say about what does or doesn't get done and what 
direction things should go.  The only way to challenge the removal of 
old, bad, or dead code should be to volunteer to step up and maintain it.

Ramon Leon
Chief Technical Officer
Alliance Reservations Network
IM Identities: gnaritas at aol, gnaritas2002 at yahoo, ramon.leon at gmail
Work: 602.889.5547
Fax: 602.224.9896

More information about the Squeak-dev mailing list