🚀 go-pugleaf

From scotth@boulder.Colorado.EDU (Scott Henninger):
> To say this is to say that current reuse environments are adequate.  They
> are not.  The fact of the matter is that it is easier and takes less time
> to code it yourself than reuse existing code with current technology. 

   Not true; the work required to repeat the design, implementation,
   and testing of a component is considerable.  Furthermore, the 
   component's implementation is likely to be considerably more 
   sophisticated than the probable result of an attempt to do it
   from scratch.   

> Besides, and I repeat, *people are not aware of what reusable components
> exist*.  This is primarily a tools problem, not a training problem. 

   My perspective is that if the market exists (i.e., if people are
   looking for components and wishing for better tools), the tools
   will spring up to meet the demand.  Where people don't bother to
   look, the tools aren't going to appear courtesy of the Tool Fairy.

> The NIH syndrome is simply a part of human nature.  

   There are a great many cultures throughout the world which practice
   ideas which appear to be alien from the perspectives of other cultures.
   This does not imply that a baby from one of those other cultures could 
   not be socialized into such a culture, such that the ostensibly alien 
   practices seem perfectly natural.  Hence, I suggest that professional 
   training can be designed such that practices are internalized which 
   preclude the possibility of rejecting an idea on the basis of its origin.
 
> designing generic code is extermely difficult and time consuming.  

   The engineering of ANY product is usually difficult and time-consuming,
   especially given that the designer of a generic component is trying to
   ensure a great many things that the user doesn't even know s/he needs.
   As a simple example, suppose that a user takes a component and uses it
   in a sequential application.  Later, the application is maintained such
   that multitasking is introduced.  Fortunately, the component's designer
   implemented the component such that multiple requests can be processed
   in parallel, while still maintaining serializability and recoverability.

   This demonstrates that the benefits of using a component can extend far
   beyond the initial construction of the application.  Such an application
   will probably be of considerably higher quality than a corresponding 
   application which did not make use of sophisticated software components.
 
> And it will NEVER be able to handle all of the cases that programmers 
> will come up with.  The ability to tailor existing code is essential. 

   Given the existence of a highly sophisticated component, any user who
   tries to modify it will probably only get into trouble.  It's much 
   better to use the component in the implementation of a higher-level 
   user-defined interface than to try to modify a component's implementation.
 
> Whenever people talk about generic code, they inevitably give examples 
> of *simple* ADTs; ones that you learn in your freshman programming class.
> I would argue that this would constitute an extermely small percentage of
> the code for, say, an accounting program, a user interface, or microcode
> for a tape drive.  

   Domain-specific components will come with their own abstract data types,
   and will normally make considerable use of those types in the supplied
   procedures and functions.  While it is certainly conceivable that 
   generic parameters would prove useful in situations in which the
   domain-specific processing is performed on arbitrary data types,
   or using arbitrary user-defined procedures or functions, the fact
   that generic code is much more vital to the area of "container" ADTs 
   has resulted in a short-term concentration of interest in that area. 
   
   Also, some of the situations you describe are ones in which a different
   technique is applicable: packaging.  An abstract interface will be 
   constructed (e.g., a standard CRT (or CPU) interface), and the
   implementation of that package will translate those commands into 
   whatever is necessary to implement them on a given hardware system.  
   When porting the application it is only necessary to rewrite the 
   machine-dependent parts of the system, which will have been segregated 
   into the bodies of specific packages.  The protection provided by the 
   package specification will ensure that the rest of the application 
   will remain unaffected. 

> Because software is so much more diverse than hardware, the number of
> potential components increases by orders of magnitude.  This makes the
> problem *fundamentally* different - tools are needed to assist the
> programmer.

   Tools *are* needed, but they won't sell if there isn't enough demand!! 
   If organizations can be convinced to commit to a reuse program, then
   the tools will quickly follow.  


   Bill Wolfe, wtwolfe@hubcap.clemson.edu