Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ncar!gatech!udel!princeton!pucc!EGNILGES
From: EGNILGES@pucc.Princeton.EDU (Ed Nilges)
Newsgroups: comp.software-eng
Subject: Re: Reusability considered harmful??(!!)
Message-ID: <12385@pucc.Princeton.EDU>
Date: 31 Jan 91 04:54:50 GMT
References: <6108@stpstn.UUCP> <7095@uqcspe.cs.uq.oz.au>
Reply-To: EGNILGES@pucc.Princeton.EDU
Organization: Princeton University, NJ
Lines: 34
Disclaimer: Author bears full responsibility for contents of this article

In article <7095@uqcspe.cs.uq.oz.au>, phil@batserver.cs.uq.oz.au (Phil Stocks) writes:

>In <6108@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes:
>
>>What do you think about substituting 'division of labor' for reusability
>>across the board, on the grounds that it says precisely what is meant
>>and nothing more?
>
>No, that won't do. People won't settle on whether to spell labour as

Interesting thread.

A lot of the time, reusability fails for the same reason RISC technology
is popular with a large subset of computer architects.  "Reusable"
software components are very often ugly to use because they do more
at run time than the potential reuser wants them to do.  Even when this
is not the case, there is a perception problem, somehwat similar to
the perception of reusability that Brad describes: programmers tend to
be highly suspicious of buying a pig in a poke, of having to pay for
someone else's mistakes, or just of coming up with a less than optimal
product.

This problem is related to the problem of the CISC (Complex Instruction
Set Computer).  The instructions of the CISC can be difficult to use
in a compiler, whereas the extremely regular instructions of the RISC
machine can be easier to consider as straightforward black boxes.

Reusability is not like motherhood, good no matter what.  We badly need
a theory of what constitutes good reusability and what constitutes bad
reusability.  Unfortunately, in an era of computing cultures that
are expand globally, at dizzying speed, it is unlikely that we can
come to any such agreement any time soon.  I therefore predict that
code, globally speaking, will be in future even LESS modular...more
highly adapted to a particular environment...than it is today.