Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!husc6!cs.utexas.edu!pp!cadillac!vaughan
From: vaughan@cadillac.CAD.MCC.COM (Paul Vaughan)
Newsgroups: comp.lang.c++
Subject: Re: Reusable design vs. reusable code
Message-ID: <657@cadillac.CAD.MCC.COM>
Date: 14 Dec 88 17:09:20 GMT
Organization: MCC VLSI-CAD Program, Austin, TX
Lines: 105
Referen	es: <4800046@m.cs.uiuc.edu> c

Please don't interpret what I have to say as the current thinking at
MCC.  It is only my current thinking, and I have nothing to do with the
group that spends its time thinking about such things.

In article <4800046@m.cs.uiuc.edu>, wsmith@m.cs.uiuc.edu writes:

;I would like to contrast two desirable properties of a language: the property
;that software in the language is reusable, with the property that the 
;software is easily rewriteable so that designs are reusable.
;
;I believe both are desirable, but may conflict with each other.
;
;To me, reusable software means that implementations may be used for many 
;different purposes.  It may be difficult to make the first implementation
;or the language may have a steep learning curve (as I understand Smalltalk
;does to an extent) but once it is done, you have an library that may save
;effort in the future.

An important point here is that	you don't start from scratch all the
time: not only do you have a useful library once it is done, you have
one before you start.  (Learning to use this library effectively is
frequently labeled "steep learning curve".)

;Another desirable property to me is that the software is rewritable.  For this
;to be true, the effort reused is in the design phase.  A design may be 
;implemented in several different ways and each of the effort to make
;new implementations of the design would be painless in a language with this 
;property.  If a algorithm is easy to implement, reimplement, or modify in 
;a language, there are several benefits to be gained:  
;
;        A library of designs may be created that may then be adapted to 
;                different uses, which leads to the second point:
;
;        I think it is easier to reuse designs than implementations.  If I have 
;                a simple schema (design) for symbol tables and I need to use 
;                that design in a slightly different manner for a prototype, 
;                it could be much easier to reimplement the modified design 
;                than to try to fit an existing C++ or Smalltalk implementation 
;                into my new framework.
Maybe, maybe not.  I find the Common Lisp Hash Tables (and their
extended brothers available in Symbolics CL) to be extremely useful
items.  The thing I find most interesting about OOL's is that they
support reusable FRAMEWORKs as well as reusable components such as
symbol tables.
;        Prototyping will be much easier.  The work of making a prototype is to
;                convert a design into a cheap and dirty implementation.  By
;                making programs easily implementable, that initial expense is
;                minimized.  Later, the same design may be implemented in a
;                more sophisticated manner as profiling and performance monitors
;                indicate that improvements are necessary.

I dissagree, prototyping is a process of taking a cheap and dirty design
and finding out what is wrong with with it, using the cheapest possible
implementation.  Moreover, the design is typically somewhat unique (or
else we wouldn't need to prototype), so it is unlikely that we will be
able to convert a previous design.  Finally, "making programs easily
implementable" is what we are shooting at with both approaches.  Of
course it Would Be Nice.
;
;        At the point where implementation becomes easy enough, a higher level
;                implementation language could be used to guide an automatic
;                generator of lower level code.
(Flame on:  sort of like a Pascal compiler, or even (gasp) Lisp)

;I believe it will be difficult to develop a language where both reusable
;designs and reusable code are possible.    The problem is capturing all 
;possible modification to a design and mapping them onto parameterizations of
;a library.   At some point, a modified design will force a reimplementation
;of the library.  Unless the reimplementation is made easy, the design won't
;be very reusable.   The effort needed to make code reusable inhibits
;this goal.
;
;Bill Smith

This is pretty abstract, but I have some fundamental disagreements as
noted above.  Also, there is the issue of optimization.  One of the
things you get from using component parts from a library is a carefully
optimized implementation (at least from a "good" library).  This is
usually abstracted out in the design.

As higher level primitives become widely understood (such as hash
tables) designs that that use them are easier to comprehend and are
thus more easily implemented, especially if the primitives themselves
are already implemented.  This is a factor that contradicts your point
about conflicting goals.

The main problem that I see with reusing code (in addition to
designs--after all, if you reuse code for a component, you've certainly
reused its design) is that it is inherently limited to its original
language.  It seems that we are continually creating new languages and
leaving everything behind.  This is a problem, but perhaps not an
especially bad thing from a macroscopic viewpoint.  Reusing designs in
the face of changing languages can also raise problems.  For instance, I
have a design for a Lisp program that needs to be modified and
implemented in C.  The design assumes a good hash table implementation
and garbage collection.  Hash tables can be found, but what about garbage
collection?  It seems that the fewer services and constructs a language
provides, the easier it will be to re-implement a design in another
language, but the design itself is more complicated.

Finally, a question:  What properties of a language make for easily
reusable designs?
-- 

 Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
 Box 200195, Austin, TX 78720  | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan