gbt@sequoia.cray.com (Greg Titus) (04/02/91)
In article <jls.670541138@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: >>ADA seems to have a lot in common with PL/1. I program in C and have no >>problems. > >Quantify, please. What is the complexity measure of the programs you >work on? Specifically, provide the following: > >a) SLOC >b) Number of developers >c) Number of configurations (targets, options, etc) >d) Number of subcontractors/sites >e) Number of threads of control >f) Number of estimated years for project >g) Estimated cost >h) Number of development environments/languages >i) Number of paradigms (e.g. real-time embedded, data base, GUI, etc) >j) Documentation/design standards required to adhere to (e.g. 2167A, etc) > >Only when these sorts of things are taken into account does the statement >that you "have no problems" programming in C acquire enough semantic >content to be useful. > >Until then, you could be hacking out 2k programs on a PC, in which case >C might actually be up to the job. > >P.S. Does "no problems" include no problems with pointers walking off > into hyperspace, functions returning the wrong type of result, > functions getting called with the wrong type/number of arguments, > inability to read the code two weeks later, or any of a number of > other problems commonly encountered by C folks? I am not the original author of the "I have no problems" post, but ... I have extensive experience with C (>500k LOC lifetime, two projects >100k LOC each) and a fair amount with Ada (>50k LOC lifetime, ~30k as part of a very large compiler). (Let LOC mean text lines including comments and white space; divide by ~2 to get ~40-character lines of actual language constructs.) I've worked in teams of from 1 to 10 people, including 10 people divided into two groups widely separated geographically, and on projects with costs up to nearly $10^7. The language really doesn't matter that much (caveats later). If you get a decent spec, produce an overall design and have *somebody else* try to break it, produce interface documents to match the modularity in the design, do module designs and have *somebody else* try to break them, code to the module designs, unit test, integrate, have *somebody else* break it (of course they'll be able to at this point), fix it, and deliver it, it'll work fine. Do the above, and you can even write large working systems in assembly code. Leave out enough of the above, and no language can save your project. Owning the best hammer in the world won't help you if the blueprints for your house are wrong in the first place. >> P.S. Does "no problems" include no problems with pointers walking off >> into hyperspace, ... A far greater problem is pointers wandering off to the wrong element of the data structure, and neither language prevents your writing code to do this. >> ... functions returning the wrong type of result, >> functions getting called with the wrong type/number of arguments, Ada wins big here. Some C compilers (bless their souls) support function declarations that include the argument types, and have gripers you can switch on to tell you when you use an undeclared function. >> inability to read the code two weeks later, ... To programmers equally comfortable with the languages, I'd say they're about equally easy/hard to read. Nothing beats good comments. Why, you can't even write self-documenting COBOL. ;-) >> ... or any of a number of >> other problems commonly encountered by C folks? Such as ... 1. Lack of a standard that all vendors must at least support a subset of. Ada wins. 2. Lots of implementation-dependent oddities, some of which seem to be *designed* to prevent anyone writing portable code. Ada is way ahead here, but it certainly can't touch pure Lisp. (big ;-) ) Ada gives you more help in implementing large systems, but C works just as well if you do large systems the way they're supposed to be done. greg Meta-disclaimer: These opinions have been created and shaped by years of making mistakes, mostly ;-) before I worked for CRI. -- -------------------------------------------------------------- Greg Titus (gbt@zia.cray.com) Compiler Group (Ada) Cray Research, Inc. Santa Fe, NM Opinions expressed herein (such as they are) are purely my own.