From: ... stéphane ducasse
[...]
But what we really need is a leadership which can be an organization that for example can collect funds, have a decent web page, identify target, motivate people, value enhancements... and not just a bunch of people working on projects without communication.
[...]
Coming in late to the discussion - apologies.
Sorry, Stef, but I disagree. What a successful open source project really needs are:
1. A small, close-knit bunch of people working on Squeak to achieve their own ends (these may not be 'leaders'), and distributing that product;
2. A way of allowing a larger group to modify and extend the products of that small group, and then to distribute those products.
I am going to argue that Squeak has *never* had that combination and, as a result, has never been a successful open source project.
-- the old way --
Squeak sort-of worked in the days of SqC. It worked because there were a core bunch of people who could and would sort out the problems, sometimes *despite* the larger community. The rest of us could argue, redesign, jabber away until we were blue in the face, but development continued despite all the noise. There weren't 'working groups' and 'cleanup projects' and the like; there were people who trusted each other to fix the problems while working solo. This works for a small group of Smalltalk developers, as our beloved "exquisite personal computing environment" can just-about deal with coders importing code from others in a small group. It's hard to do this with even a few people working on the same project, however, and seems to get exponentially harder as the number of developers increases.
Some of us in the larger group didn't always like the way the development was going. When a new image came out, we found that the extensions we had made didn't work any more, and we had to fix them or let them rot. So we clamoured to get 'our' bit into the 'base' image, because then it was more likely that it would be maintained. That didn't work, because the central maintainers couldn't maintain the extra bits and they rotted anyway. But neither was it possible to keep reasonable external packages that could be added in, because those packages relied on too much of that highly-functional, extensible class hierarchy in the core. Implementation inheritance is inherently fragile - as I think every package maintainer has found out when something minor changes in a base class and suddenly your code no longer works.
-- the new way --
SqC dispersed. Image maintenance was taken over by the larger group - and, immediately, the problems started. Our "exquisite personal computing environment" turned round and bit us, because it *sucks* as a system in which a large number of developers can work. We're now in the position of having a small group of 'harvesters', whose job is to examine changes submitted by others and to perform a damage-limitation exercise on the amount of change going on in the core image. It's a tough job; it burns people out. But, because we have this monolithic image, we don't have the choice.
The larger group are still no better off; possibly worse off. We still develop code. We are still encouraged by the functionality in this huge code base, and we still choose to use implementation inheritance to extend the system as there is no other mechanism in Squeak for extension. We still get ticked off when something modifies behaviour on which we depend; but now, we cannot even be sure that the modification is sensible, as the harvesters are having to pull in changes from many people and attempt to make them work together. This situation will remain while we continue to use implementation inheritance from base classes that evolve.
-- another way --
1. Throw away the notion that you can depend on that big, juicy class library. You can't, and it's a mistake to try, because it will evolve faster than you can keep up and your code will rot.
2. Decide on a very small, stable core. Collection and number classes may be a good start.
3. Introduce a proper notion of interfaces for these. Freeze the interfaces, either formally or by people avoiding modifying them.
4. Build up from this core. In each package - for example, the MVC UI - define and freeze interfaces. Document all the dependencies. Ensure each package can be loaded into an image that only has its dependencies loaded; and ensure that a package *cannot* alter any other package. Yes, this means that nobody except the maintainer of the core can touch Object, for any reason, no matter how apparently noble.
We will then have a basis for a system that might begin to satisfy (2) above. (1) will only happen when another (non-SqC) group of people get together and decide to use Squeak for a project. The larger community cannot force it.
Note that by making a system that is suitable for parallel development by many developers, we have thrown away most of the things that make Squeak such a productive system for developers. We have moved away from the concept of an exquisite personal computing environment to something much more rigid and prescriptive. This may put people off adopting such an approach, but I think stability and flexibility are mutually exclusive goals.
-- conclusion --
Due to Squeak's origin as a personal computing environment, it has never had a way of allowing a large group of developers to work on it and re-use each others' artifacts. Current efforts are attempting to change that, but there is no appetite for throwing the image away and starting again with a small core - a very hard task, made harder by the fact that all the development tools are in-image and need a larger core. So the architecture of Smalltalk itself is against us. Newcomers come in, realise that they can change the world in Squeak, do so, and then get discouraged when their code no longer works in the next minor version. So they put Squeak away - nice toy, unsuitable for me - and go back to perl, or Java, or .Net, or something that has a stable core and where their code won't break in the next minor revision. And it takes them more effort to develop in that environment, but *much* less effort to maintain.
I admire Craig Latta's work on small images that do not contain a development system. If we are ever to build a Squeak that allows many developers to work in parallel, Craig's work - or something very similar - is going to be pivotal, as the *only* way to build and test the core parts of such a system.
I'll leave you with one last puzzle: why does majorShrink exist? Why isn't it majorGrow?
- Peter
On Sun, Jan 30, 2005 at 10:20:55AM -0000, Peter Crowther wrote:
Coming in late to the discussion - apologies.
Sorry, Stef, but I disagree. What a successful open source project really needs are:
[huge snip]
Thanks for the email Peter; suddenly the origin of all the troubles is clear as water.
Hear, hear!
Subclassing is generally evil with two exceptions: 1) When subclassing a stable core. The only way for core classes to evolve is by creating new classes with new names. 2) When a developer creates super- and subclass simultaneously.
The Squeak programming environment needs to be extended with support for Interfaces. A great deal of what we today do with subclassing should be done with delegation.
Finally, the notion of a Component as an object that encapsulates other objects looks promising for program sharing; more robust than the code based Package.
Cheers --Trygve
At 11:20 30.01.2005, Peter wrote:
[...] -- another way --
- Throw away the notion that you can depend on that big, juicy class
library. You can't, and it's a mistake to try, because it will evolve faster than you can keep up and your code will rot.
- Decide on a very small, stable core. Collection and number classes may
be a good start.
- Introduce a proper notion of interfaces for these. Freeze the
interfaces, either formally or by people avoiding modifying them.
- Build up from this core. In each package - for example, the MVC UI -
define and freeze interfaces. Document all the dependencies. Ensure each package can be loaded into an image that only has its dependencies loaded; and ensure that a package *cannot* alter any other package. Yes, this means that nobody except the maintainer of the core can touch Object, for any reason, no matter how apparently noble.
We will then have a basis for a system that might begin to satisfy (2) above. (1) will only happen when another (non-SqC) group of people get together and decide to use Squeak for a project. The larger community cannot force it.
Note that by making a system that is suitable for parallel development by many developers, we have thrown away most of the things that make Squeak such a productive system for developers. We have moved away from the concept of an exquisite personal computing environment to something much more rigid and prescriptive. This may put people off adopting such an approach, but I think stability and flexibility are mutually exclusive goals.
-- conclusion --
Due to Squeak's origin as a personal computing environment, it has never had a way of allowing a large group of developers to work on it and re-use each others' artifacts. Current efforts are attempting to change that, but there is no appetite for throwing the image away and starting again with a small core - a very hard task, made harder by the fact that all the development tools are in-image and need a larger core. So the architecture of Smalltalk itself is against us. Newcomers come in, realise that they can change the world in Squeak, do so, and then get discouraged when their code no longer works in the next minor version. So they put Squeak away - nice toy, unsuitable for me - and go back to perl, or Java, or .Net, or something that has a stable core and where their code won't break in the next minor revision. And it takes them more effort to develop in that environment, but *much* less effort to maintain.
I admire Craig Latta's work on small images that do not contain a development system. If we are ever to build a Squeak that allows many developers to work in parallel, Craig's work - or something very similar - is going to be pivotal, as the *only* way to build and test the core parts of such a system.
I'll leave you with one last puzzle: why does majorShrink exist? Why isn't it majorGrow?
- Peter
On Sun, 30 Jan 2005 15:52:53 +0100, Trygve Reenskaug trygver@ifi.uio.no wrote:
The Squeak programming environment needs to be extended with support for Interfaces. A great deal of what we today do with subclassing should be done with delegation.
No, it should be extended with full support for Traits.
(personally, I think Traits - at least the 'run-time' bit - should be part of the core. Together with networking. Traits shapes the language, and a computer, virtual or not, without networking seems to be a bit useless to me these days ;)).
Trygve,
yes! one note/question - do you think using Stef's (at all) Traits would replace the need for interfaces and/or delegation or do you see something inheritent in having interfaces that Traits would not cover (because I assume Trait's provide what delegation can give us). [Well in any case it's time for me to start playing with Traits, loaded the new version this wekk but not time ...]
Milan
On January 30, 2005 09:52 am, Trygve Reenskaug wrote:
Hear, hear!
Subclassing is generally evil with two exceptions:
- When subclassing a stable core. The only way for core classes to evolve is by creating new classes with new names.
- When a developer creates super- and subclass simultaneously.
The Squeak programming environment needs to be extended with support for Interfaces. A great deal of what we today do with subclassing should be done with delegation.
Finally, the notion of a Component as an object that encapsulates other objects looks promising for program sharing; more robust than the code based Package.
Cheers --Trygve
At 11:20 30.01.2005, Peter wrote:
[...] -- another way --
- Throw away the notion that you can depend on that big, juicy class
library. You can't, and it's a mistake to try, because it will evolve faster than you can keep up and your code will rot.
- Decide on a very small, stable core. Collection and number classes may
be a good start.
- Introduce a proper notion of interfaces for these. Freeze the
interfaces, either formally or by people avoiding modifying them.
- Build up from this core. In each package - for example, the MVC UI -
define and freeze interfaces. Document all the dependencies. Ensure each package can be loaded into an image that only has its dependencies loaded; and ensure that a package *cannot* alter any other package. Yes, this means that nobody except the maintainer of the core can touch Object, for any reason, no matter how apparently noble.
We will then have a basis for a system that might begin to satisfy (2) above. (1) will only happen when another (non-SqC) group of people get together and decide to use Squeak for a project. The larger community cannot force it.
Note that by making a system that is suitable for parallel development by many developers, we have thrown away most of the things that make Squeak such a productive system for developers. We have moved away from the concept of an exquisite personal computing environment to something much more rigid and prescriptive. This may put people off adopting such an approach, but I think stability and flexibility are mutually exclusive goals.
-- conclusion --
Due to Squeak's origin as a personal computing environment, it has never had a way of allowing a large group of developers to work on it and re-use each others' artifacts. Current efforts are attempting to change that, but there is no appetite for throwing the image away and starting again with a small core - a very hard task, made harder by the fact that all the development tools are in-image and need a larger core. So the architecture of Smalltalk itself is against us. Newcomers come in, realise that they can change the world in Squeak, do so, and then get discouraged when their code no longer works in the next minor version. So they put Squeak away - nice toy, unsuitable for me - and go back to perl, or Java, or .Net, or something that has a stable core and where their code won't break in the next minor revision. And it takes them more effort to develop in that environment, but *much* less effort to maintain.
I admire Craig Latta's work on small images that do not contain a development system. If we are ever to build a Squeak that allows many developers to work in parallel, Craig's work - or something very similar - is going to be pivotal, as the *only* way to build and test the core parts of such a system.
I'll leave you with one last puzzle: why does majorShrink exist? Why isn't it majorGrow?
- Peter
Milan, Yes, I am confident that traits is an important part of our future. Give me a few months, and I can (hopefully) be more specific about where I believe it fits in.
Trygve
At 23:22 30.01.2005, you wrote:
Trygve,
yes! one note/question - do you think using Stef's (at all) Traits would replace the need for interfaces and/or delegation or do you see something inheritent in having interfaces that Traits would not cover (because I assume Trait's provide what delegation can give us). [Well in any case it's time for me to start playing with Traits, loaded the new version this wekk but not time ...]
Milan
On January 30, 2005 09:52 am, Trygve Reenskaug wrote:
Hear, hear!
Subclassing is generally evil with two exceptions:
- When subclassing a stable core. The only way for core classes to evolve is by creating new classes with new names.
- When a developer creates super- and subclass simultaneously.
The Squeak programming environment needs to be extended with support for Interfaces. A great deal of what we today do with subclassing should be done with delegation.
Finally, the notion of a Component as an object that encapsulates other objects looks promising for program sharing; more robust than the code based Package.
Cheers --Trygve
At 11:20 30.01.2005, Peter wrote:
[...] -- another way --
- Throw away the notion that you can depend on that big, juicy class
library. You can't, and it's a mistake to try, because it will evolve faster than you can keep up and your code will rot.
- Decide on a very small, stable core. Collection and number classes may
be a good start.
- Introduce a proper notion of interfaces for these. Freeze the
interfaces, either formally or by people avoiding modifying them.
- Build up from this core. In each package - for example, the MVC UI -
define and freeze interfaces. Document all the dependencies. Ensure each package can be loaded into an image that only has its dependencies loaded; and ensure that a package *cannot* alter any other package. Yes, this means that nobody except the maintainer of the core can touch Object, for any reason, no matter how apparently noble.
We will then have a basis for a system that might begin to satisfy (2) above. (1) will only happen when another (non-SqC) group of people get together and decide to use Squeak for a project. The larger community cannot force it.
Note that by making a system that is suitable for parallel development by many developers, we have thrown away most of the things that make Squeak such a productive system for developers. We have moved away from the concept of an exquisite personal computing environment to something much more rigid and prescriptive. This may put people off adopting such an approach, but I think stability and flexibility are mutually exclusive goals.
-- conclusion --
Due to Squeak's origin as a personal computing environment, it has never had a way of allowing a large group of developers to work on it and re-use each others' artifacts. Current efforts are attempting to change that, but there is no appetite for throwing the image away and starting again with a small core - a very hard task, made harder by the fact that all the development tools are in-image and need a larger core. So the architecture of Smalltalk itself is against us. Newcomers come in, realise that they can change the world in Squeak, do so, and then get discouraged when their code no longer works in the next minor version. So they put Squeak away - nice toy, unsuitable for me - and go back to perl, or Java, or .Net, or something that has a stable core and where their code won't break in the next minor revision. And it takes them more effort to develop in that environment, but *much* less effort to maintain.
I admire Craig Latta's work on small images that do not contain a development system. If we are ever to build a Squeak that allows many developers to work in parallel, Craig's work - or something very similar - is going to be pivotal, as the *only* way to build and test the core parts of such a system.
I'll leave you with one last puzzle: why does majorShrink exist? Why isn't it majorGrow?
- Peter
On January 31, 2005 10:21 am, Trygve Reenskaug wrote:
Milan, Yes, I am confident that traits is an important part of our future. Give me a few months, and I can (hopefully) be more specific about where I believe it fits in.
Juicy bait, will stay atuned -)
Thanks for your comment, Milan
Trygve
At 23:22 30.01.2005, you wrote:
Trygve,
yes! one note/question - do you think using Stef's (at all) Traits would replace the need for interfaces and/or delegation or do you see something inheritent in having interfaces that Traits would not cover (because I assume Trait's provide what delegation can give us). [Well in any case it's time for me to start playing with Traits, loaded the new version this wekk but not time ...]
Milan
On January 30, 2005 09:52 am, Trygve Reenskaug wrote:
Hear, hear!
Subclassing is generally evil with two exceptions:
- When subclassing a stable core. The only way for core classes to evolve is by creating new classes with new names.
- When a developer creates super- and subclass simultaneously.
The Squeak programming environment needs to be extended with support for Interfaces. A great deal of what we today do with subclassing should be done with delegation.
Finally, the notion of a Component as an object that encapsulates other objects looks promising for program sharing; more robust than the code based Package.
Cheers --Trygve
At 11:20 30.01.2005, Peter wrote:
[...] -- another way --
- Throw away the notion that you can depend on that big, juicy class
library. You can't, and it's a mistake to try, because it will evolve faster than you can keep up and your code will rot.
- Decide on a very small, stable core. Collection and number classes
may be a good start.
- Introduce a proper notion of interfaces for these. Freeze the
interfaces, either formally or by people avoiding modifying them.
- Build up from this core. In each package - for example, the MVC UI
- define and freeze interfaces. Document all the dependencies.
Ensure each package can be loaded into an image that only has its dependencies loaded; and ensure that a package *cannot* alter any other package. Yes, this means that nobody except the maintainer of the core can touch Object, for any reason, no matter how apparently noble.
We will then have a basis for a system that might begin to satisfy (2) above. (1) will only happen when another (non-SqC) group of people get together and decide to use Squeak for a project. The larger community cannot force it.
Note that by making a system that is suitable for parallel development by many developers, we have thrown away most of the things that make Squeak such a productive system for developers. We have moved away from the concept of an exquisite personal computing environment to something much more rigid and prescriptive. This may put people off adopting such an approach, but I think stability and flexibility are mutually exclusive goals.
-- conclusion --
Due to Squeak's origin as a personal computing environment, it has never had a way of allowing a large group of developers to work on it and re-use each others' artifacts. Current efforts are attempting to change that, but there is no appetite for throwing the image away and starting again with a small core - a very hard task, made harder by the fact that all the development tools are in-image and need a larger core. So the architecture of Smalltalk itself is against us. Newcomers come in, realise that they can change the world in Squeak, do so, and then get discouraged when their code no longer works in the next minor version. So they put Squeak away - nice toy, unsuitable for me - and go back to perl, or Java, or .Net, or something that has a stable core and where their code won't break in the next minor revision. And it takes them more effort to develop in that environment, but *much* less effort to maintain.
I admire Craig Latta's work on small images that do not contain a development system. If we are ever to build a Squeak that allows many developers to work in parallel, Craig's work - or something very similar - is going to be pivotal, as the *only* way to build and test the core parts of such a system.
I'll leave you with one last puzzle: why does majorShrink exist? Why isn't it majorGrow?
- Peter
yes! one note/question - do you think using Stef's (at all) Traits would
Nathanael's traits (I'm only responsible of the topic and aliases :) But yes this is the goal of traits.
replace the need for interfaces and/or delegation or do you see something inheritent in having interfaces that Traits would not cover (because I assume Trait's provide what delegation can give us). [Well in any case it's time for me to start playing with Traits, loaded the new version this wekk but not time ...]
Milan
On January 30, 2005 09:52 am, Trygve Reenskaug wrote:
Hear, hear!
Subclassing is generally evil with two exceptions:
- When subclassing a stable core. The only way for core classes to evolve is by creating new classes with new names.
- When a developer creates super- and subclass simultaneously.
The Squeak programming environment needs to be extended with support for Interfaces. A great deal of what we today do with subclassing should be done with delegation.
Finally, the notion of a Component as an object that encapsulates other objects looks promising for program sharing; more robust than the code based Package.
Cheers --Trygve
At 11:20 30.01.2005, Peter wrote:
[...] -- another way --
- Throw away the notion that you can depend on that big, juicy class
library. You can't, and it's a mistake to try, because it will evolve faster than you can keep up and your code will rot.
- Decide on a very small, stable core. Collection and number
classes may be a good start.
- Introduce a proper notion of interfaces for these. Freeze the
interfaces, either formally or by people avoiding modifying them.
- Build up from this core. In each package - for example, the MVC
UI - define and freeze interfaces. Document all the dependencies. Ensure each package can be loaded into an image that only has its dependencies loaded; and ensure that a package *cannot* alter any other package. Yes, this means that nobody except the maintainer of the core can touch Object, for any reason, no matter how apparently noble.
We will then have a basis for a system that might begin to satisfy (2) above. (1) will only happen when another (non-SqC) group of people get together and decide to use Squeak for a project. The larger community cannot force it.
Note that by making a system that is suitable for parallel development by many developers, we have thrown away most of the things that make Squeak such a productive system for developers. We have moved away from the concept of an exquisite personal computing environment to something much more rigid and prescriptive. This may put people off adopting such an approach, but I think stability and flexibility are mutually exclusive goals.
-- conclusion --
Due to Squeak's origin as a personal computing environment, it has never had a way of allowing a large group of developers to work on it and re-use each others' artifacts. Current efforts are attempting to change that, but there is no appetite for throwing the image away and starting again with a small core - a very hard task, made harder by the fact that all the development tools are in-image and need a larger core. So the architecture of Smalltalk itself is against us. Newcomers come in, realise that they can change the world in Squeak, do so, and then get discouraged when their code no longer works in the next minor version. So they put Squeak away - nice toy, unsuitable for me - and go back to perl, or Java, or .Net, or something that has a stable core and where their code won't break in the next minor revision. And it takes them more effort to develop in that environment, but *much* less effort to maintain.
I admire Craig Latta's work on small images that do not contain a development system. If we are ever to build a Squeak that allows many developers to work in parallel, Craig's work - or something very similar - is going to be pivotal, as the *only* way to build and test the core parts of such a system.
I'll leave you with one last puzzle: why does majorShrink exist? Why isn't it majorGrow?
- Peter
On February 1, 2005 04:36 am, stéphane ducasse wrote:
yes! one note/question - do you think using Stef's (at all) Traits would
Nathanael's traits (I'm only responsible of the topic and aliases :)
my bad, sorry Nathanael i thought i was reading Stef's article on traits -)
But yes this is the goal of traits.
replace the need for interfaces and/or delegation or do you see something inheritent in having interfaces that Traits would not cover (because I assume Trait's provide what delegation can give us). [Well in any case it's time for me to start playing with Traits, loaded the new version this wekk but not time ...]
Milan
On January 30, 2005 09:52 am, Trygve Reenskaug wrote:
Hear, hear!
Subclassing is generally evil with two exceptions:
- When subclassing a stable core. The only way for core classes to evolve is by creating new classes with new names.
- When a developer creates super- and subclass simultaneously.
The Squeak programming environment needs to be extended with support for Interfaces. A great deal of what we today do with subclassing should be done with delegation.
Finally, the notion of a Component as an object that encapsulates other objects looks promising for program sharing; more robust than the code based Package.
Cheers --Trygve
At 11:20 30.01.2005, Peter wrote:
[...] -- another way --
- Throw away the notion that you can depend on that big, juicy class
library. You can't, and it's a mistake to try, because it will evolve faster than you can keep up and your code will rot.
- Decide on a very small, stable core. Collection and number
classes may be a good start.
- Introduce a proper notion of interfaces for these. Freeze the
interfaces, either formally or by people avoiding modifying them.
- Build up from this core. In each package - for example, the MVC
UI - define and freeze interfaces. Document all the dependencies. Ensure each package can be loaded into an image that only has its dependencies loaded; and ensure that a package *cannot* alter any other package. Yes, this means that nobody except the maintainer of the core can touch Object, for any reason, no matter how apparently noble.
We will then have a basis for a system that might begin to satisfy (2) above. (1) will only happen when another (non-SqC) group of people get together and decide to use Squeak for a project. The larger community cannot force it.
Note that by making a system that is suitable for parallel development by many developers, we have thrown away most of the things that make Squeak such a productive system for developers. We have moved away from the concept of an exquisite personal computing environment to something much more rigid and prescriptive. This may put people off adopting such an approach, but I think stability and flexibility are mutually exclusive goals.
-- conclusion --
Due to Squeak's origin as a personal computing environment, it has never had a way of allowing a large group of developers to work on it and re-use each others' artifacts. Current efforts are attempting to change that, but there is no appetite for throwing the image away and starting again with a small core - a very hard task, made harder by the fact that all the development tools are in-image and need a larger core. So the architecture of Smalltalk itself is against us. Newcomers come in, realise that they can change the world in Squeak, do so, and then get discouraged when their code no longer works in the next minor version. So they put Squeak away - nice toy, unsuitable for me - and go back to perl, or Java, or .Net, or something that has a stable core and where their code won't break in the next minor revision. And it takes them more effort to develop in that environment, but *much* less effort to maintain.
I admire Craig Latta's work on small images that do not contain a development system. If we are ever to build a Squeak that allows many developers to work in parallel, Craig's work - or something very similar - is going to be pivotal, as the *only* way to build and test the core parts of such a system.
I'll leave you with one last puzzle: why does majorShrink exist? Why isn't it majorGrow?
- Peter
On Sun, 30 Jan 2005 10:20:55 -0000, Peter Crowther Peter@ozzard.org wrote:
-- another way --
Hear, hear! (mostly. There are quite a number of nits in your story I'd like to pick, but I'm not going to do that at this moment)
BTW - I'm thinking that we could decide to "just do it". Cause major breakage in, say, a version we call 3.14159... by starting with one of the small images (I got a very nice image from Edgar De Cleene - networking, (MVC) dev tools are there, it's 2Mb big and based on 3.6. Shouldn't be to hard to roll this core code (lots of MVC tool code that hasn't been changed anyway between 3.6 and now, I think) forward to the current state.
It's not a super-duper minimal core (which I, personally, tend to define as "the minimal Squeak system that can bootstrap itself in one way or another into something more useful" - Craig's work fits that definition nicely, of course), but it is a whole lot better than what we've got now and could be done immediately, just by deciding to do it. Probably by (mentally) splitting it up, internally, in 'core', 'dev' and 'networking', you'd have a 'core' that's quite close to what you want at the end.
The efforts to make a really minimal Squeak image could all continue, but by kicking out 90% of the code right now we'd be 95% there, not?
And, yes, I know that I'm conveniently ignoring a whole slew of issues. But by Just Doing It, we could actually attempt to tackle these issues instead of constantly debating them. It'd be a whole lot easier to have lots of package and observe how they interact and depend and finding ways of dealing with that, than theorizing about it. But then, I'm a coder, not a researcher.
(re breakage - I just realized that it should be possible to use the RB rewriting stuff with thisContext sender to actually rewrite methods that call obsolete stuff and send the maintainer of the package an auto-generated patch. Now that'd be an elegant tool for dealing with bit rot ;)).
Peter, you have a good idea but you are looking at Squeak as the wrong kind of project. It is not a single application that does one thing. The individual applications built in Squeak *do* have a small team of dedicated programmers: EToys, Croquet, Scratch, the Berne group, Squat, L, etc. etc.
But for Squeak as a whole? A better analogy, as I've often argued, is to compare it to a Linux distribution. Squeak as a whole needs to support all of us working together using the same basic code base. Squeak-as-a-whole fails if everyone forks off and uses their own Squeak, never to re-merge. But heck, even if that happens, it's not the end of the world. It only means we are more like Scheme than like Debian, with everyone pursuing independent, incompatibly paths. The ideas will still be in each independent path.
(And given this, I think we should model our processses after linux distributions, or after SE processes that develop *suites* of applications, not after SE processes or open source groups that are building *individual* applications.)
Lex
PS -- why do we see so many depressed posts? Things seem to be progressing nicely, to me.
-- another way --
--- Yet Another Way ---
I think the way forward would to introduce a packaging system with namespaces and versioning, this would allow concurrent support and usage of different versions of Squeak libraries and applications. This would provide a way forward and if it was done right could be pritty transparent once libraries and applications are set up. This would then allow migration of applications to newer libraries in a controlled way.
Aaron
squeak-dev@lists.squeakfoundation.org
-
Aaron Gray -
Cees de Groot -
Lex Spoon -
Milan Zimmermann -
Peter Crowther -
Ragnar Hojland Espinosa -
stéphane ducasse -
Trygve Reenskaug