Re: An uncomfortable question

On Wednesday, October 30, 2002, at 05:33  PM, Swan, Dean wrote:

> Colin,
>
> Consider the case where there are dependencies between the modules and 
> more than one version of each module.  The current effort of 
> implementing modules is attempting to deal with these issues, and it 
> is a non-trivial problem.  It is also possible that because of certain 
> interdependencies between different versions of different modules that 
> some modules may become mutually incompatible.  This situation is 
> witnessed with MS Windows .DLL libraries quite often.
>
> One common effect is that some applications have to be installed on a 
> Windows machine in a particular order in order for them to all 
> function properly on the same machine.  There can arise instances 
> where because of different sets of .DLL versions required, a set of 
> applications may not all function correctly on one machine.

Well sure, incompatibilities between different parts of the system is 
always a danger. Certain parts of the system expect particular 
behaviour from other parts of the system. If you make changes you run 
the risk of violating those expectations. This is true whether those 
parts are modules, classes, functions or DLLs.

The nice thing about Squeak is that you can have multiple images lying 
around. So if you need different versions of a module in different 
situations, you do that without having to say, swap out your hard drive 
when switching between applications.

Now, this is not to say that dependency tracking, versioning and so on 
is a non-issue. It is a problem that we're going to have to address.  
But the ability to build images for specific purposes is a mitigating 
factor. So when we do have incompatibilities between modules - and it 
will happen - instead of "hell" we're faced with a mere problem.

> And regarding SqueakMap and DVS, realize that these are based on the 
> monolithic image model.  They are more or less fancy user interfaces 
> to manage filing in the various change sets (I know I'm 
> oversimplifying a bit, but the point is still valid).

Hmm. It sounds like we have different definitions of "monolithic." When 
I speak of modularizing the image I mean grouping the code into 
clusters of classes and methods that a) provide a distinct and coherent 
piece of functionality, and b) interact with other clusters through 
well defined interfaces. Once that's accomplished (and yes, it's a 
non-trivial task) many of the clusters can be removed from the base 
image and maintained separately.

I place that scenario opposite the "monolithic" system used by Squeak 
3.2. Everything is really intertwined and you can't easily remove any 
functionality from the image. Adding functionality is easier, but still 
quite a hassle because of the some what artificial distinction between 
"blessed" code that's maintained by SqC and other stuff, which is 
floating around in ChangeSets.

So again, I don't think I understand your concern. Are you saying that 
you prefer the SM/DVS route to 3.3 modules? How do you define "modular" 
and "monolithic?"

As to SqueakMap and DVS, sure. They really are just tools to make it 
easier to move code in and out of images. But that's the point! The 
whole problem here is that it's difficult to manage code.

> Of course, monolithic systems have the issue of shared namespaces 
> which can make it difficult to make different packages play nice 
> together in the same image, so like I said, the problem is > non-trivial.
>
> While it would certainly be possible to produce an MPEG player image, 
> with only the items necessary to play MPEGs, and a MIDI image with 
> only the items needed for MIDI processing, and so on, factoring out 
> the common components can be difficult.  This is especially true when 
> some "applications" use different versions of a particular component 
> and rely on some characteristic behavior.  A hardware example of this 
> is the 4046 phase locked loop IC.  It is a fairly standard part, BUT 
> the Motorola Version and the Philips versions are incompatible in that 
> the external timing components require different values to get the 
> same frequency out of the two parts.  The same kind of thing can 
> happen in software.

No, it's not trivial, but it can be solved, and it's not even all that 
difficult.

For one thing, the package model used by DVS makes the problem easier 
by virtue of its inflexibility. A given package can contain classes and 
methods. When a package is loaded, it can create classes and it can add 
methods to existing classes. It cannot modify methods belonging to 
another package, and it can't delete methods. So it avoids all kinds of 
problems that can arise when modules can modify each other.

A second factor that makes the problem tractable is that Squeak images 
offer developers much more control over the execution environment than, 
say, a desktop operating system. For development, you can build an 
image that has exactly the configuration you need - all the right 
packages, of the right versions, loaded in the correct order. For 
deployment, you just distribute that image. There's no need to have 
users load your package into whatever randomly configured system they 
happen to be running. That's the situation that creates DLL hell and it 
just doesn't apply to Squeak.

And finally, if you do run into a compatibility problem, just fix it! 
The source code is there, there's a community of people willing to 
help,  and with SqueakMap and DVS, you've got the tools to easily 
distribute your fix to the rest of the community and to easily benefit 
from their efforts. As Daniel mentioned, we've got a social advantage 
over the commercial world.

Cheers,

Colin