PLE lecture notes -- Components

Component software

Distributing software components, instead of entire applications, has the potential to benefit everyone:

Users benefit from being able to assemble applications from only the best parts, or the ones people are familar with. For example, using the same "Emacs" component whenever an application needs to do text editing. This creates a high level of competition and turns software into a buyer's market.
Developers benefit from not having to develop monolithic programs. This means a smaller entry cost and shorter release cycles.

In order to build applications out of independently-engineered parts, we not only need components but also glue to hold them together. It is important to distinguish glue because components and glue have to satisfy different requirements. These arise from two simple facts:

Components must be gluable, i.e. reusable
Glue must bind components

Components must be reusable

The most important characteristic of components is that they are reusable. Reuse is aided by:

Generality: the component must support various uses. The linguistics lecture discussed some approaches to generality: polymorphism, higher-order functions, and inheritance. A component should be able to adapt to its embedding environment, e.g. in its naming (whether names denote variables or methods) and control flow (whether it is called as a subroutine or coroutine).
Contracts: the component should ensure that it is correct, and that it is used properly. Typing, encapsulation, invariants, and run-time instrumentation are ways to do this.
Efficiency: the component should adhere to the resource requirements of the user.

Thus Sather, Haskell, and C++ might be useful languages for writing components. However, it is unrealistic to expect that all components be written in a single language. Different tasks still have different language requirements, besides those specific to components, e.g. abstraction, parallelism, and simplicity. A single language which attempts to meet many different requirements is difficult to engineer, and the result is a monolith. (Software tools are applications, too, and so should also be designed in terms of components. With more competition among languages, instead of language monopolies, all of this research may actually see the light of day.)

Glue must bind components

The most important characteristic of glue is that it support many different kinds of components. Since components should be written in several languages, this includes inter-language unification. It also means that the glue language must be extensible. Component binding is aided by:

Reflection: components should dictate the structure of the glue language. This includes values, types, naming, effects, and perhaps the reflection mechanism itself.
Naming: a powerful naming system is needed to manage components and allow them to refer to each other. It should support modular namespaces which avoid name capture or name clash.
Constraints: glue must manage relationships between components. Declarative statement of constraints is more convenient than message-passing for this purpose, and is often more efficient.

Scripting

Interpreted scripting languages are sometimes presented as glue languages. By binding commands in the language to component functions, it is easy to build applications. (Tcl/Tk is a good example.) However, while useful for many tasks, the features of these languages seem to have little in common with the goals outlined above.

Interpreted languages support programming in "interpretive style," where data can be interchanged with programs. This includes:

Generating and executing programs on the fly.
Storing data as programs which recreate the data when executed.
Communicating data between programs in the same way.
Attaching behavior to content, e.g. Web pages.

Scripting languages are optimized for short, simple, used-once programs. Their goal is to enable good things rather than prevent bad things. This includes:

minimal structure in the form of declarations
little concern for efficiency
many ways to do similar things (in the case of Perl)

These are all consistent with the objective of scripting, but this is not the same as component software.

Recently, scripting languages have been outfitted with better naming systems (e.g. Perl5) and reflection capabilities (e.g. Python), which make them better glue languages. However, the best glue languages may result from assuming the glue requirements as fundamental, not add-ons.

PLE lecture notes -- Components

Component software

Components must be reusable

Glue must bind components

Scripting

Other reading