I do have a few observations to pass on. Some relate to the subjects surveyed in the paper, others refer to the paper itself. I hope the former are relevant to the workshop discussions. The latter are only relevant if you intend to publish the paper in some more durable form. Accordingly, I've separated my remarks below.
The enhanced opportunity for reuse apparently comes from the hope that only client code related to the use of the meta interface needs to change when the system above and below the interfaces under consideration is reused. Some of the ease of change may come from the details of interface packaging, but it seems more plausible that the real reason for hope is the separation of concerns, e.g., functionality and performance.
I think this is a slippery slope. There has been a long-standing dream, never realized to my knowledge, of writing a purely functional implementation of a client of an interface, then using a separately provided performance specification or characterization to choose an appropriate implementation of that interface. This dream seems to be the extreme version of the hoped-for reusability story.
Why is the slope slippery? Because of the oft-quoted aphorism that large quantitative changes induce qualitative change. Adjusting the performance knobs of a meta interface within a limited range is plausible, but an order of magnitude change in performance is likely to be achieved by using a different base interface instead, with an attendant sacrifice of reuse. Presumably, we choose to sacrifice reuse in this situation because the gain in performance is worth it. In other words, we're making an engineering tradeoff.
It is certainly true that the more comprehensive the meta-interface, the more opportunities for reuse arise. But there is a cost in making the meta-interface comprehensive, and that cost is only repaid for the cases in which it is actually used. Pushing too much under a single interface imposes too much of a cost on the client as well. VMS has an extensive meta-interface for tuning resource allocation and performance. In principle, this should promote great economies through reuse. In practice, configuring it is so complicated that consultants must be called in (and paid for). Perhaps several different base-interfaces with more limited accompanying meta interfaces would be better. (This situation is far from unique; TSS/360 was similar, and analogous cases arise in other areas.) In trying to promote reuse, we risk compromising original use! (I believe this observation motivates some of the MetaObject Protocol work, though I confess I'm not conversant with this area.)
The foil suggests that the meta-interface should expose only mapping dilemmas . A mapping dilemma, once resolved, becomes a functional choice. Thus, in a broad sense, a module in which a mapping choice has been made is a subclass of one in which a meta interface for making that choice is offered. Many class hierarchies include this kind of subclassing (e.g., HashTable as a subclass of Table as a subclass of Mapping). If retaining the meta interface is desirable from a reuse point of view, should we discourage the inclusion of such things in a static class hierarchy? That is, should we make it hard for code to be written that, ab initio, depends on HashTable rather than Mapping? Seems a little Draconian. But, now we have two largely overlapping but very differently presented ways of achieving the same functionality: static (sub)class choice or dynamic meta-interface invocation. These different modes of achieving similar results impose an undesirable intellectual burden on the programmer.
I think the ``inform/direct'' distinction, as it applies to the facilities of a meta interface, deserves more investigation. The ``direct'' style says, in effect, ``I don't know how to resolve this mapping dilemma, please tell me.'' The ``inform'' style says, in effect, ``I have some idea of how to resolve this mapping dilemma, and perhaps you do too. Neither one of us knows the whole story, but maybe we'll be better off if we pool what we know. Call me - who knows, you might enjoy it.'' These are obviously very different. The former has the contract-like quality of an ordinary interface; the latter promises nothing except good faith. It seems pretty likely that these have different effects on reusability.
In the late 50s, a major mapping dilemma was the translation of mathematical formulas to machine instructions. Fortran was born of this dilemma. For quite a few years thereafter, ``high level languages'' had meta interfaces that permitted their programs to be combined with hand-written machine code. Initially, those meta interfaces were quite extensive. Today, most of them are gone; vestiges remain in only a few very specialized cases, and use of those meta interfaces is deprecated in most situations.
Why did this happen? Technology advanced to the point where, for almost all programs, the control offered by the ability to connect machine code wasn't worth much. That technology wasn't just faster hardware; we figured out how to do much better code generation. However, we shouldn't conclude that all the work involved in making useful meta interfaces for inline machine code and the like wasn't a good idea - it was. Nevertheless, it's in the buggy whip category today.
I think there's a good chance that the techniques being used or considered for open implementation of operating systems will follow a similar evolution. This suggests approaching OI as a worthwhile engineering problem to be solved in today's technology context. It further suggests that we shouldn't approach it as a question of cosmic intellectual depth.
Back to Alphabetical List of Responses
(Last Revised February 1995)