* Ada cost breakpoints (was Re: Air Force helping to undermine Ada)
@ 1993-03-15 17:02 Michael D Shapiro
1993-03-21 5:19 ` Alex Blakemore
1993-03-22 18:58 ` Robert I. Eachus
0 siblings, 2 replies; 10+ messages in thread
From: Michael D Shapiro @ 1993-03-15 17:02 UTC (permalink / raw)
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. 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.
================================================================
Michael D. Shapiro, Ph.D. e-mail: mshapiro@nosc.mil
NCCOSC RDT&E Division (NRaD) Code 411 San Diego CA 92152-7560
Voice: (619) 553-4080 FAX: (619) 553-4808 DSN: 553-4080
[Until January 1992 we were Naval Ocean Systems Center (NOSC)]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Ada cost breakpoints (was Re: Air Force helping to undermine Ada) 1993-03-15 17:02 Ada cost breakpoints (was Re: Air Force helping to undermine Ada) Michael D Shapiro @ 1993-03-21 5:19 ` Alex Blakemore 1993-03-21 19:01 ` Ada cost breakpoints Mark Atwood 1993-03-21 23:42 ` Ada cost breakpoints (was Re: Air Force helping to undermine Ada) Michael Feldman 1993-03-22 18:58 ` Robert I. Eachus 1 sibling, 2 replies; 10+ messages in thread From: Alex Blakemore @ 1993-03-21 5:19 UTC (permalink / raw) In article <9303151702.AA01402@manta.nosc.mil> mshapiro@MANTA.NOSC.MIL (Michael D Shapiro) writes: > for smaller programs with shorter life > cycles, Ada might cost more to use over the full life cycle. > 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. 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. -- --------------------------------------------------- Alex Blakemore alex@cs.umd.edu NeXT mail accepted ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Ada cost breakpoints 1993-03-21 5:19 ` Alex Blakemore @ 1993-03-21 19:01 ` Mark Atwood 1993-03-21 22:50 ` Rahul Dhesi 1993-03-21 23:42 ` Ada cost breakpoints (was Re: Air Force helping to undermine Ada) Michael Feldman 1 sibling, 1 reply; 10+ messages in thread From: Mark Atwood @ 1993-03-21 19:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Ada cost breakpoints 1993-03-21 19:01 ` Ada cost breakpoints Mark Atwood @ 1993-03-21 22:50 ` Rahul Dhesi 1993-03-23 3:13 ` Complexity of "distributed" v "monolithic" (was Re: Ada cost breakpoints) Mark Atwood 1993-03-24 22:24 ` Ada cost breakpoints David Emery 0 siblings, 2 replies; 10+ messages in thread From: Rahul Dhesi @ 1993-03-21 22:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Complexity of "distributed" v "monolithic" (was Re: Ada cost breakpoints) 1993-03-21 22:50 ` Rahul Dhesi @ 1993-03-23 3:13 ` Mark Atwood 1993-03-24 22:30 ` David Emery 1993-03-24 22:24 ` Ada cost breakpoints David Emery 1 sibling, 1 reply; 10+ messages in thread From: Mark Atwood @ 1993-03-23 3:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Complexity of "distributed" v "monolithic" (was Re: Ada cost breakpoints) 1993-03-23 3:13 ` Complexity of "distributed" v "monolithic" (was Re: Ada cost breakpoints) Mark Atwood @ 1993-03-24 22:30 ` David Emery 0 siblings, 0 replies; 10+ messages in thread From: David Emery @ 1993-03-24 22:30 UTC (permalink / raw) When designing distributed applications, consistency becomes more important and harder to achieve. If you have a pipe of three programs, for instance, with a common data stream, it's hard to make sure that a change to the data stream definition is adopted by all three programs. In our experience doing client/server in Ada, the Ada compiler and library system (that so many people complain about) is instrumental in keeping our distributed software in sync. dave ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Ada cost breakpoints 1993-03-21 22:50 ` Rahul Dhesi 1993-03-23 3:13 ` Complexity of "distributed" v "monolithic" (was Re: Ada cost breakpoints) Mark Atwood @ 1993-03-24 22:24 ` David Emery 1993-03-25 7:00 ` Rahul Dhesi 1 sibling, 1 reply; 10+ messages in thread From: David Emery @ 1993-03-24 22:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Ada cost breakpoints 1993-03-24 22:24 ` Ada cost breakpoints David Emery @ 1993-03-25 7:00 ` Rahul Dhesi 0 siblings, 0 replies; 10+ messages in thread From: Rahul Dhesi @ 1993-03-25 7:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Ada cost breakpoints (was Re: Air Force helping to undermine Ada) 1993-03-21 5:19 ` Alex Blakemore 1993-03-21 19:01 ` Ada cost breakpoints Mark Atwood @ 1993-03-21 23:42 ` Michael Feldman 1 sibling, 0 replies; 10+ messages in thread From: Michael Feldman @ 1993-03-21 23:42 UTC (permalink / raw) In article <65260@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes: >In article <9303151702.AA01402@manta.nosc.mil> mshapiro@MANTA.NOSC.MIL (Michael D Shapiro) writes: >> for smaller programs with shorter life >> cycles, Ada might cost more to use over the full life cycle. >> 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. > >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. As a 20-year Snobol4 nut (Snobol4 is one of the languages Shapiro mentioned as good for quickies), I feel qualified to describe something I did yesterday. I needed to generate a file of calendar data to use in a little system I'm developing for the department. Basically I needed a set of lines of form <day of week> <month name> <day in month>, for several years. I briefly considered doing it manually, or generating the file from a Snobol4, C, or Ada program. As it turned out, I was able to use package Calendar, along with a little student-written package that finds the day of the week a given date falls on, and generate this file with a 1-shot Ada program in about 30 minutes. The program compiled and ran the first time; refining the output took a couple of change cycles. Mostly, the changes were required to display the days and months with initial caps. My first cut was to use Enumeration_IO, but enum literals can be written only in full upper or full lower case, and I thought this was unesthetic after seeing it "in print." So I gave up on Enumeration_IO and used strings instead. Yes, I know there are tricks one can use to get initial caps, but I didn't want to spend the time - after all, it was a one-shot. Given my two reusable components - Calendar and my own package - I found Ada to be a very productive way to write a quickie. No doubt someone will claim that it would have been just as fast with C or maybe PERL. Sure - no problem there. But the point of this post is to emphasize that with a good personal collection of Ada components, together with the "free" stuff like Calendar, Ada does NOT (read my lips: NOT) require a big human-time overhead to write a 1-shot. Don't believe all this trash you hear. What counts is how much reusable functionality you have lying around. No doubt you will find better ways of doing this program - so would I if I wished to spend the time. But I had 30 minutes to do it, and I was done on time. So don't flame me - I brought the sucker in under budget :-) BTW - I used Ada/Ed. And the program was so simple - given the packages - that I will now assign it to my freshmen as a 1-week-turnaround project. Mike Feldman ------------------------------------------------------------------------ Michael B. Feldman co-chair, SIGAda Education Committee Professor, Dept. of Electrical Engineering and Computer Science School of Engineering and Applied Science The George Washington University Washington, DC 20052 USA (202) 994-5253 (voice) (202) 994-5296 (fax) mfeldman@seas.gwu.edu (Internet) "The most important thing is to be sincere, and once you've learned how to fake that, you've got it made." -- old show-business adage ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Ada cost breakpoints (was Re: Air Force helping to undermine Ada) 1993-03-15 17:02 Ada cost breakpoints (was Re: Air Force helping to undermine Ada) Michael D Shapiro 1993-03-21 5:19 ` Alex Blakemore @ 1993-03-22 18:58 ` Robert I. Eachus 1 sibling, 0 replies; 10+ messages in thread From: Robert I. Eachus @ 1993-03-22 18:58 UTC (permalink / raw) In article <9303151702.AA01402@manta.nosc.mil> mshapiro@MANTA.NOSC.MIL (Michael D Shapiro) writes: > 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. 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. My first thought was to say that this was way too high, but then I realized that 1) the complexity of the application has a major effect on the breakpoint, and 2) that in general a line of Ada does cost more than a line of C, FORTRAN, or COBOL. The cost advantage comes because a large application is much smaller in Ada. (The relation does not seem to be linear. If you translate a one thousand line C program into Ada, it will usually come out larger. About three or four K, they are the same size, and a hundred KSLOC of C maps to about 40 to 50 KSLOC of Ada.) Having said all that, my guess at the breakpoint is 25K lines of C for embedded applications, 50K lines of FORTRAN mathmatical code, and 100K lines of screen management and report generation in COBOL. (But I personally would not go anywhere near those numbers before switching.) Incidently, this is the crossover point where Ada development costs will be smaller. If the software will be maintained by someone not the author, twenty lines of C can be too much. My own (personal) guideline is that C is only acceptable if I could rewrite it from scratch in a week. (I'm not an anti-C bigot, I use the same guideline for assembler, BLISS, BCPL, and PL-M. :-) That usually turns out to be about a device driver. It is interesting to note that most Unix utilities are in this size range or smaller. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~1993-03-25 7:00 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1993-03-15 17:02 Ada cost breakpoints (was Re: Air Force helping to undermine Ada) Michael D Shapiro 1993-03-21 5:19 ` Alex Blakemore 1993-03-21 19:01 ` Ada cost breakpoints Mark Atwood 1993-03-21 22:50 ` Rahul Dhesi 1993-03-23 3:13 ` Complexity of "distributed" v "monolithic" (was Re: Ada cost breakpoints) Mark Atwood 1993-03-24 22:30 ` David Emery 1993-03-24 22:24 ` Ada cost breakpoints David Emery 1993-03-25 7:00 ` Rahul Dhesi 1993-03-21 23:42 ` Ada cost breakpoints (was Re: Air Force helping to undermine Ada) Michael Feldman 1993-03-22 18:58 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox