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

[matwood%peruvian.cs.utah.edu@cs.utah.edu (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.