From: [...] Cees de Groot 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)
Well, quite. You didn't expect me to spoil a one-sided email like that by weakening my case, did you? ;-)
BTW - I'm thinking that we could decide to "just do it".
I think Craig already has. Like most prophets and visionaries, he has confused a lot of folks in the process.
it is a whole lot better than what we've got now and could be done immediately, just by deciding to do it.
And that, I would argue, is a key point. As Craig has found, one person 'just doing' works for that person. As we have found on this list, a large group delegating a few people to go away and debate something then maybe do it sometime... doesn't work either, as the frictional costs are too high and nobody in the small group wants the results enough.
This is actually a third problem with Squeak as an OS project... It's too big, and does too many things, none well enough to be best-of-breed. So there's always a better tool to use for any particular problem. Who would rally round the new, slimmer image? Certainly not the Croquet/Teatime crowd. Not the UI folks. It wouldn't do multimedia... Really, it's a bit difficult to know who would take it and use it.
This shouldn't stop somebody doing it, however, and publishing the result; that way, people might pick it up and use it. But that 'somebody' should need/want it *for themselves*, so that they'll put the effort in.
But by Just Doing It, we could actually attempt to tackle these issues instead of constantly debating them.
Quite.
(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 ;)).
Quick, find an academic and publish a paper :-).
- Peter
On 31-Jan-05, at AM 01:20, Peter Crowther wrote:
This is actually a third problem with Squeak as an OS project... It's too big, and does too many things, none well enough to be best-of-breed. So there's always a better tool to use for any particular problem. Who would rally round the new, slimmer image? Certainly not the Croquet/Teatime crowd. Not the UI folks. It wouldn't do multimedia... Really, it's a bit difficult to know who would take it and use it.
I would, as a web application developer using Seaside. Assuming that most people only uses and knows one area (out of web application frameworks, multimedia, etc), would it not be good if we have a slim image that includes only the bare essentials? That would reduce any unnecessary dependencies and also allow each group of people to focus on/test their part more easily. And hopefully for each group of people, a fatter image/distribution will be adopted, with the slim image as the base. Someone mentioned the reverse of majorShrink (sorry, forgot the name and the person's name), I thought that sounds good.
-- HweeBoon MotionObj http://motionobj.com (65) 6764-9774
On Jan 30, 2005, at 9:20 AM, Peter Crowther wrote:
From: [...] Cees de Groot 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)
Well, quite. You didn't expect me to spoil a one-sided email like that by weakening my case, did you? ;-)
BTW - I'm thinking that we could decide to "just do it".
I think Craig already has. Like most prophets and visionaries, he has confused a lot of folks in the process.
it is a whole lot better than what we've got now and could be done immediately, just by deciding to do it.
And that, I would argue, is a key point. As Craig has found, one person 'just doing' works for that person. As we have found on this list, a large group delegating a few people to go away and debate something then maybe do it sometime... doesn't work either, as the frictional costs are too high and nobody in the small group wants the results enough.
This is actually a third problem with Squeak as an OS project... It's too big, and does too many things, none well enough to be best-of-breed. So there's always a better tool to use for any particular problem. Who would rally round the new, slimmer image? Certainly not the Croquet/Teatime crowd. Not the UI folks. It wouldn't do multimedia... Really, it's a bit difficult to know who would take it and use it.
I strongly agree with the need for a small core and packaged extensions above that, and that Squeak is trying to do too much. I would stress that my perception of squeak is that it is trying to do far too much for the resources available. It shows all the signs of a project that is barely keeping its head above water. There are major parts of the system with no documentation, no class comments, no way for anyone but the author to have a clue about what the code is SUPPOSED to do. This means it is unmaintainable in the long run. There are an equal number of areas where the code is unfinished to a large degree. Much of the code is just barely good enough for what it is currently used for, while having pretensions of being more general. This lack of quality in the design and implementation is understandable for research projects that are more interested in trying out an idea than producing a solid product, but the effort required to use Squeak in a product appears huge at present. There is a lot of code that would need serious maintenance effort on code that is going to be hard to maintain, and hard to get changes accepted into. Money is never going to flow into a project that is in this state. And money in the form of services or development dollars is what it is going to take to get enough resources on this project to produce a clean product. The successful open source projects are those that are used commercially, because they get resources from vendors, and employers using the software. Unfortunately too much of Squeak has been built for research or hobby motivations.
Nothing of the above is critical of any individual or group. There are pockets of people putting a lot of effort into this system, and it has some huge architectural advantages. But to be successful the community is going to need to take itself more seriously and hold itself accountable to a higher standard of what goes into the product. To do that the core must be smaller so it can retain its quality while supporting packages that can have any focus and quality they want.
People like open source projects because they can fix issues that arise, but that does not mean they want to fix them. In general the level of bugs and quality of implementation is more important to adoption than the level of features.
This shouldn't stop somebody doing it, however, and publishing the result; that way, people might pick it up and use it. But that 'somebody' should need/want it *for themselves*, so that they'll put the effort in.
But by Just Doing It, we could actually attempt to tackle these issues instead of constantly debating them.
Quite.
(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 ;)).
Quick, find an academic and publish a paper :-).
- Peter
Hi,
We are all still here so we can't be that bad.
IMHO we do not need to add more/less to the image or langauge.
Perhaps we should just complete the things we have done. By way of example...
1. There are 3 HttpClient implementations, which is fully HTPP1.1 compliant. 2. Comanche is not HTTP1.1 compliant. 3. There are multiple Socket implementation in various states of completion.
Pretty important for a community which, in this thread at least, has emphasised, the importance of networking.
4. The old compiler does not have closures. 5. The new closure compiler is slow (see Andreas Raab's comments) and does not decompile blocks.
Pretty important stuff.
6. Do all the test in the 3.8gamma image work, did they ever ?
$0.02
Brent
Perhaps we should just complete the things we have done. By way of example...
- There are 3 HttpClient implementations, which is fully HTPP1.1
compliant. 2. Comanche is not HTTP1.1 compliant. 3. There are multiple Socket implementation in various states of completion.
Oh, I once tried to get rid of OldSocket and adapt the rest to work with Socket. I went to some point where it was done but after all that I was pretty frustrated as I started to recognize all the mess. One example for all. If you look into Network-Protocols category you will find quite nice hierarchy such as
ProtocolClient -> TelnetProtocolClient -> SMTPClient
Even though TelnetProtocolClient stands for something rather telnet-like (it's not implementing RFC854), I was very happy with that. So leading conclusion was to have HTTPClient subclassed from TelnetProtocolClient (which can be renamed without harmful consequences). But suddenly, you will find that some $&*(#@*($^ introduced HTTPClient totally out of this concept. Now solve the dilema:
- rename HTTPClient to HTTPHelper or whatever and write nice HTTPClient. Not hard to imagine that even if you adapt the rest of image, all packages' maintainers relying on HTTPClient would like to kick your ass.
- leave it as it is and just keep that mess arround. Of course, pray someone won't write IMAPClient or XYZClient derived from Object and pissing all this concept.
Luckily helper HTTPClient has no instance methods so it can me merged with ProtocolClient concept though it brings such a beast into the image. Maybe best compromise.
Pretty important for a community which, in this thread at least, has emphasised, the importance of networking.
Yes, and I see there are unresolved problems with handling errors in socket communication but I feel it's maybe something simply unsolvable within current design. Any other development environment is better in this and other issues. No wonder, that even though I can amaze people with rotating windows, I simply can't rely on it as development platform. It is really a shame.
Hi Kamil,
Yes, and I see there are unresolved problems with handling errors in socket communication but I feel it's maybe something simply unsolvable within current design. Any other development environment is better in this and other issues. No wonder, that even though I can amaze people with rotating windows, I simply can't rely on it as development platform. It is really a shame.
This is precicely the problems we are talking about.
however, let me assure you that this problem occurs in every environment - my sad forray into Java discovered no less than 5 separate implementation of a Date class!
Other languages simply refuse to address this problem by usgin namesspaces. This allows the duplication to the tolerated but does NOT fix it. Squeak's single namespace expses this duplication earlier which should allow us to fix it to build the One True RFC Compliant HttpClient class.
This downside of namespaces has been repeatedly emphasised by Andreas Raab.
In this case I would petition the maintainers of the various HtppClient species and the Comanche/Seaside crowd to converge on the One True version.
Brent
On Tue, 08 Feb 2005 07:53:52 +0200, Brent Pinkney brent.pinkney@aircom.co.za wrote:
This downside of namespaces has been repeatedly emphasised by Andreas Raab.
Hey, fun, a namespaces discussion! ;-}
My 2 cents: I used VW with namespaces, and Java with namespaces, and both not in hobby projects but in multimultimanyear projects. The way they've implemented them, I don't like them.
Ok, another cent: partitioning (Squeak-E, Islands style) probably solves that problem and a slew of others as well.
On Sun, 30 Jan 2005 17:20:57 -0000, Peter Crowther Peter@ozzard.org wrote:
Who would rally round the new, slimmer image?
Well, force the issue. The PowersThatBe[tm] as far as the core/minimal/full image thing is concerned, are the Guides. If they declare that for the coming version x.y, the Guides feel themselves only responsible for: - core image; - building minimal/full from packages; then you can choose to fork your thing or play ball by packaging your stuff and maybe some stuff your stuff needs (I'd gladly help packaging wxSqueak, Seaside, because I depend on it; others will have other itches to scratch).
It's a risk. But it's a risk worth taking, because I feel that a) the concensus that this must be done, sooner or later, is there, and b) the PowersThatBe have enough weight in the community that people will cooperate, rather than fork.
squeak-dev@lists.squeakfoundation.org
-
Brent Pinkney -
Cees de Groot -
Kamil Kukura -
Michael Latta -
Peter Crowther -
Yar Hwee Boon