Hi Lex -

Lex Spoon wrote:
> Your argument here is that feature X allows modules to mess each other
> up. The perfect module system must absolutely forbid modules to mess
> each other up.  Therefore, X is disallowed.

No, this is not my argument. My argument is that I don't get any say in 
whether these modules should affect each other in this way or not. There 
are perfectly reasonable situations (loading patches, trying to build an 
application) where you *want* these modules to affect each other.

> The components utopia is the second to last sentence: The perfect
> module system must absolutely forbid modules to mess each other up.
> That's obviously too extreme, right?  Utopian, some might say?

It depends on what you mean by "absolutely forbid to mess each other 
up". What I would expect from the "perfect" module system is to allow me 
the formulate the equivalent of both, saying "I want these two modules 
on different computers", in other words "perfectly isolated" or 
alternatively to specify "I want these modules to affect each other", in 
other words "patch module X with module Y". Both are perfectly 
reasonable, and I simply don't get why you completely disregard the 
former in favor of the latter. There is *nothing* utopian about it - I 
run different versions of modules on different computers all the time 
and I patch modules with others all the time. And they communicate with 
each other all the time.

> Believe me, I do not mean to beat up on your simplification here.
> It's just a simplification.  Perhaps, though, if you try to be more
> precise here, then there is a deeper understanding to be had.  What,
> precisely, does it mean for modules to allow *limited* interaction, as
> opposed to the extremes of non-interaction or blatantly stepping all
> over each other?

I would define "limited interaction" as: Limited to *explicit* 
interaction, e.g., sending messages requesting services contrasted with 
*implicit* interaction, caused merely by loading a code base that has an 
(unintended) side effect on another module. In other words, if module A 
uses a public API to tell module B it wants "Foo" to mean "Bar" that is 
much more acceptable than the effect that merely loading A has the 
effect of "Foo" meaning "Bar" (the simple reason being that module B can 
deny the request if it is explicit; and that other modules are aware 
that Foo may mean Bar and can guard against that possible problem).

> Curiously, component systems can succeed even when they allow lots of
> interference between packages.  I'm thinking of Debian packages.
> Debian packages are your nightmare, Andreas: practically everything is
> in a global scope, just begging for inter-package conflicts!  Yet,
> Debian manages to produce 10k of these packages which all get along
> together.  How can this be?

Do they? Really? We are currently living through the equivalent of 
DLL-hell on Linux, and let me tell you, it is *much* worse than the 
situation currently on Windows and MacOS. MUCH worse. For example, on 
Windows we ship certain DLLs with our commercial app (trivial; just drop 
them into the binary directory) and that works with every binary on 
Windows regardless of whether other versions of the same library are 
installed on the system or not. On MacOS it's harder, but still doable; 
you need to patch the binary a little to use "your versions" of the 
library but again, it's doable. On Linux? Well, we just gave up on one 
particular product we were planning to use simply because it couldn't 
even agree on the C runtime libraries to use! Sorry Lex, but I think 
Linux is not exactly the benchmark in this area.

> I think their success is due to how they set up their package sharing.
> Debian has a great answer to the following question: what do you do
> when, as is inevitable, two packages conflict?

You run them side-by-side. That strategy was ultimately the way out of 
DLL-hell on windows (compared with previous versions, this problem has 
ceased to exist since XP). Windows, starting with XP (and even more 
extreme on Vista) has explicitly adapted that strategy to the point 
where even patching system DLLs means your app gets their "private 
versions" of those DLLs instead of silently side-effecting others. The 
same is true on MacOS (with a bit more explicit programmer effort since 
historically MacOS didn't have the problems). However, in both cases the 
result is the same: Applications with different requirements in terms of 
the libraries required can run side-by-side and *still* communicate with 
each other using a variety of APIs. They are not *required* to affect 
each other, they can if the integrator (usually the app) decides to, but 
if the integrator doesn't, they can also live perfectly happy side-by-side.

Cheers,
   - Andreas