🚀 go-pugleaf

From article <5186@pt.cs.cmu.edu>, by ram@wb1.cs.cmu.edu (Rob MacLachlan):
> As I see it, the key barrier to reusing software is that systems don't
> naturally break down into atomic reusable components.  

    While out in industry, I found the reverse to be true; as long as
    one actively seeks to identify reuseability opportunities, there
    will be little difficulty finding them.  Just about anything you
    do more than once is a good candidate for reuseability, after
    being structured into an appropriate abstraction.   The problem
    is not that "systems don't naturally break down into atomic 
    reuseable components"; in fact, they do so quite readily when
    considered in relation to similar systems.  The problem is that
    many programmers (and project managers) do not view things with 
    an eye toward reuseability; programmers either because their language
    doesn't support reuseability or because the concepts are slow to
    propagate into industry, and managers because they aren't being
    measured by anything other than the time and money required for
    the project itself, regardless of the potential value of spinoffs.

> Supposing I had this whizzy indexed library of frobs, and I wanted 
> a green frobboz.  But when I look, I probably won't find one.  I could 
> maybe make do with the yellow-green one, but I would have to work around 
> it or modify it.  The advantage of an o-o inheritance system is that it 
> makes it very easy to reuse a component *with modifications*.  If you have 
> to modify a component without understanding how it works, then you are much 
> better off with the structured modification techniques of inheritance and 
> method combination than if you attempted arbitrary modification of the code.

    The same thing is possible through the use of Ada packages; a new
    package serves as an interface which hides both the calls to the old 
    package and the new code which was added on top of it, thus preserving
    the integrity of the original abstraction and creating a new one.  Do 
    you seriously believe that any software engineer worth his/her pay is 
    going to overlook the above strategy?  Quite simply, "Abstraction 
    is the fundamental means by which the computer scientist can combat 
    complexity"; to assume arbitrary modification of code is to assume
    total disregard for this fundamental principle of computer science.

    Now if a single inheritance clause is used to obtain both specification 
    and implementation, it would seem that any modification of a component's 
    implementation would trigger the recompilation of everything depending 
    on it.  In contrast, the new Ada package can be added to the local 
    library of software components immediately if it seems appropriate;  
    when it becomes obvious that the component is going to have to be 
    implemented more efficiently, Ada provides the abstract separation 
    which allows us to replace the implementation in a modular fashion 
    without recompiling any of the code depending upon the abstraction.  

    The Ada package provides excellent support for abstraction, and 
    it has yet to be demonstrated that inheritance is even necessary.

> I personally think you are wacko if you think that there are going to be
> very many components reusable millions of times without modification, at
> least if defined in Ada.  

    Why?  Ada provides a very high level of support for abstract data types, 
    so no problems there.  There is a large and growing set of Ada packages 
    which support specific domains (the classic math libraries are the basis 
    for this increasingly important reuseability strategy), which extend
    reuseability into reuseable domain-specific knowledge; they certainly
    work rather effectively.  What basis is there for claiming otherwise? 

> I can conceive of there being a "programming environment" someday that 
> could substantially automate the process of customizing components, but 
> it's going to have to pay a lot more attention to semantics than Ada does.

    The knowledge-based reuseability librarians discussed earlier in this
    newsgroup (Unisys STARS research) substantially automate the process of
    selecting existing components.  When a component requires customization,
    it is conceivable that a knowledge-based customizer could make use of
    the same knowledge base used by the librarian to create an interface
    package appropriate for a particular user, while alerting component
    developers when a given modification is requested frequently enough
    to warrant efficient implementation.  But these are AI topics which
    are largely independent of the underlying language.

    Unlike C++ and other "moving targets", Ada is the product of a language 
    *engineering* effort.  Users are assured of linguistic stability for ten
    years at a time, long enough for investments in the language to pay off.  
    Ada 83 software will almost certainly be suitable for automatic Ada 9X 
    translation, thus ensuring the continuity of that investment.  In the 
    interim between revisions, opportunities exist to incorporate new 
    ideas which emerge in the form of research languages, if they make 
    a significant new contribution and can be efficiently implemented;  
    but so far, inheritance isn't holding up very well on either count.

    When we consider that Ada was designed in the late 70's (it took from
    1980 to 1983 to get Ada through the ISO), its continuously accelerating
    popularity almost a decade later is quite remarkable, and a strong
    affirmation of the vision and skill of its designers.  The concepts
    developed in _Abstraction_Mechanisms_And_Language_Design_ (Paul N. 
    Hilfinger's ACM Distinguished Dissertation) will surely lead to an 
    even higher level of support for the process of abstraction as Ada 
    upgrades itself to support the 1990's.  Nevertheless, given that support 
    for secure data abstractions which can survive external multitasking 
    as well as utilize multitasking internally, in conjuction with the no 
    subsets, no supersets, ten-year stability essential for portability and 
    for a software components industry, is still the exclusive domain of Ada 
    83, and that much research still needs to be done on ways to fully exploit 
    parallelism in the implementation of abstract data types, it is quite clear 
    that Ada 83 is a very powerful tool whose limits are much farther away
    than the limits of our current ability to fully utilize its capabilities.  
    

    Bill Wolfe, wtwolfe@hubcap.clemson.edu