What 3.3a is trying to do with modules is essentially opening the same can of worms that has made MS Windows such a maintenance nightmare. Modules are (more or less) equivalent to .DLLs and may end up with all the associated issues. I don't know of any "good" solutions to these problems, but as attractive as the "idea" of modules is, I am personally content to stick with monolithic images for the forseeable future.
The whole concept of "software components" is IMO a fantasy propagated by media hype that ignores all the realities of real world engineering. In "real" hardware product designs, one often finds that re-usability is more of a structuring concept than a hard reality. I don't believe I've ever worked on a hardware design that didn't involve some kind of custom connector that is a "slight" variation of a "standard" connector, for example. (Just for context, I'm referring to everything I've worked on in the last 12 years or so).
I think the concept of a monolithic image constrains the reusability myth to realistic proportions, and makes implementation possible. Too much flexibility comes at a cost, which usually rears its ugly head in the form of increased complexity, higher resource requirements, and reduced preformance (relative to a less flexible implementation).
As an example of what I'm talking about, I've worked on a couple of different projects in the last few years where the end product has similar capabilities but one was implemented using a "flexible, reusable platform approach" and the other was implemented using a more task specific approach.
The flexible system has a source tree for the "platform" of about 5 gigabytes, generates a target image of about 170 megabytes, and needs two 300 MHz PowerPC 603e's and 512M of RAM to run. This system has hundreds of developers working on it.
The "task specific" system has a source tree of about 300 megabytes, generates a target image of about 1 megabyte, and runs on one 66 MHz PowerPC with 16M of RAM. This system had 4 developers working on it. The end functionalities of these two systems is *very* similar.
I'm not sure what my point is in all of this, but I think we should consider our goals carefully in relation to the questions that Andrew has raised. My preference is towards "lean and mean" rather than "incredibly flexible, general purpose (and suboptimal)".
-Dean Swan
-----Original Message----- From: Les Tyrrell [mailto:tyrrell@canis.uiuc.edu] Sent: Thursday, October 24, 2002 8:15 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: An uncomfortable question
These are important points- as we move forward, I am hoping that we will be moving towards a model in which individual pieces of code are liberated as much as possible from unneccessary constraints on their usage. That is going to require a rather significant change in a lot of Squeak's infrastructure, but I am rather impressed with how much progess is being made by a lot of people in terms of understanding those issues, or at least recognizing them. The days of the monolithic image ( and the inherent weaknesses and roadblocks to progress that it represents ) are, hopefully, numbered.
- les
----- Original Message ----- From: danielv@netvision.net.il To: squeak-dev@lists.squeakfoundation.org Sent: Thursday, October 24, 2002 3:41 PM Subject: Re: An uncomfortable question
Well, I think something interesting is happening in SqueakMap. The count is now up to 16 packages, by 8 different authors. These range from small framework additions like SharedStreams to large projects that would be unlikely to ever become available through the Squeak base image, like Seaside.
This opens up directly possibilities to maintain other projects outside the image too, like Celeste, Scamper and others.
All this should reduce the maintainance effort required of SqC, and let the community do experiments in various directions without actually requiring a fork.
A case in point - if Henrik's code was first debuted as a SM package, it would have gotten earlier feedback, it could have been more modular, it would have been easier for people to try out and it would have been optional, orthogonal to the harvesting work done on 3.3a.
This would have saved us at least one uncomfortable question.
So I think one important thing to consider is how we take full advantage of this new option we have as a community, and how we change our process to fit it in.
Dean,
your thoughts are interesting and provocating. They have triggered some thoughts in my brain...
Swan, Dean wrote:
What 3.3a is trying to do with modules is essentially opening the same can of worms that has made MS Windows such a maintenance nightmare. Modules are (more or less) equivalent to .DLLs and may end up with all the associated issues. I don't know of any "good" solutions to these problems, but as attractive as the "idea" of modules is, I am personally content to stick with monolithic images for the forseeable future.
Why is the <stdio.h> module in the C world so successful? Since it has a well defined *interface*.
It is *not* sufficient to divide a big system into modules, it is necessary to get a clear definition of their interfaces to the world! Then a change in the interface suggests more or less compatibility problems, but not improvements and bug fixes inside a module.
Thinking loud: what about working at tools for viewing/defining/changing/detecting interfaces first, and then putting this concept as a subconcept into the modules concept?
The whole concept of "software components" is IMO a fantasy propagated by media hype that ignores all the realities of real world engineering.
I wouldn't be so hard: it depends. One example: Squeak itself uses interfaces to external code modules to be portable between many platforms...
In "real" hardware product designs, one often finds that re-usability is more of a structuring concept than a hard reality. I don't believe I've ever worked on a hardware design that didn't involve some kind of custom connector that is a "slight" variation of a "standard" connector, for example. (Just for context, I'm referring to everything I've worked on in th e last 12 years or so).
Statement: There is one important difference between hard- and software: hardware interfaces evolve much faster.
(Some doubt remains: Is this true?)
I think the concept of a monolithic image constrains the reusability myth to realistic proportions, and makes implementation possible. Too much flexibility comes at a cost, which usually rears its ugly head in the form of increased complexity, higher resource requirements, and reduced preformance (relative to a less flexible implementation).
Squeak already consists of multiple 'modules', mostly without well defined interfaces. And it becomes worse, if there is no fight against.
As an example of what I'm talking about, I've worked on a couple of different projects in the last few years where the end product has similar capabilities but one was implemented using a "flexible, reusable platform approach" and the other was implemented using a more task specific approach.
The flexible system has a source tree for the "platform" of about 5 gigabytes, generates a target image of about 170 megabytes, and needs two 300 MHz PowerPC 603e's and 512M of RAM to run. This system has hundreds of developers working on it.
The "task specific" system has a source tree of about 300 megabytes, generates a target image of about 1 megabyte, and runs on one 66 MHz PowerPC with 16M of RAM. This system had 4 developers working on it. The end functionalities of these two systems is *very* similar.
To how many platforms has the 'flexible, reusable platform approach' been applied (to get their theoretical benefits)?
In any case: your example is glaring and the latter approach has won there.
But there are other possible reasons for failure of the 'flexible' approach: e.g. just to manage 'hundreds of developers' could be a nightmare.
I'm not sure what my point is in all of this, but I think we should consider our goals carefully in relation to the questions that Andrew has raised. My preference is towards "lean and mean" rather than "incredibly flexible, general purpose (and suboptimal)".
I'm against to try to get an "Eierlegende Wollmilchsau" (means 'something to do all and very different tasks', to quote a nice German expression), but I'm for working towards better definitions of interfaces and a more modularized system.
-Dean Swan
Greetings,
Stephan
PS: Your mail without line breaks at 76 chars or so wasn't very easy for me to reply to with good readability... (admitted: my mail client (Mozilla) could be better, I've solved the problem by forwarding the mail to myself and copy/pasteQuoted the line breaked result (since replying to or using for copy/pasteQuoted the original one resulted in quoted *not* line breaked lines, which is very ugly)).
-----Original Message----- From: Les Tyrrell [mailto:tyrrell@canis.uiuc.edu] Sent: Thursday, October 24, 2002 8:15 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: An uncomfortable question
These are important points- as we move forward, I am hoping that we will be moving towards a model in which individual pieces of code are liberated as much as possible from unneccessary constraints on their usage. That is going to require a rather significant change in a lot of Squeak's infrastructure, but I am rather impressed with how much progess is being made by a lot of people in terms of understanding those issues, or at least recognizing them. The days of the monolithic image ( and the inherent weaknesses and roadblocks to progress that it represents ) are, hopefully, numbered.
- les
----- Original Message ----- From: danielv@netvision.net.il To: squeak-dev@lists.squeakfoundation.org Sent: Thursday, October 24, 2002 3:41 PM Subject: Re: An uncomfortable question
Well, I think something interesting is happening in SqueakMap. The count is now up to 16 packages, by 8 different authors. These range from small framework additions like SharedStreams to large projects that would be unlikely to ever become available through the Squeak base image, like Seaside.
This opens up directly possibilities to maintain other projects outside the image too, like Celeste, Scamper and others.
All this should reduce the maintainance effort required of SqC, and let the community do experiments in various directions without actually requiring a fork.
A case in point - if Henrik's code was first debuted as a SM package, it would have gotten earlier feedback, it could have been more modular, it would have been easier for people to try out and it would have been optional, orthogonal to the harvesting work done on 3.3a.
This would have saved us at least one uncomfortable question.
So I think one important thing to consider is how we take full advantage of this new option we have as a community, and how we change our process to fit it in.
On Wednesday 30 October 2002 04:44 pm, Stephan Rudlof wrote:
Statement: There is one important difference between hard- and software: hardware interfaces evolve much faster.
(Some doubt remains: Is this true?)
Not particularly. Look at how long the 80386/80486 instruction set has been with us -- through several entire generations of processors!
And PCI, and PCMCIA, USB, etc... all of them standards that (though they're changing gradually) still remain backwards-compatible.
Where hardware does change dramatically, it usually requires stable software specs: for instance, 3D graphics acceleration has only become useful through standards like OpenGL and DirectX.
On balance, I am with Dean.
I think the beauty of Squeak is that you can get down to programming without any superfluous rubbish like Java's import java.io.* or the literary diarrhoea of stuff like Iterator myIterator = new Iterator() (how many times do you have to say something before the compiler 'get it'?) etc etc. It is clear and pure and I would hate it to be muddied by unnecessary stuff just because of me-too-itis.
However, I also understand the problem of having multiple 'applications' in the one image and inter-dependencies.
It is a tough problem.
Karl
Just playing Devil's advocate here...
On Thu, 31 Oct 2002, Stephan Rudlof wrote:
Why is the <stdio.h> module in the C world so successful? Since it has a well defined *interface*.
... which after 30 years is still not quite entirely the same between different implementations of libc. <wink> ;)
Ian
Hello All,
To begin with, if this is not the correct list to post to for these kind of questions please direct me to the correct list. With that out of the way, on to my questions and comments.
I have recently (within the last few days) discovered SmallTalk and Squeak in general. Oh, I have heard about SmallTalk in the past and even Squeak but I never picked it up for a number of reasons. In any case, I have been looking for a good productive cross platform language that has excellent support of a GUI interface. These criteria made finally me stop and look at both SmallTalk and Squeak in particular. I am glad I did. After reading some of the docs and playing around with the environment I already like it allot. In fact the code browser reminds me a whole lot of VisualAge for Java, one of my favorite IDEs. Of course, Now I found out that why VisualAge for Java resembles Squeak and other SmallTalk environments, I assume lol.
Ok so now I am all hyped up ready to write some code and get a feel for the environment, particularly Morphic which is what drew me here in the first place. Alas this is where I fall flat on my face. There are a few very simple tutorials out there, but there doesn't seem to be any comprehensive in depth material. In fact, I can't even find any class descriptions. I've tried looking at the source, but at this point, thats not real helpful.
Is there some information out there I am missing? How do you go about learning this thing from scratch. Maybe I have just been spoiled by the amount of documentation out there for Java and C++, but it still seams to me that there must be some method for learning this thing, otherwise there would be know one using it.
So if you guys have suggestions I would love to hear them.
Thanks, Eric
__________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Hi, Eric.
I would like to add my voice to yours. I have considerable Smalltalk experience, but not Squeak, and hence not Morphic. Someone else will have to answer your question, but I suspect that Squeak/Morphic is like so many other open source projects: programming is fun but documentation is not, at least as a general rule among programmers. The Morphic classes are there: * pick favorite morphic project and * bring up it's halo, * select menu->debug->browse morph class. That might get you started exploring.
On Thursday 31 October 2002 12:32 pm, Eric Merritt wrote:
Hello All,
To begin with, if this is not the correct list to post to for these kind of questions please direct me to the correct list. With that out of the way, on to my questions and comments.
I have recently (within the last few days) discovered SmallTalk and Squeak in general. Oh, I have heard about SmallTalk in the past and even Squeak but I never picked it up for a number of reasons. In any case, I have been looking for a good productive cross platform language that has excellent support of a GUI interface. These criteria made finally me stop and look at both SmallTalk and Squeak in particular. I am glad I did. After reading some of the docs and playing around with the environment I already like it allot. In fact the code browser reminds me a whole lot of VisualAge for Java, one of my favorite IDEs. Of course, Now I found out that why VisualAge for Java resembles Squeak and other SmallTalk environments, I assume lol.
Ok so now I am all hyped up ready to write some code and get a feel for the environment, particularly Morphic which is what drew me here in the first place. Alas this is where I fall flat on my face. There are a few very simple tutorials out there, but there doesn't seem to be any comprehensive in depth material. In fact, I can't even find any class descriptions. I've tried looking at the source, but at this point, thats not real helpful.
Is there some information out there I am missing? How do you go about learning this thing from scratch. Maybe I have just been spoiled by the amount of documentation out there for Java and C++, but it still seams to me that there must be some method for learning this thing, otherwise there would be know one using it.
So if you guys have suggestions I would love to hear them.
Thanks, Eric
Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Eric Merritt wrote:
So if you guys have suggestions I would love to hear them.
The Squeak Swiki is the best place to find this kind of documentation. http://minnow.cc.gatech.edu/squeak/ A nice morphic intro is at:
http://minnow.cc.gatech.edu/squeak/1253
Karl
Hi Dean,
I'm not sure that I understand your concern. Modularizing the image would be a very good thing in my view of the world. In fact, I think it's required in order to build the kind of task-specific system you prefer.
Modules would let us build custom images for specific purposes, rather than attempt to make the standard image flexible enough for any purpose. If I'm using Squeak for a web application, I don't need an MPEG player in the image. If I'm developing a MIDI application, I don't need Comanche.
With the monolithic image, we get bitten coming and going. Not *everything* can be in the standard image, so we frequently have to file in additional classes to get the functionality we need. With the current system this a hassle, much more difficult than it needs to be. On the other hand, the standard image has a bunch of stuff that won't get used most of the time, and removing it from the image is a more than a hassle, it's a nightmare, not to be attempted by mere mortals.
So by all means lets consider our goals carefully. I really like the scenario that's emerging from the interaction of SqueakMap and DVS. I hope that we can arrive at a very basic kernel in the image, with easy-to-install packages available from SqueakMap.
Cheers,
Colin
On Wednesday, October 30, 2002, at 01:46 PM, Swan, Dean wrote:
What 3.3a is trying to do with modules is essentially opening the same can of worms that has made MS Windows such a maintenance nightmare. Modules are (more or less) equivalent to .DLLs and may end up with all the associated issues. I don't know of any "good" solutions to these problems, but as attractive as the "idea" of modules is, I am personally content to stick with monolithic images for the forseeable future.
The whole concept of "software components" is IMO a fantasy propagated by media hype that ignores all the realities of real world engineering. In "real" hardware product designs, one often finds that re-usability is more of a structuring concept than a hard reality. I don't believe I've ever worked on a hardware design that didn't involve some kind of custom connector that is a "slight" variation of a "standard" connector, for example. (Just for context, I'm referring to everything I've worked on in the last 12 years or so).
I think the concept of a monolithic image constrains the reusability myth to realistic proportions, and makes implementation possible. Too much flexibility comes at a cost, which usually rears its ugly head in the form of increased complexity, higher resource requirements, and reduced preformance (relative to a less flexible implementation).
As an example of what I'm talking about, I've worked on a couple of different projects in the last few years where the end product has similar capabilities but one was implemented using a "flexible, reusable platform approach" and the other was implemented using a more task specific approach.
The flexible system has a source tree for the "platform" of about 5 gigabytes, generates a target image of about 170 megabytes, and needs two 300 MHz PowerPC 603e's and 512M of RAM to run. This system has hundreds of developers working on it.
The "task specific" system has a source tree of about 300 megabytes, generates a target image of about 1 megabyte, and runs on one 66 MHz PowerPC with 16M of RAM. This system had 4 developers working on it. The end functionalities of these two systems is *very* similar.
I'm not sure what my point is in all of this, but I think we should consider our goals carefully in relation to the questions that Andrew has raised. My preference is towards "lean and mean" rather than "incredibly flexible, general purpose (and suboptimal)".
Colin Putney Whistler.com
sle, it's a nightmare, not to be attempted by mere
mortals.
So by all means lets consider our goals carefully. I really like the scenario that's emerging from the interaction of SqueakMap and DVS. I hope that we can arrive at a very basic kernel in the image, with easy-to-install packages available from SqueakMap.
Cheers,
Colin
He's implying we'll end up with the equivalent of DLL Hell that Windows ( and to a lesser extent ) windows have.
Linux survives in the fact that diff versions of the same libs can live together happily by using symbolic links, and ld. Simple, and works better than windows registry pain....
Modules MUST support version dependency, and different versions of the same modules living on the host system if this is to work...
Read up on PIE and Traits, these ideas could solve our problems...
-Daniel
Daniel Joyce wrote the following in reference to Dean Swan's post :
He's implying we'll end up with the equivalent of DLL Hell that Windows ( and to a lesser extent ) windows have.
Linux survives in the fact that diff versions of the same libs can live together happily by using symbolic links, and ld. Simple, and works better than windows registry pain....
Modules MUST support version dependency, and different versions of the same modules living on the host system if this is to work...
I agree that packages should be versioned, and that dependencies should include version information. But I also think that having multiple versions of a package installed in a single image would not be a good idea. The benefits are not worth the complexity it would require.
Consider that images are not the same as operating systems. Linux can have multiple versions of a library installed and allow different executables to link against the versions they require. But you can't have two different versions of a library linked into the same process space. The Squeak parallel would be to have multiple versions of a package available on SqueakMap and have different versions installed in different images.
Now consider the complexity supporting this would introduce to Squeak. The VM would have to take dependencies into account during method lookups. You'd have to have separate namespaces for globals. The Browser would have to present multiple versions of methods to the user, the Compiler would have to store compiled methods in the right namespace etc. That's all possible of course, but it's a low-level, far-reaching change with deep implications.
And then there's the complexity cost at the user/developer level. Can you imaging debugging in an image where there are different versions of the same method floating around and the version that actually gets execcuted depends on the class of the sender? Dear God!
Colin
----- Original Message ----- From: "Colin Putney" cputney@whistler.com To: squeak-dev@lists.squeakfoundation.org Sent: Thursday, October 31, 2002 1:38 AM Subject: Re: An uncomfortable question
Daniel Joyce wrote the following in reference to Dean Swan's post :
He's implying we'll end up with the equivalent of DLL Hell that Windows ( and to a lesser extent ) windows have.
Linux survives in the fact that diff versions of the same libs can live together happily by using symbolic links, and ld. Simple, and works better than windows registry pain....
Modules MUST support version dependency, and different versions of the same modules living on the host system if this is to work...
I agree that packages should be versioned, and that dependencies should include version information. But I also think that having multiple versions of a package installed in a single image would not be a good idea. The benefits are not worth the complexity it would require.
It is a bit early to state it that emphatically. There is no evidence to support the notion that having this ability would be any more complex in practice than not having it, as we do now. You are used to the situation we have now... so you think of it as being "simple", by virtue of familiarity. As long as we arbitrarily ignore the vast amounts of code which are *not* routinely packaged in the official release, then certainly we can "simplify" the problem. However, if you now want to consider what it takes to use all those other bits of code, then we find that there is a fair bit of missing tool support to make this job easier. Deliberately choosing to neither develop nor use such tools does not "simplify" life.
Consider that images are not the same as operating systems. Linux can have multiple versions of a library installed and allow different executables to link against the versions they require. But you can't have two different versions of a library linked into the same process space. The Squeak parallel would be to have multiple versions of a package available on SqueakMap and have different versions installed in different images.
Or provide the means to support multiple versions in the image simultaneously. Nontrivial, but feasible and already largely demonstrated in Oasis. But at a higher level I'd reccomend that we consider that OS's do a lot of things much better than what we are doing "within" the image right now. It is worth considering ( as I believe Stephen Pair once suggested ) a comparison and contrast between Squeak/Smalltalk/image and OS/file systems. To wit: in an OS, having something be *available* to use is not the same thing as *demanding* that it already be in memory. And when done using that thing, it goes away. Compare that to the way in which we currently manage our images. There is a big realm of transient things that are not managed at all- we load them at some point, and from that point on, they stay in the image, because we do not have tools to identify the extent of these things and what is needed to remove them. I just don't see how deliberately deciding to never develop such tools will ever be a good thing.
Now consider the complexity supporting this would introduce to Squeak. The VM would have to take dependencies into account during method lookups. You'd have to have separate namespaces for globals. The Browser would have to present multiple versions of methods to the user, the Compiler would have to store compiled methods in the right namespace etc. That's all possible of course, but it's a low-level, far-reaching change with deep implications.
The specifics are not exactly what I'd anticipate, but the gist I agree with- very deep impact at a low level, decidedly non-trivial. However, technically feasible- a big chunk of this is already working rather well in Oasis.
And then there's the complexity cost at the user/developer level. Can you imaging debugging in an image where there are different versions of the same method floating around and the version that actually gets execcuted depends on the class of the sender? Dear God!
Having method lookup based partially on the sender is actually vital and neccessary if this is all going to work coherently... the easiest way to understand this is to ask yourself, "when travelling overseas or in another country, do I continue to behave according to my own culture's beliefs and values, or do I adopt the behaviors of the country I'm visiting?" Things go a lot easier when you do your best to respect and blend in with the local customs. In our Smalltalk world, this means that objects crossing domain ( or module or whatever ) boundaries need to behave according to the local customs ( ie, methods which may have been provided/altered for them by the module/domain they are visiting ) of the domain that they are visiting. This makes it trivial to reason about the behavior of say, OrderedCollection, when instances are zooming through Module X or Module Y, where X & Y provide differing behavior for OrderedCollections. Also perhaps non-trivial, but I believe that Stephen Pair has some form of selector namespaces already working.
Take care,
- les
Sorry but I disagree. The fact that 3.3a modules were not usable is just due to the lack of push, the fact that the image is a ****messy**** state with lot of references everywhere, and a too complex module model.
We need modularity. Lot of people are fed up to not be able to logically identify why when there is a new changes in the system their code breaks. Or to have to remove from the image stuff that does not interest them at all. Having modules, I prefer packages for code grouping issues is key the future of Squeak. Look at how daniel manages RB out of the image. If I want RB I load it. (even if RB should be the base browser but this is another discussion).
You miss a key point: an image is not an entity for deployement and code management and there is nothing in packages that goes against image. These two concepts are NOT ENEMY. Imagine a small image like in GNU Smalltalk where you can configure what you want to have in and a server where you can select what you want in. You click and hop you get a new image. You code, publish your code and hop you able to REBUILD your image. I'm also able to load your code and all the dependent packages. Without having nightmare to know which changeset should be loaded and why my system is getting unstable because I forgot to load this tiny cs.
If I do not need Music, eToy, Chess, why do I need them in my image?
Image are cool for developping, I loved them, saving your objects for coffee breaks with the mouse on the right line of the debugger but not for deployement and source code management.
Stef
On mercredi, octobre 30, 2002, at 10:46 pm, Swan, Dean wrote:
What 3.3a is trying to do with modules is essentially opening the same can of worms that has made MS Windows such a maintenance nightmare. Modules are (more or less) equivalent to .DLLs and may end up with all the associated issues. I don't know of any "good" solutions to these problems, but as attractive as the "idea" of modules is, I am personally content to stick with monolithic images for the forseeable future.
The whole concept of "software components" is IMO a fantasy propagated by media hype that ignores all the realities of real world engineering. In "real" hardware product designs, one often finds that re-usability is more of a structuring concept than a hard reality. I don't believe I've ever worked on a hardware design that didn't involve some kind of custom connector that is a "slight" variation of a "standard" connector, for example. (Just for context, I'm referring to everything I've worked on in the last 12 years or so).
I think the concept of a monolithic image constrains the reusability myth to realistic proportions, and makes implementation possible. Too much flexibility comes at a cost, which usually rears its ugly head in the form of increased complexity, higher resource requirements, and reduced preformance (relative to a less flexible implementation).
As an example of what I'm talking about, I've worked on a couple of different projects in the last few years where the end product has similar capabilities but one was implemented using a "flexible, reusable platform approach" and the other was implemented using a more task specific approach.
The flexible system has a source tree for the "platform" of about 5 gigabytes, generates a target image of about 170 megabytes, and needs two 300 MHz PowerPC 603e's and 512M of RAM to run. This system has hundreds of developers working on it.
The "task specific" system has a source tree of about 300 megabytes, generates a target image of about 1 megabyte, and runs on one 66 MHz PowerPC with 16M of RAM. This system had 4 developers working on it. The end functionalities of these two systems is *very* similar.
I'm not sure what my point is in all of this, but I think we should consider our goals carefully in relation to the questions that Andrew has raised. My preference is towards "lean and mean" rather than "incredibly flexible, general purpose (and suboptimal)".
-Dean Swan
-----Original Message----- From: Les Tyrrell [mailto:tyrrell@canis.uiuc.edu] Sent: Thursday, October 24, 2002 8:15 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: An uncomfortable question
These are important points- as we move forward, I am hoping that we will be moving towards a model in which individual pieces of code are liberated as much as possible from unneccessary constraints on their usage. That is going to require a rather significant change in a lot of Squeak's infrastructure, but I am rather impressed with how much progess is being made by a lot of people in terms of understanding those issues, or at least recognizing them. The days of the monolithic image ( and the inherent weaknesses and roadblocks to progress that it represents ) are, hopefully, numbered.
- les
----- Original Message ----- From: danielv@netvision.net.il To: squeak-dev@lists.squeakfoundation.org Sent: Thursday, October 24, 2002 3:41 PM Subject: Re: An uncomfortable question
Well, I think something interesting is happening in SqueakMap. The count is now up to 16 packages, by 8 different authors. These range from small framework additions like SharedStreams to large projects that would be unlikely to ever become available through the Squeak base image, like Seaside.
This opens up directly possibilities to maintain other projects outside the image too, like Celeste, Scamper and others.
All this should reduce the maintainance effort required of SqC, and let the community do experiments in various directions without actually requiring a fork.
A case in point - if Henrik's code was first debuted as a SM package, it would have gotten earlier feedback, it could have been more modular, it would have been easier for people to try out and it would have been optional, orthogonal to the harvesting work done on 3.3a.
This would have saved us at least one uncomfortable question.
So I think one important thing to consider is how we take full advantage of this new option we have as a community, and how we change our process to fit it in.
Dr. Stéphane DUCASSE (ducasse@iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes
squeak-dev@lists.squeakfoundation.org