From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_05,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,af0c3b19525975d5,start
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1993-03-14 14:52:51 PST
Path: sparky!uunet!fedfil!news
From: news@fedfil.UUCP (news)
Newsgroups: comp.lang.ada
Subject: Common Threads
Message-ID: <348@fedfil.UUCP>
Date: 14 Mar 93 14:15:56 GMT
Organization: HTE
Date: 1993-03-14T14:15:56+00:00
List-Id: <comp.lang.ada>





The following item once appeared in the AdaWoe BBS which DOD used to
maintain:

complaint #0237
 
    We cannot adequately configure large systems as the language now
    stands.  There are no standard means of performing the kind of
    operations on library units generally considered desirable.  These
    include:
    -     creating a new variant or version of a compilation unit;
    -     mixed language working, particularly the use of Ada units by
          other languages;
    -     access control, visibility of units to other programmers;
    -     change control and the general history of the system.
    The inability to do these things arises out of a few loosely worded
    paragraphs in the LRM (in 10.1 and 10.4), which imply the existence
    of a single Ada program library, whose state is updated solely by
    the compiler.  This can be an inconvenient foundation on which to
    build.  The relationships between compilations in a project will be
    determined by the problem and the organization of work, and any
    automatic enforcement of a configuration control regime must come
    from a locally chosen PSE.  Ada especially, as a language with large
    and diverse application, must have a separate compilation system
    which gives the greatest freedom possible in this area.
 
 
    IMPORTANCE:
 
    ESSENTIAL
 
    Ada was intended for use in large projects, involving many people,
    possibly at different centers.  These are precisely the projects
    which will collapse if the programming support technology is
    inadequate.
 

Of course, according to most of what transpires on comp.lang.ada, the author
of the above statement was probably just some sort of a foul-ball or a
non-team-player.  Ada certainly can't be blamed for the gentleman's problems,
nor for problems such as he describes, which we seem to be reading more and
more about as time passes.  

And yet, there must be some common thread between some of these;  take the
FAA scandal and STANFINS R, for example.  What could there be in common 
between those two projects which might explain the problem?  Same city
perhaps (possibly no Ada programmers to be found in one locale)?  No,
Indiana is a ways from Bethesda Md.  Same contractor?  No, CSC and IBM if
I remember correctly... those two don't share many secrets.  The managers
of both projects are dying of AIDS?  No, or at least I don't think so...
you'd read about that.

Whatever COULD it be???


-- 
Ted Holden
HTE