> From: [...] Lex Spoon
> 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.

True enough.  And they all hack at the code that supports all the
projects for their own benefit, with no regard for each other and little
to no co-ordination.  After all, this is a *personal* computing
environment.  Then those changes get filed out, and some poor sod has to
deal with the result - whether harvester, or just someone who tries to
load >1 package from SM and gets bitten by incompatible changes.

> 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. 

That's fine, and I agree with the analogy *of use*, but I don't agree
with the analogy *of development*.  Where's chroot() and
LD_LIBRARY_PATH?  How on earth do I, as a developer of an application
inside a larger environment, insulate myself from the chaos around me?
At least the Linux folks *know* that if they replace libc, things are in
general going to foul up.  They know what their dependencies are - hell,
you can even *list* them with ldd.  How do we prevent changes to (say)
Object that cause breakage elsewhere in the image?  How do we even know
what has changed and might break our code?

Given your OS analogy, it's as if libc can change (and break all the
other apps that use it) every time you import a package.  It's DLL hell,
doubled and redoubled.  Microsoft tried to address this with smarter
installers that didn't replace newer libraries with old, better backward
compatibility... Then they threw their hands up, admitted it would never
work, and allowed side-by-side assemblies.  UNIX has had library load
paths for decades.  Squeak is getting as large as those systems were
when they encountered the problems, and has none of that isolation.

> (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.)

Agree.

> PS -- why do we see so many depressed posts?  Things seem to be
> progressing nicely, to me.

In every other environment I use, I have a pretty good idea that I can
maintain my code with little effort.  In Squeak, I'm running the Red
Queen's race - I'm trying to keep up with the shifting codebase around
me.  Dunno about anyone else, but my own depression* is about the amount
of time I have to spend fixing my code due to external changes.  That's
no fun; I enjoy cutting new code, not playing catch-up.

If I were on Linux, I would not expect to have to change the code I use
for Web-serving just because I've installed a new game.  Why should I
have to do this in Squeak?

		- Peter

* wrt Squeak; other issues may be contributory :-(.