Re: Free e-book discussing the C Standard

["jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net>]

Derek M Jones wrote:
> Pascal,
>
> >> Fans of Ada often talk a lot of nonsense about C
> >
> > That's a nice start for an invitation to read you book :)
>
> I thought so to, :-), combining truth and something of
> a challenge.
>
> It is, of course, equally true that fans of C often talk a
> lot of nonsense about Ada.  But I will leave it to an Ada
> fan to write a book and post this statement to comp.lang.c

Your work certainly has a negative point of view concerning Ada.

You suggest that Ada was more expensive than C for DoD development
because of the number of cancelled Ada projects. This implies that
the number of cancelled projects in Ada was significantly more than
the number of cancelled projects in C for the same period, or over any
similar period. Do you have any studies showing the cancellation
rates of Ada projects versus projects in C?

Do you have any studies showing that the up-front development costs
of Ada programs exceeded those of C programs when normalized on
project complexity?

During the time of the DoD Ada mandate many people insisted on using
validated Ada compilers while they were not concerned about using
validated C compilers. How do you explain that, except for an
irrational preference for C over Ada? You note that the directive
mandating the use of Ada was cancelled in 1997. Do you know why it
was cancelled? When was the mandate to use C cancelled?

Of course, there was never a mandate to use C. Cancellation of the
Ada mandate simply placed C and Ada on the same footing as far as
the Dod was concerned for choice of languages. It did not reject
Ada as a language.

Cancellation of the Ada mandate was part of a larger trend in the
DoD to move towards Commercial Off The Shelf (COTS) solutions.
This happened under the title of acquisition modernization.
The results of this policy have been mixed. Many projects have been
delivered at reduced initial development cost. Many projects fail
to meet all their requirements, and request waivers of requirements.
The COTS products were not developed to DoD requirements, and simply
do not meet those requirements. Another problem that is becoming
ever more apparent is in the area of maintenance of the software.
DoD products tend to have lifetimes on the order of several decades,
while commercial software products tend to have support lifetimes on
the order of two to three years. Many DoD systems built on COTS
software has become unsupportable long before the planned end of
lifetime for the systems they implement.

Acquisition modernization was simply an attempt to improve the short
term costs of development without adequate concern for the long term
costs of support. In this environment C has again thrived in DoD
projects. Likewise, C++ and Java have also thrived in DoD projects.
C++ has a language standard that is very nearly impossible to implement
completely. Java has no language standard at all. Java is whatever Sun
says it is, no more, no less.

The C standard is at least implementable. That is good.

I wonder how well C is really suited for modern system development
when we need to deal with complex parallel systems using multi-core
CPUs. There are certainly C threading libraries. In fact several
flavors of C threading libraries exist. Threading libraries are not
yet part of any C standard. Does the lack of any C standard for
threading (or concurrency in general) make C more attractive for
development of concurrent system than Ada? I do not see how this
could be true.

You state that C is based on a single-threaded execution model.
C also deals with the interrubtability of functions due the receipt
of an interrupt.

Ada has built-in concurrency. Interrupt handling for Ada 95 is
built on its built-in concurrency. An Ada interrupt handler can
be implemented as a simple task suspended on a protected entry
associated with the interrupt. Only that task needs to deal with
the interrupt.

The single-threaded model of C presents more detailed complexity
to the C programmer when dealing with concurrency than the tasking
model does to the Ada programmer. This complexity is a paradox to
the C model of simplicity. The extra complexity faced by the C
programmer invites human error. The extra simplicity faced by the
Ada programmer reduces the opportunities for error. Correct
programs can be written in either language. Incorrect programs
can also be written in either language. This does not imply parity.
More errors will be created in the environment where errors are
easier to create and harder to avoid. Fewer errors will be created
in the environment where errors are harder to create and easier to
avoid.

Jim Rogers