Re: Ada 9X objectives

[billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )]

From article <73079@linus.UUCP>, by munck@chance.uucp (Robert Munck):
> In a previous article, I said:
>> ...  the Ada effort is NOT primarily concerned
>> with the state of the art in programming languages, but rather that
>> of large-scale software engineering.
>>
% And in article <6699@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu replied:
%>
%>   I think otherwise: the effort is not to link Ada with the state
%>   of the art in programming languages, but to link Ada with the
%>   state of the art in software engineering.
%>                       ^^^^^^^^^^^^^^^^^^^^ 
> 
> Does anyone else get the feeling that he's not LISTENING?  
> It must be wonderful to have the leisure to reply at length 
> to every posting, no matter what, but
> the replies should be based on what was originally written.

    It was.  What you originally wrote (prior to the included material)
    was words to the effect that an effort is being made to link Ada with 
    the state of the art in programming languages RATHER THAN the state of
    the art in software engineering, and this contention is what I took
    issue with.  

    I submitted instead that the idea was to determine (as was the
    case with Ada 83) what language capabilities would best support
    software engineering practice, and move from there to specific
    language constructions.  I see no basis for your contention that
    the state of the art in programming languages is being considered
    as the driving factor; what has changed is the state of the art
    in software engineering practice.  This in turn requires new
    programming language support facilities. 

    Example from Ada 83: Support shall be provided for data abstraction.

    Resulting constructs: generic packages, limited private types.

    Example for Ada 9X: Support shall be provided for object-oriented
                          software development.

    Resulting constructs: classes, a multiple inheritance mechanism  

    In each case we have a software engineering practice (data abstraction,
    object-oriented development) for which language support is required.
    Hence, it seems that the assertion that proposed changes are not 
    being driven by software engineering requirements is not correct. 
         
    Perhaps you know of a counterexample -- some proposal which is not
    related to support for software engineering practices.  If so, please
    point it out directly.  


    Bill Wolfe, wtwolfe@hubcap.clemson.edu