Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.software-eng
Subject: Re: Ada vs. COBOL study
Message-ID: <5958@hubcap.clemson.edu>
Date: 9 Jul 89 18:26:40 GMT
References: <20256@cup.portal.com>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 53

From article <20256@cup.portal.com>, by ts@cup.portal.com (Tim W Smith):
> Those "obvious" benefits of switching to a more advanced language
> did not show up in the productivity studies of De Marco and Lister
> reported in their book "Peopleware".  ( I may have the names wrong,
> since this is from memory ).
> They found that language did not have a correlation to performance
> except that assembly language programmers got left behind.

   I've seen such studies; one major flaw is that they did not study 
   languages which are designed around the concept of reuseable
   software components.  Start using Ada generics and see what 
   happens to your productivity...

   If we simply compare the things which most high-level languages have
   pretty much identical facilities for doing, we shouldn't be surprised
   to find that the only differences are those imposed by, e.g., the
   excessive amount of typing necessary to produce a COBOL program
   relative to the benefit derived.  If we are to compare advanced
   languages, then we must also assume that the applications involved
   are nontrivial, and that they are to be given a quality implementation.

   Further, the studies only consider the time required to hack something
   together.  I submit that the costs of maintenance over the life of the
   product are simply omitted from such studies; when we consider the
   vast difference between the ease of modifying a highly modular Ada
   product and the torture of modifying (and subsequently trying to debug)
   products written in languages without even local variables, much less
   highly secure abstract data types, it is clear that no comparison 
   which does not include these lifecycle costs is really useful.
   
   Also, there are typically costs in the form of product inferiority
   which arise in some languages but not others.  If I were to try to
   implement a priority queue in COBOL, it would have to be bounded;
   the result is either squandered storage (when the queue is small)
   or application failure (when the queue is large).  The use of 
   unbounded Ada components results in a higher-quality application.   

   Finally, the studies typically address only sequential coding; 
   such studies should cover a range of applications which includes 
   multitasking.  One example would be the writing of a database system;
   another would be the implementation of high-performance software
   components which are not only secure under conditions of multiple
   requests from multiple tasks to a single instance, but which actually
   satisfy these requests in a parallel fashion.  Many business applications
   have poor response times because they are unable to exploit multitasking. 

   I haven't checked _Peopleware_ specifically, but perhaps you can tell
   us how many of these factors were considered in their study, and whether
   Ada was even part of the analysis...


   Bill Wolfe, wtwolfe@hubcap.clemson.edu