Ada cost breakpoints (was Re: Air Force helping to undermine Ada)

Ada cost breakpoints (was Re: Air Force helping to undermine Ada)

[Michael D Shapiro]

Bob Munck recently wrote:

> Ada is mandated by DoD because a program that uses it cost less over
> its full life cycle.  The larger the program and the longer the life
> cycle, the higher the percentage saved.

This implies to me that for smaller programs with shorter life
cycles, Ada might cost more to use over the full life cycle.
Certainly a 23-line reformatting utility to be used one time and
discarded thirteen minutes later can probably be written in
SNOBOL4 or ICON (or even AWK) more cheaply than in Ada.  Has
anyone done a study to find these breakpoints?  One pair I've
heard mentioned as the appropriate minima for Ada are 500K
source lines of delivered code and/or seven years life cycle.

================================================================
Michael D. Shapiro, Ph.D.              e-mail: mshapiro@nosc.mil
NCCOSC RDT&E Division (NRaD) Code 411    San Diego CA 92152-7560
Voice: (619) 553-4080     FAX: (619) 553-4808      DSN: 553-4080
 [Until January 1992 we were Naval Ocean Systems Center (NOSC)]

Re: Ada cost breakpoints (was Re: Air Force helping to undermine Ada)

[Alex Blakemore]

In article <9303151702.AA01402@manta.nosc.mil> mshapiro@MANTA.NOSC.MIL (Michael D Shapiro) writes:
> for smaller programs with shorter life
> cycles, Ada might cost more to use over the full life cycle.
> Has anyone done a study to find these breakpoints?  One pair I've
> heard mentioned as the appropriate minima for Ada are 500K
> source lines of delivered code and/or seven years life cycle.

I have no study to point to, but from experience 500K SLOC is way too high
for a minimum breakpoint to Ada.  The breakpoint depends on the complexity
and number of people involved.  I dont know about you, but things start
to seem complex to me much closer to 30K than 500K lines.
Even 30K lines of C is a pretty frightening thought.
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

Re: Ada cost breakpoints

[Mark Atwood]

I've have been thinking about my own experiences with Ada, and other
programming languages, and program size.

In article <9303151702.AA01402@manta.nosc.mil> mshapiro@MANTA.NOSC.MIL (Michael D Shapiro) writes:
> Has anyone done a study to find these breakpoints?  One pair I've
> heard mentioned as the appropriate minima for Ada are 500K
> source lines of delivered code and/or seven years life cycle.

In article <65260@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:
>I have no study to point to, but from experience 500K SLOC is way too high
>for a minimum breakpoint to Ada.  The breakpoint depends on the complexity
>and number of people involved.  I dont know about you, but things start
>to seem complex to me much closer to 30K than 500K lines.
>Even 30K lines of C is a pretty frightening thought.

