On Mon, 2009-06-29 at 13:29 -0700, Ramon Leon wrote:
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.
I didn't want to participate at all in this thread but reading your post I feel the need to fully agree.
over and out,
Norbert