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