I'l say 30KLOC of C is frightning.  It is probably just me, but 5KLOC of
C starts going over my head in a real hurry, esp. when it is full of
"incantations" and commented like the BSD UNIX OS.  (I've seen some of
the source, so don't bother me about it.)

On the other hand, I'm working on a project that will probably come in
at just under 10KLOC of Ada, and I feel I understand it, and feel
comfortable calling it "small".

Mark Atwood                  :: Being a kitten is it's own excuse.
matwood@peruvian.cs.utah.edu :: 
The University has enough problems without being blamed for mine.

Re: Ada cost breakpoints

[Rahul Dhesi]

In <1993Mar21.120121.16006@hellgate.utah.edu>
matwood%peruvian.cs.utah.edu@cs.utah.edu (Mark Atwood) writes:

>>Even 30K lines of C is a pretty frightening thought.

>I'l say 30KLOC of C is frightning.  It is probably just me, but 5KLOC of
>C starts going over my head in a real hurry, esp. when it is full of
>"incantations" and commented like the BSD UNIX OS.  (I've seen some of
>the source, so don't bother me about it.)

>On the other hand, I'm working on a project that will probably come in
>at just under 10KLOC of Ada, and I feel I understand it, and feel
>comfortable calling it "small".

Now let me ask all of you something.

Suppose you have a software package that is a single monolithic program
with 100,000 lines of C (or Ada).  ("Package" is a generic term here
and not related to Ada's "packages".)

Suppose you have another software package that contains a number of
separate smaller programs, each one having 20,000 lines of code or
less.  Each program can invoke others via a system call (e.g., fork()
and exec() in a BSD environment).  The whole package has 125,000 lines
of code.

Other things (e.g., programming style and package functionality) being
the same, can you allow for the possibility that the second package
might be much easier to write and understand?

Discussions of lines of code should specify the structure of your
software.  Simply counting all lines of code in a software system does
not tell you much about its complexity.  100K lines of code all linked
together and sharing a namespace and common memory are likely to be
much harder to write and maintain than 20K pieces that execute as
independent processes.  Some environments (BSD) make it easy to use
small independent programs that efficiently invoke and communicate with
one another.

In these environments C and C++ will work
very well -- just keep the pieces small.

Other environments may make it difficult to do the same.  In such
environments Ada might be clearly better, though the controversy will
continue to rage.  But why are you using such environments in the first
place?

Note: It's true that some software functionality requires that
everything be linked together, either for efficiency, or because you
are writing an operating system kernel.  But most user-level
applications don't require such monolithicity.  Almost anywhere that
you have a logical division between a client and the server, the two
can be independent processes communicating via messages.  Not only is
does this simplify software design, but it gives you as a bonus the
ability to do distributed processing.

Rebuttals to the above argument should describe the software being
discussed, and why it can't be thus split.
-- 
Rahul Dhesi <dhesi@rahul.net>
also:  dhesi@cirrus.com

Complexity of "distributed" v "monolithic" (was Re: Ada cost breakpoints)

[Mark Atwood]

In article <C49GrE.3xH@rahul.net> dhesi@rahul.net (Rahul Dhesi) writes:
>Now let me ask all of you something.
>
>Suppose you have a software package that is a single monolithic program
>with 100,000 lines of C (or Ada).  ("Package" is a generic term here
>and not related to Ada's "packages".)
>
>Suppose you have another software package that contains a number of
>separate smaller programs, each one having 20,000 lines of code or
>less.  Each program can invoke others via a system call (e.g., fork()
>and exec() in a BSD environment).  The whole package has 125,000 lines
>of code.
>
>Other things (e.g., programming style and package functionality) being
>the same, can you allow for the possibility that the second package
>might be much easier to write and understand?

Not truely a rebuttal, but,

This is a cute straw man.  Whether you design the software to be linked
as one big executable, or as a set of communicating OS processes, should
not make any differance in the "complexity" of the system.  The decision
to do so or not should depend on other factors, such as the need for remote
servers or clients, speed, need for "hot-swapping", etc.

A set of Ada tasks (done as OS threads if you're lucky), or a set of
OS processes using IPC have the same complexity from a design POV.

>Discussions of lines of code should specify the structure of your
>software.  Simply counting all lines of code in a software system does
>not tell you much about its complexity.  100K lines of code all linked
>together and sharing a namespace and common memory are likely to be
>much harder to write and maintain than 20K pieces that execute as
>independent processes.  

The LOC argument is begin thrashed to death over in comp.soft-eng.
Of course LOC is not a "good" measure of complexity.

If all your identifiers are sharing namespace, your design is either
very poor, or you're using a bad language.

>Note: It's true that some software functionality requires that
>everything be linked together, either for efficiency, or because you
>are writing an operating system kernel.

No, just "traditional" kernals.  There are "new" ones that have
spun such things as memory management, file system handling, and
device drivers off as separate "hot" processes.

---
Mark Atwood                  :: Being a kitten is it's own excuse.
matwood@peruvian.cs.utah.edu :: 
The University has enough problems without being blamed for mine.


Newsgroups: comp.lang.ada
Subject:Complexity of "distributed" v "monolithic" (was Re: Ada cost breakpoints)
Summary: a single executable should not be more complex
Expires: 
References: <65260@mimsy.umd.edu> <1993Mar21.120121.16006@hellgate.utah.edu> <C49GrE.3xH@rahul.net>
Organization: University of Utah Computer Science
Keywords: ada complexity loc distributed monolithic kernals

In article <C49GrE.3xH@rahul.net> dhesi@rahul.net (Rahul Dhesi) writes:
>Now let me ask all of you something.
>
>Suppose you have a software package that is a single monolithic program
>with 100,000 lines of C (or Ada).  ("Package" is a generic term here
>and not related to Ada's "packages".)
>
>Suppose you have another software package that contains a number of
>separate smaller programs, each one having 20,000 lines of code or
>less.  Each program can invoke others via a system call (e.g., fork()
>and exec() in a BSD environment).  The whole package has 125,000 lines
>of code.
>
>Other things (e.g., programming style and package functionality) being
>the same, can you allow for the possibility that the second package
>might be much easier to write and understand?

Not truely a rebuttal, but,

This is a cute straw man.  Whether you design the software to be linked
as one big executable, or as a set of communicating OS processes, should
not make any differance in the "complexity" of the system.  The decision
to do so or not should depend on other factors, such as the need for remote
servers or clients, speed, need for "hot-swapping", etc.

A set of Ada tasks (done as OS threads if you're lucky), or a set of
OS processes using IPC have the same complexity from a design POV.

>Discussions of lines of code should specify the structure of your
>software.  Simply counting all lines of code in a software system does
>not tell you much about its complexity.  100K lines of code all linked
>together and sharing a namespace and common memory are likely to be
>much harder to write and maintain than 20K pieces that execute as
>independent processes.  

The LOC argument is begin thrashed to death over in comp.soft-eng.
Of course LOC is not a "good" measure of complexity.

If all your identifiers are sharing namespace, your design is either
very poor, or you're using a bad language.

>Note: It's true that some software functionality requires that
>everything be linked together, either for efficiency, or because you
>are writing an operating system kernel.

No, just "traditional" kernals.  There are "new" ones that have
spun such things as memory management, file system handling, and
device drivers off as separate "hot" processes.

---
Mark Atwood                  :: Being a kitten is it's own excuse.
matwood@peruvian.cs.utah.edu :: 
The University has enough problems without being blamed for mine.

Re: Complexity of "distributed" v "monolithic" (was Re: Ada cost breakpoints)

[David Emery]

When designing distributed applications, consistency becomes more
important and harder to achieve.  If you have a pipe of three
programs, for instance, with a common data stream, it's hard to make
sure that a change to the data stream definition is adopted by all
three programs.  In our experience doing client/server in Ada, the
Ada compiler and library system (that so many people complain about)
is instrumental in keeping our distributed software in sync.
				dave

Re: Ada cost breakpoints

[David Emery]

The problem with this example is that it is clearly *VERY* dependent
on Unix, and specifically BSD, semantics.  Consider what would happen
if you tried to port this code to a non-BSD or non-Unix environment.  

Despite the Open Systems and POSIX movements, Unix is not the only
O.S. in the world (there's more DOS than any other O.S.) (scary, ain't it?)
			dave 

Re: Ada cost breakpoints

[Rahul Dhesi]

In <EMERY.93Mar24172443@dr_no.mitre.org> emery@dr_no.mitre.org (David
Emery) writes:

>The problem with this example is that it is clearly *VERY* dependent
>on Unix, and specifically BSD, semantics.  Consider what would happen
>if you tried to port this code to a non-BSD or non-Unix environment.  

This was presumably in response to my posting, in which I said,

     Some environments (BSD) make it easy to use small independent
     programs that efficiently invoke and communicate with one
     another.

     In these environments C and C++ will work very well -- just keep
     the pieces small.

But don't forget that I also said:

     Other environments may make it difficult to do the same.  In such
     environments Ada might be clearly better, though the controversy
     will continue to rage.  But why are you using such environments in
     the first place?

Note the final question.  It is not just rhetorical.  Anybody who
mandata Ada is probably also in a position to mandate BSD or an
equivalent environment.
-- 
Rahul Dhesi <dhesi@rahul.net>
also:  dhesi@cirrus.com

Re: Ada cost breakpoints (was Re: Air Force helping to undermine Ada)

[Michael Feldman]

In article <65260@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:
>In article <9303151702.AA01402@manta.nosc.mil> mshapiro@MANTA.NOSC.MIL (Michael D Shapiro) writes:
>> for smaller programs with shorter life
>> cycles, Ada might cost more to use over the full life cycle.
>> Has anyone done a study to find these breakpoints?  One pair I've
>> heard mentioned as the appropriate minima for Ada are 500K
>> source lines of delivered code and/or seven years life cycle.
>
>I have no study to point to, but from experience 500K SLOC is way too high
>for a minimum breakpoint to Ada.  The breakpoint depends on the complexity
>and number of people involved.  I dont know about you, but things start
>to seem complex to me much closer to 30K than 500K lines.
>Even 30K lines of C is a pretty frightening thought.

As a 20-year Snobol4 nut (Snobol4 is one of the languages Shapiro mentioned
as good for quickies), I feel qualified to describe something I did yesterday.
I needed to generate a file of calendar data to use in a little system I'm
developing for the department. Basically I needed a set of lines of
form <day of week> <month name> <day in month>, for several years.

I briefly considered doing it manually, or generating the file from a
Snobol4, C, or Ada program. As it turned out, I was able to use package
Calendar, along with a little student-written package that finds the
day of the week a given date falls on, and generate this file with a
1-shot Ada program in about 30 minutes. 

The program compiled and ran the first time; refining the output took 
a couple of change cycles.

Mostly, the changes were required to display the days and months
with initial caps. My first cut was to use Enumeration_IO, but
enum literals can be written only in full upper or full lower case,
and I thought this was unesthetic after seeing it "in print."

So I gave up on Enumeration_IO and used strings instead. Yes,
I know there are tricks one can use to get initial caps, but I
didn't want to spend the time - after all, it was a one-shot.

Given my two reusable components - Calendar and my own package -
I found Ada to be a very productive way to write a quickie.

No doubt someone will claim that it would have been just as fast with 
C or maybe PERL. Sure - no problem there. But the point of this post
is to emphasize that with a good personal collection of Ada components,
together with the "free" stuff like Calendar, Ada does NOT (read my
lips: NOT) require a big human-time overhead to write a 1-shot. Don't
believe all this trash you hear. What counts is how much reusable
functionality you have lying around. 

No doubt you will find better ways of doing this program - so would I 
if I wished to spend the time. But I had 30 minutes to do it, and I 
was done on time. So don't flame me - I brought the sucker in under
budget :-)

BTW - I used Ada/Ed. And the program was so simple - given the packages -
that I will now assign it to my freshmen as a 1-week-turnaround project.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"The most important thing is to be sincere, 
and once you've learned how to fake that, you've got it made." 
-- old show-business adage
------------------------------------------------------------------------

Re: Ada cost breakpoints (was Re: Air Force helping to undermine Ada)

[Robert I. Eachus]

In article <9303151702.AA01402@manta.nosc.mil> mshapiro@MANTA.NOSC.MIL (Michael D Shapiro) writes:

  > This implies to me that for smaller programs with shorter life
  > cycles, Ada might cost more to use over the full life cycle.
  > Certainly a 23-line reformatting utility to be used one time and
  > discarded thirteen minutes later can probably be written in
  > SNOBOL4 or ICON (or even AWK) more cheaply than in Ada.  Has
  > anyone done a study to find these breakpoints?  One pair I've
  > heard mentioned as the appropriate minima for Ada are 500K
  > source lines of delivered code and/or seven years life cycle.

  My first thought was to say that this was way too high, but then I
realized that 1) the complexity of the application has a major effect
on the breakpoint, and 2) that in general a line of Ada does cost more
than a line of C, FORTRAN, or COBOL.  The cost advantage comes because
a large application is much smaller in Ada.  (The relation does not
seem to be linear.  If you translate a one thousand line C program
into Ada, it will usually come out larger.  About three or four K,
they are the same size, and a hundred KSLOC of C maps to about 40 to
50 KSLOC of Ada.)

  Having said all that, my guess at the breakpoint is 25K lines of C
for embedded applications, 50K lines of FORTRAN mathmatical code, and
100K lines of screen management and report generation in COBOL.  (But
I personally would not go anywhere near those numbers before
switching.)

   Incidently, this is the crossover point where Ada development costs
will be smaller.  If the software will be maintained by someone not
the author, twenty lines of C can be too much.  My own (personal)
guideline is that C is only acceptable if I could rewrite it from
scratch in a week.  (I'm not an anti-C bigot, I use the same guideline
for assembler, BLISS, BCPL, and PL-M. :-)  That usually turns out to
be about a device driver.

   It is interesting to note that most Unix utilities are in this size
range or smaller.



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...