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