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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ffe7b9269a00c843 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1993-03-23 04:18:18 PST Newsgroups: comp.lang.ada Path: sparky!uunet!europa.eng.gtefsd.com!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!peruvian.cs.utah.edu!matwood From: matwood%peruvian.cs.utah.edu@cs.utah.edu (Mark Atwood) Subject: Complexity of "distributed" v "monolithic" (was Re: Ada cost breakpoints) Date: 22 Mar 93 20:13:35 MST Message-ID: <1993Mar22.201336.5850@hellgate.utah.edu> Summary: a single executable should not be more complex Keywords: ada complexity loc distributed monolithic kernals Organization: University of Utah Computer Science References: <65260@mimsy.umd.edu> <1993Mar21.120121.16006@hellgate.utah.edu> Date: 1993-03-22T20:13:35-07:00 List-Id: In article 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> Organization: University of Utah Computer Science Keywords: ada complexity loc distributed monolithic kernals In article 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.