In a recent vw-dev e-mail on namespaces and packaging, Helge Nowak mentioned the following:
I just recently heard a talk of Perri Tarr a researcher at IBM. She was
laying out the vision of "Pieceware" - Software that is developed in such a
manner that it can be de-composed in any "shape". Today software is composed
and can only be decomposed in exactly _one_ (maybe two) way(s): technical
components and at a lower level the object model. But it is desirable to
have the possibility to "slice out" an arbitrary interesting part of it like
"give me that part of SAP that handles customer data in a secure way".
Helge's observations on this were about navigating through code in a development environment, but the references to Perri Tarr I found on Google were more about software composition. That's what I want to comment on here.
The "Pieceware" concept will certainly be one to watch as it develops, but I am concerned about the notion of being able to "arbitrarily" slice out interesting aspects of programs. Excuse me for being hung up on biological analogies, but how meaningful would it be to "slice out" the aspects of a cell that deal with metabolism or protein replication. Maybe it could be done, but would you have anything useful? Only, I believe, if you had a context that had been designed to accept a wide range of components, and only if what was "sliced out" was an appropriate component for that context.
A good hardware example of such a context is an electronic bus designed to provide power and communication paths for a variety of electronic components. A good software example is Sam Schuster's work on Pollock, which consists of both a framework for the use of GUI widgets, and a extensible family of widgets for that framework. Could an electronic component be arbitrarily sliced out of a given piece of hardware and plugged into new hardware? Could a Pollock widget be sliced out of a given program and plugged into a new program? Yes, but only if you used them in a new instance of the same context.
The problem remains what it has always been, to design useful contexts (busses, frameworks, etc) and components for those contexts. That is what makes it possible to arbitrarily slice a component out of a context and plug it into a new instance of the same context, and thereby apply it to a new problem domain.
I do not accept the statement quoted earlier that
software is composed and can only be decomposed in exactly _one_ (maybe two) way(s): technical components and at a lower level the object model.
There is no difference between "technical components" and "the object model." There are only objects, but they exist as components in a variety of contexts. Well-designed software consists of subsystems of components (objects) that interact at multiple levels of an emergence hierarchy. If there is a failing in object-oriented languages, like Smalltalk, it is in not providing explicit linguistic and development support for hierarchies of subsystems.
To build good systems, build good subsystems.
Read: Pieceware?
Previous Topic
