Re: Ada

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

From article <14033@grebyn.com>, by ted@grebyn.com (Ted Holden):
> Journal articles indicate a continuing failure of Ada to work for embedded
> systems as well as for large scale projects, a continuing failure to run
> with acceptable performance on anything other than parallel or special-
> purpose, expensive systems, and an actual gain in cross-system complexity
> and decrease in the stated goal of reuseability.  

   This is blatantly false; consider the November 1988 article
   in IEEE Software ("Large Ada projects show productivity gains"):

      After years of development and an initial skeptical reception,
      many people are now using Ada and saying that they like it...
      The growth in Ada's use has been helped by favorable reports
      from early adopters ("Ada Catches on in the Commercial Market,
      Soft News, IEEE Software, November 1986, p. 81) and by the
      growing number of validated compilers... project results show
      that Ada can greatly increase productivity for large systems...
      [in a 1.2-million-line Ada project] reuseable software developed 
      on the project was counted only once.  Roughly 13 percent of the
      delivered software was reuseable.  This reuse saved 190 man-months
      of effort (a 9-percent savings) and reduced the schedule by two
      calender months (a 4-percent savings)... Productivity for the
      execution environment -- including the operating system, data
      management, information management, communications support, and
      communications interface -- was 550 lines per man-month... 
      Productivity for the applications software... was 704 lines per
      man-month... the average productivity of the 1,500 systems in
      productivity consultant Lawrence Putnam's database: 77 lines
      per man-month (at the 1.2-million-line level)... 

   Sounds like a continuing *success* to me... 
   
> In particular, the
> ordinary systems which most people will be seeing in front of them for the
> next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably.

   Precisely the point of Dr. Charles McKay, head of the Software
   Engineering Research Consortium, in his Tri-Ada '88 presentation,
   "Standards for the Sake of Standards -- A Recipe for Failure".

   A prime example is Unix; the current POSIX effort aims to 
   standardize 1960's technology, thus resulting in a "lowest
   common denominator" which locks users into obsolescence.

   Ada's problem with Unix is that Unix, being 1960's technology,
   does not properly support lightweight processes.  Modernized 
   versions of Unix (e.g., MACH) which are designed to provide
   such support remove the difficulty.  Note that C or C++ programs
   making use of the same "heavyweight" tasking facility will be
   equally slow, since they rely on precisely the same system. 

   If one does not have to struggle with the limitations of *Unix*,
   then there is a wide selection of Ada compilers which run Ada 
   within that environment quite nicely.  Some, like the Telesoft
   TeleGen2 compiler, have global optimization facilities which
   result in better code than that which can be produced by current
   C compilers (as of Tri-Ada '88). 
   
> C began with real machines, real programmers.  The idea seems to have
> been:  [...] end up with a kind of high-structured, low-level language; 
> a thinking-man's assembler.  

   Yes, as one Usenetter's .signature states, "C combines the power
   of assembly language with the flexibility of assembly language".

   Fortunately, the economics of software development are in favor
   of using considerably higher-level languages.

> C++ appears to BE the very language which Ada was supposed to be
> (the spirit of the law) but never can and never will be.  

   Total rubbish; C++ retains all the low-level and dangerous
   facilities of C, which is obsolescent by modern software
   engineering standards.  As stated by Fairley (Software
   Engineering Concepts, page 228),  

      Modern programming languages provide a variety of
      features to support development and maintenance of
      software products.  These features include strong
      type checking, separate compilation, user-defined
      data types, data encapsulation, data abstraction,
      generics, flexible scope rules, user-defined exception
      handling, and concurrency mechanisms.  This chapter
      discusses these concepts...

   Now C++ has one useful feature which Ada does not: inheritance.
   But it is also (as its designer freely admits) lacking in
   generics and exception handling, and also does not provide
   a means of expressing concurrency in a standardized, portable way. 
   Since tools such as Classic Ada permit the use of inheritance with
   Ada (generating *standardized*, compile-it-anywhere code), this is
   something which can be worked around until Ada 9X brings it in directly. 

> Ada is what you might expect from a programming language designed by
> committee;  it is unbelievably slow, an unbelievable resource hog,

   This has been a property of some early Ada *compilers*, but is
   not a property of the Ada *language*.  Fortunately, compiler
   technology is now capable of delivering tight, efficient Ada
   object code, better than that being produced by C compilers.

   Compilation is slower because the Ada compiler is doing much
   more work for you; this reflects again the economics of software
   development in that machine time is cheaper than programmer time.

> [...] There is the August 21 89 issue of Government Computer News
> describing the problems which the huge FAA Advanced Automation System is
> having due to IBM Ada implementations and tools (or lack thereof).  

   Are you saying that this is the fault of the *language*, or of IBM?

> There is no real way to call [Ada] from a Cobol program.

   Ada users can call COBOL or any other language using pragma
   INTERFACE; COBOL needs to have a similar standardized means
   of calling other languages.  Given that it does not, ad hoc
   means of calling other languages have been devised; there is
   no reason why such techniques cannot be used to call Ada just
   as well as C or any other language.  But this is COBOL's problem,
   not Ada's.  
    
> the programming style being promulgated by DOD for Ada [descriptive
> variable names] is anti-conducive to the stated goal of readability;  

   To C hackers, who are accustomed to single-letter variables, yes.

   Software engineering specialists tend to have the opposite perspective.

> Second, DOD is often insisting on portability via Ada rather than
> portability via UNIX, POSIX calls etc.  This amounts to such things as
> insisting, for instance, that vendors provide direct Ada hooks to a
> database rather than simply writing an Ada -> C -> database hook.  Typical
> vendor response is either "F... You" or "Manana".

   And the response of the Ada community is to turn to companies
   such as The Ada Ace Group, Inc., a technical consulting company
   specializing in the development of Ada interface to software
   products and applications.  They provide customized pure Ada
   interfaces to existing commercial software products, such as
   databases, operating systems, and specific applications such 
   as X-Windows.  (Contact information: 4254 Indigo Drive, 
   San Jose, CA  95136; (408) 267-8296)  Do you really think the
   Ada community, with its emphasis on standardization and vendor  
   independence, is going to be stopped by an intransigent vendor?

> A military project involving Sun machines and Ada was abandoned after
> something like 4 years and $30 million effort because of unacceptable
> performance;  database screens were taking over a minute to come up.  The
> design work had all been done according to your formula, the individual
> modules had been designed, written, and tested, all according to the
> standard military schedules and formulas (2167 etc.).  Everything seemed
> hunky dory, only when they put the fricking thing together, it was too
> damned slow to use.  And, the remarkable thing is, the very system the
> military insists upon for management of software contracts prevented
> anybody from knowing they were in trouble until four years and millions
> had been blown.  The government people involved were essentially reduced
> to the role of actors in a Greek tragedy.
>  
> Asked for a solution, my firm weighed the choice between offering an Ada-
> to-C converter and silence, and opted for silence.

   How about applying a profiler and recoding the "hot spots"?
   If the slowness of Unix process handling is a problem, then
   a more modern version of Unix should be used.  Your company
   should have considered more than two options.

   There are problems in the government management process, but
   this pertains to the government and not to Ada.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu