Re: Reserve Demobilization System Built Around Re

[jgn@nvuxe.uucp (27126-Joe Niederberger(G030)m000)]

>What irks me about some of this is the rapidly graying distinction
>between 'reuse' and 'use'.  From a research perspective, most people
>will agree with the idea that reusable software is hard to make.
>Some would even say that USABLE software is hard to make.  But where
>are we going to draw the line between these two ideas ? 

<stuff deleted>

>Is there a fine line between use/reuse when talking about
>a spreadsheet ?  Is Emacs REUSABLE just because it has a programming
>language built in, or is it just a whole lot more USABLE than vi ?
>
>I'll admit I don't know how to put this distinction into a well worded
>definition.  Perhaps USE is associated with a USER ?  Therefore, REUSE
>occurs when software is used by a non-USER ? (ugly definition)
>Perhaps, REUSE occurs when software is employed to develop more
>software (but what do you call a compiler then ?)

It seems to me that software reuse is a (albeit fuzzy) proposed method
for creating software (a) faster (b) with less bugs (c) with lots of
other nice qualities...

Given that, does trying to pin down precise definition for "Software
Reuse" really help? The "problem" (timeliness, bugs, etc.) remains --
finding *new* ways to reuse software helps chip away the boundaries of
the "problem". It seems that old triumphs (OS, DBMS, Compilers, etc.)
become less interesting to someone trying to chip away at the current
boundares of the problem, rather than the boundaries that existed ten or
twenty years ago. Likewise, novel concepts of reuse today will be boring
ten years from now. 

Can an abstract definition of "Software Reuse" capture the ever shifting
focus of attention? Its like trying to define art -- artists tend to
care the least about any academic definitions.

Just my 2 cents.

Joe Niederberger