Re: Ada cost breakpoints

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

[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

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

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