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...

Re: Ada cost breakpoints

[Bob Munck]

In V93 #137, mshapiro@manta.nosc.mil (Michael D Shapiro) writes:
>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.

The esteemed and strange Dr. Shapiro is obviously alluding to the
serious problem now showing up in DoD programs in the
fractional-statement range.  We are beginning to realize that any Ada
project that does not involve at least a full legal Ada statement can
take femto-seconds to complete and cost $billions.  One project for a
service that I won't identify (but it's in the NNE corner of the
Pentagon) involves only the variable name and ":" of an assignment
statement (ending before the "=") now has a budget greater than that
of several European nations.

Bob Munck

(I realize that we don't really need more humor in Info-Ada as long as
we have the Ted and Greg Show.)

Re: Ada cost breakpoints

[Gregory Aharonian]

>Bob Munck
>
>(I realize that we don't really need more humor in Info-Ada as long as
>we have the Ted and Greg Show.)

   As a taxpayer, Bobby, I resent your sarcasm-while-on-the-taxpayer-dole.
Ted and me might be clowns, but at least we have the balls to do it with
our own money, while you do it as part of your cushy-taxpyer-funded job.

Answer me this, how long would Paramax remain a part of the STARS program
if the DoD said that the contractors would have to fund STARS R&D with
their own money?  Your management would stop your efforts in nanoseconds,
not wanting to waste good Paramax money on a project of no commercial value.
Heck, they wouldn't even give you a charge number to investigate for one
hour whether Paramax show fund STARS R&D.

In short, Bob, start spending your own money on Ada activities and see
how fast your story changes.  You soon will know the difference between
being a self-funded clown and a taxpayer funded clown.

Greg Aharonian
Source Translation & Optimization

P.S. I am still waiting for a good rebuttal for my comments on STARS waste.
That is, unless you agree that STARS was founded partly on lies, that ASSET
is being mismanaged, that in light of VHDL STARS is showing little vision
and that STARS contractors have no honest reasons for not showing up at
CASE conferences and shows.
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178

Re: Ada cost breakpoints

[crispen]

emery@mitre-bedford.arpa  (David Emery) sez:

>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.  

Sorry to jump into this, but *I've* considered what happens -- you
write a package body that performs the equivalent functions (including
emulations and workarounds) in a non-BSD environment instead of pragma
Interface'ing in the private part of the package spec.  So what?  How
hard can that be for someone familiar with Unix and whatever proprietary
DOS you're trying to interface to?  Surely we're all familiar with
having several package bodies for a package spec by now.

>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?)

Yup, it sure is, but we have hope that eventually the world will awaken
to the True Light ;-)

Seriously, Posix provides us with a standard, non-priprietary set of
OS interface semantics.  These semantics are (a) guaranteed to work
on a whole bunch of machines (or at least, if they don't work, the
vendor is obliged to admit that he has a problem); and (b) guaranteed
to change slowly, not at the whim of the vendor.  If you use Posix OS
interface semantics, you have reason to expect that your code will be
usable for a long, long time, and that changes will be relatively minor,
and announced to the world ahead of time.

It occurs to me that it might be sensible for programs to require
that all OS interfaces which are not pre-defined in the language (e.g.,
Text_IO, task stuff) be defined in Posix syntax.

What does the new AQ&S say about that?
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   Who will babysit the babysitters?  |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

Re: Ada cost breakpoints

[David Emery]

Open, Read, Write, pipes, Fork and Exec are included in POSIX
standards.  Sockets, for instance, are not currently in any approved
POSIX standards.  Therefore, code written using sockets is *NOT*
guaranteed portable in a POSIX environment (e.g.  Open VMS, CTOS or
POSIX-compliant MVS, for instance).  Sockets are a BSD extension
(which is now included in System V).  Sockets packages exist for other
operating systems, but they're not "open" in the sense of formally
standardized.  Your semantics may vary...

>It occurs to me that it might be sensible for programs to require
>that all OS interfaces which are not pre-defined in the language (e.g.,
>Text_IO, task stuff) be defined in Posix syntax.

Could you please explain this?  What is "Posix syntax"?  I'm not
familiar with that term...

			dave
			(IEEE P1003.5 POSIX/Ada Binding Technical Editor)