> The "perfect" approach to building new systems would be, I 
> think, the "burn the diskpacks" way: If you want to do something
> new, throw the old stuff away and start from scratch, using all
> the knowledge you learned.
> 
> But this seems to me not very practical anymore: This was a great way
> for the 70ties, but the sytems we are building are too big for that
> today.

I disagree. The question is what kind of system you want to build (e.g.,
which disk packs exactly you want to burn) because typically, there are many
things that you may want to preserve.

> Just take croquet: I don't think something like that would
> be possible to build that fast "from scratch".

So what does "from scratch" mean here? Should we have started building our
own development environment first? Our own language? Our own hardware? As
far as I am concerned, Croquet is being built from scratch.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Marcus Denker
> Sent: Friday, July 25, 2003 1:02 PM
> To: The general-purpose Squeak developers list
> Subject: Re: [ENH] SocketStream ascii/binary and nextAvailable
> 
> 
> On Fri, Jul 25, 2003 at 01:04:18PM +0300, Daniel Vainsencher wrote:
> > What I mean by the last issue is that namespaces don't solve the
> > integration problem, they just make its pain less direct. 
> Whether this
> > is more of a benefit than it is a liability I think is a tricky
> > question.
> > 
> Yes, you are right... but I think that the benefit could be greater,
> if such a system is used with care: e.g. it would be no good idea
> to ship the image with two versions of the library, and have parts of
> the image using the old one and parts the new one... this should be 
> used only for packages that build on top of the image and while
> migrating the image towards new version of a subsystem. 
> 
> The "perfect" approach to building new systems would be, I 
> think, the  
> "burn the diskpacks" way: If you want to do something new, 
> throw the old 
> stuff away and start from scratch, using all the knowledge 
> you learned.
> 
> But this seems to me not very practical anymore: This was a great way
> for the 70ties, but the sytems we are building are too big for that
> today. Just take croquet: I don't think something like that would
> be possible to build that fast "from scratch". You need to have a
> good and proven basis, especially if you try to jump into the blue 
> plane... 
> 
> The same is true for the black-plane people (black plane: 
> "doing things
> with squeak that were old even before squeak was invented" or: that
> stuff you need to do to get food on the table): Using Squeak as a 
> "free visualworks" requires a system that is somewhat stable in the
> sense "I can update and my stuff will be up and running again with
> not-too-much work".  
> 
> So, interestingly, both blue and black needs something to build upon.
> The problem is: This makes changing the system very difficult. 
> Even ignoring the "black plane": As soon as you have two groups doing
> blue plane stuff, you will have a clash: The blue-plane-part of the
> person will be the basis of the other... 
> 
> So to make real progress possible (esp. in the blue plane) we need
> a system that is stable *and* mealable. A big part of this is adding
> more late-binding to the system: Meta Object Protocols are a nice
> example for that. By providing a protocoll (API) for changing (or
> hooking into) the implementation of the system itself (e.g. changing
> method lookup), you can go very far in experimentation 
> without hurting 
> others....
> 
>        Marcus 
> 
> -- 
> Marcus Denker marcus at ira.uka.de  -- Squeak! http://squeak.de
> 
>