Why Modules???????
			------------------

			Michael S. Noble
		      mnoble@space.mit.edu
			   12/08/2003


When we mention modules or packages we are referring to small-ish bits of
software which exist outside of any particular program, and which are
loaded by explicit user request, such as

	import("histogram");
or
	evalfile("vwhere");

after a program has been invoked.  While the rest of this section will
use the term "module" to refer to both modules and packages, note that
modules are binary code, while packages are human-readable scripts.

Now, given the fact that modules are essentially useless until they've
been loaded into some parent application, one might wonder "Why all the
fuss?" Well, there are many reasons, of which here are several:

One is that the function of programs endowed with the capacity to load
modules can be dynamically increased while the programs are running.
Such programs are said to be extensible, and in fact some programs
(such as GIMP or Mozilla) even refer to modules as extensions.  The
ability of a program to grow, potentially through the work of external
parties, beyond its creator's initial conception, provides a great
evolutionary advantage over the traditional application, which is
conceptually organized as self-contained entity, intended to provide
only the function available when the program is invoked, and only in
the manner conceived of by its author(s).

Robustness and maintenance may also be enhanced.  In the extensible
model the internal cores of programs may remain unchanged -- avoiding
the introduction of new bugs into otherwise stable code -- even as
the programs gain new capabilities.

Packaging code into modules increases flexibility and extends the scope
of its usage, since modules may be loaded into multiple programs, on
user demand, without user recompilation.  Software written in the 
non-extensible model tends to be usable only in the application for
which it was targeted, and even if written as a library (i.e. for use
in multiple programs) must still be explicitly compiled into those
programs, almost always by the developer rather than user, prior to
invocation.

Conversely, a user who does not require the use of module X need not load
it at all, saving program startup time and computer resources.  In contrast,
all of the code within a self-contained, non-extensible program must be
loaded, even if parts of it go unused at runtime, when the program is
started.  As a result extensible programs can produce a nimbler, more
responsive, and less bloated feel.

The use of modules can also increase the rate at which programs evolve,
because in developing a module the individual is generally not required
to master the internals of the application(s) which the module extends.
Modules thus tend to increase the number of individuals able and willing
to contribute to an application, which in turn allows fewer "in-house"
developers to maintain "larger" systems because the evolution and
maintenance problems are now distributed over a larger pool of workers.

Organizing software into collections of modules can also dramatically
shrink the cycles between enhancement releases.  Since modules are,
again, small in nature, specific in function, and orthogonal to one
another, the mental map required to maintain them can be considerably
smaller than, say, that required to work on systems hundreds of megabytes
in size, whose pieces are woven together with tight, often circular,
interdependencies.  As a result module enhancements can usually be
developed in less time, and require less system-level testing and
integration, than those for mega-systems.  This can be a big win for
users under time constraints, such as scientists with fixed periods
before their proprietary data go public, who might otherwise have to
wait months, or as much as a year or more, before a new version of
NAME-YOUR-LARGE-SYSTEM is released which provides features required
for their analysis.