🚀 go-pugleaf

Paul writes:

>I was under the impression that a major reason for inventing reusable
>components was to reuse code, that is to recycle implementations.

I believe that there could be an ends/means confusion here. It's something
like saying of war that the objective is clearly to discharge weapons 
[which is perhaps a natural perception for an arms manufacturer].

Similarly, if we look at the construction industry and only see that
it constantly reuses I-beams, bricks, etc., or look at the electronics
industry and only see that newer components are plug compatible with
older ones [so that you can, say, roll out an old mainframe computer,
roll in a newer model, plug in the peripherals, and you're off and running
again], then we are fixing on the physical aspect of the situation and
missing much of what is really happening.

A major reason architects and construction engineers reuse I-beams is because 
they have fixed, well-understood specifications and because their performance
characteristics are completely analysed. When they are used as components,
all sorts of structural analysis can treat the I-beams as whole units
which do not require further costly microanalysis. 

In electronics, plug compatible components don't just physically interchange
with their precursors, they provide the same [or even extended] functionality,
although they often differ in preformance or cost characteristics. [The
role of specs is again clear.]

Our intent in the reusable components effort is to help to support the
development of correct, efficient, useful, ... , brave, clean, and
reverent software in a timely and cost-effective manner. This will
certainly involve `recycling implementations', but that's just a piece
of the story. Adequate specifications and techniques for identifying
generally reusable facilities are some of the other pieces.

>  ...
>But other than performance characteristics, why would someone
>want to keep multiple implementations of a specification, or multiple
>implementations of an almost-constant-function?  If one does the job
>just as well as the other, why have both?

Performance is the reason [well perhaps programmer egotism too].
If you convert your B-tree code into a realization of the almost-constant-
function concept and add performance specs for the various operations,
you'll find that the operation for getting the value of F at index i
(in worst case) will have a duration O(log(n)), where n = Card( { j: index |
   F(j) # C } ). Now the performance of this operation might be improved
by using a hashing scheme instead of a B-tree, but then the operation which
gets the next [interesting] index at which F is non-constant would have
duration O(n). [Moreover, the hash table would require more space.] If an
application of the almost-constant-function mostly looks up random indices,
then the hashing realization is probably preferable. If it predominantly visits
the interesting indices in order, then the B-tree realization (or the
linked-list one perhaps) might be appropriate. 
The important point to note is that reusable facilities provide several
operations, so the performance optimization problem is far from single
dimensional. If realization A beats realization B in all aspects of
performance, then Paul is right and we don't need B [unless we or
some politically powerful group happened to write B :-) ]. After
we dispose of all such useless realizations we will normally be left
with a collection of performancewise incomparable realizations.
Functionally they are interchangable, so we may end up tuning an
application by the old swap and see technique.

Another concern here:
>   ....    Though it is possible to write several implementations
>of, say, an almost-constant-function (e.g. B-tree, doubly-linked list,
>splay tree, etc.), each implementation has strengths, and implementation
>details that could be very useful if they are presented in the interface.

No matter how fascinating implementation details are to a programer, they
are precisely the information we are trying to hide from facility clients.
The conceptual specification of a facility gives as simple a picture of
what functionality a client should expect as we can come up with. [E.g.
the almost-constant-function] In general this description should say
nothing about any clever pointer schemes, etc. that might be used to
realize the facility -- especially since we may develop realizations
that use completely different tricks. 
Now performance characteristics are particular to each different
realization of a concept, so specifications for them must be attached
to each realization. Even here, we do not want to complicate the clients
situation by drawing him into the details of our implementation, so
the performance specifications should be formulated in terms of the
simple conceptual picture we used to give the functional specs.

/Bill