Re: Software Reuse -- do we really know what it is ?

[crowl@rochester.arpa (Lawrence Crowl)]

In article <4658@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes:
]... software people fume and gnash their teeth over "wasted space". ...  All
]the techniques for modules, objects, etc, tend to slow things down.  Again,
]software types tear their hair out and vow to recode everything into one
]assembly language procedure.  Worse, other software types admire them for
]doing so!  ...
]
]In article <374@sol.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes:
>>In article <371@dcl-csvax.comp.lancs.ac.uk>
>>craig@comp.lancs.ac.uk (Craig Wylie) writes:
)))3.	Languages such as Ada and Modula-2, and imperative languages in
)))	general are unsuitable for writing reusable software because of
)))	their concentration on the HOW rather than the WHAT.
>>
>>Clearly, we need more concentration on WHAT, but we should not abandon the
]                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^
>>efficiency of HOW.
] ^^^^^^^^^^
]
]QED!

Let me clarify my position.  I can specify a sort as a set of predicates and
let the system figure out how to satisfy those predicates.  This is the WHAT
approach used in languages such as Prolog.  Another approach is to write a
algorithm for sorting, e.g. quicksort.  This is the HOW approach used in
languages such as Ada.  Yes, the packaging of the sort will result in some
loss of efficiency.  However, it will be substantially faster than the WHAT
approach.  I am advocating an approach in which a package interface describes
WHAT and the implementation of the package describes HOW.

Because I wish to keep the macro-efficiency of algorithmic languages, do not
accuse me of wishing to keep the micro-efficiency of hand-tuned assembler.

]3. In general, hardware types have standards for every imaginable sort of
]interface, and they stick to them remarkably well.  You can plug boards into
]a standard bus with only a small chance of sparks flying everywhere as the
]boards fry.  In software, standards are strictly for lip service to managers;
]only a novice would consider combining programs from several different
]sources without planning a few hours or days of debugging!

Programmers to this sort of program combination many times a day in the Unix
shell.  There ARE approaches to software reuse that CAN work.  We need to
provide this kind of capability within a language.

]In short, I believe there are no technical problems or issues with reuse;
]it's the software culture that has to change.  At present, the prevailing
]attitude is that the densely-coded, highly-optimized, do-everything program
]is a sort of ideal to which everyone aspires.  Until this attitude changes,
]software reusability will continue to be a bad joke among those who actually
]write programs.

There are technical problems.  For instance, how do you insure that the 
parameters to a generic package are appropriate.

Performance will always be a goal.  However, it must be balanced against cost.
Most programming done today is in a high-level language.  In the early sixties,
most programming was done in assembler.  So, the software attitude has changed.

Modular code also allows changes in representation that can lead to orders of
magnitude performance improvements.  Non-modular code strongly inhibits such
representational changes.  In short, the micro-efficiency of non-modular code
leads to the macro-INefficiency of poor algorithms and representations.

)))5.	Nobody can force programmers to write good reusable code.
>>
>>True.  But no one need buy code that is not both good and reusable.  I
>>believe there is a market for such code.
]
]Manufacturers seem to think their interest is in maintaining secrecy of code.

Again, let me clarify.  I meant that the reusable software would be written by
software houses and sold to companies which write applications.  For instance,
Reusable Software Inc. sells a sort package to Farm Software Inc. which uses
it in its combine scheduling program.  Farm Software Inc. need not divulge its
algorithms or its use of packages written by Reusable Software Inc.

]Customers only care about speed and features.  Read Infoworld and see if they
]ever say anything positive about a program that is slower but more modular.

You forgot cost.  Modular code will cost substantially less in the long run.
-- 
  Lawrence Crowl		716-275-5766	University of Rochester
			crowl@rochester.arpa	Computer Science Department
 ...!{allegra,decvax,seismo}!rochester!crowl	Rochester, New York,  14627