* Re: is C good enough (was: Free ADA compiler)
1991-04-01 21:25 ` Jim Showalter
@ 1991-04-02 1:36 ` Greg Titus
0 siblings, 0 replies; 3+ messages in thread
From: Greg Titus @ 1991-04-02 1:36 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 3+ messages in thread