Re: Ada cost breakpoints

[dhesi@rahul.net (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