From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,456bbc1eb1b5c5bc
X-Google-Attributes: gid103376,public
From: mfb@mbunix.mitre.org (Michael F Brenner)
Subject: Re: "Density" of Ada 95 vs. Ada 83
Date: 1996/09/20
Message-ID: <51uaa9$2ku@linus.mitre.org>#1/1
X-Deja-AN: 184190244
references: <32419F92.1E13@lmtas.lmco.com>
organization: The MITRE Corporation, Bedford Mass.
newsgroups: comp.lang.ada
Date: 1996-09-20T00:00:00+00:00
List-Id: <comp.lang.ada>


> ...it should take fewer lines of Ada 95 code to express the same
> algorithms, data structures, etc. (on the average).
>
> Does anyone have some good quantitative information on whether Ada 95 is
> "denser" than Ada 83 for a given domain, and it so, how much "denser" on
> average?

Without discussing the new object oriented, CORBA, remote procedure calls,
Posix compatibility, C language parameter compatibility, and built-in
libraries, which make many Ada-83 programs replaceable by a tiny Ada-95
procedure, there is one feature of Ada-95 which has a measurable effect
on lowering lines of code. That feature is MOD types. In Ada-83 many
type conversions, procedure calls, libraries of functions, and 
unchecked_conversions were required to do AND, OR, UNSIGNED_ADD, and
the other features that systems programmers and signal processor
programmers need in all their integers. These operations are now
built in to the Ada-95 MOD type, eliminating libraries
of functionalities, reducing all methods to the built-in functions "+",
"*", "AND", etc., except one. The one operation that is missing is
checked conversion between 32-bit signed and 32-bit unsigned numbers;
to do this in Ada-95 requires an unchecked_conversion, unlike Ada-83,
which permitted the user to implement unsigned numbers (without literals)
by using a single signed type with two sets of operators (signed
operators and unsigned operators). 

I recently downloaded EMCC from the net for use in HYTLIST, and converted
it to Ada-95. I made the minimal changes necessary, and measured them in
both function points and source code bytes (I did not measure them in 
less meaningful lines of code). The source code (when pkzipped) took up a
1.4 megabyte floppy, overflowing to a second floppy containing 26071 bytes.
After conversion to Ada-95 it fit on the 1.4 megabyte floppy (just barely).
This slight reduction was despite having to double the  generic packages, 
so they work both on signed and unsigned types in Ada-95. Just use a text
editor and copy-paste each one, and put the word MOD in the second copy. 
However, Ada-95 libraries, mod types, and built-in interfaces (no tagged 
types or protected records were used in this conversion) resulted in lines of 
code savings equal to the doubled generics, and an additional 2 percent
savings.

I estimate that by using tagged types, the EMCC packages would save 
about another 5 percent, because there is a lot of code that switches
device drivers through complicated levels of packages, case statements,
and alternate package bodies for the command language to compile in
to the same visible part to get the same effect on different output 
devices. This kind of code is a prime candidate for a tagged type, and
will become not only smaller, but much easier to modify, expand, and 
configure when adapted to the Ada-95 paradigms instead of just a minimal
conversion. Contradictingly, it will actually run faster also, despite
the run-time dispatching I am proposing to put into it, because the
tricks it now uses to get the effects of run-time dispatching use 
a couple of CPU cycles, even though recompiling package bodies is part
of those tricks. This is contrary to what would be expected with a
program designed with hard realtime embedded techniques, where adding
run-time dispatching would cause cache-voiding jumps and thus make it
run slower. 

The real problem is that so many people base their cost estimates on lines
of code. I once changed a spherical trigonometric equation in a satellite
location program (one line of code), using up approximately 6 months of
effort. How does your estimation model predict something like that?
Also, I can write 5 million lines of code in one minute (time me):

with EMCC;
procedure mike is
  package my_EMCC is new EMCC (integer, integer, integer);
begin
  my_EMCC.go;
end mike;

A second minute to compile, link, and run it. How does your model
handle the fact that the word NEW above automatically programmed
5 million lines of code?

D
D
begin