Re: Free e-book discussing the C Standard

[Derek M Jones <derek@NOSPAMknosof.co.uk>]

Jim,

Looks like you are a fast reader.

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

I think you are reading what I wrote through Ada 'tinted' glasses.

> You suggest that Ada was more expensive than C for DoD development
> because of the number of cancelled Ada projects.

Subsection 8.6 of sentence 0 does not make a comparison against C.

> 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.

The total cost of a project would also need to be taken into
account.  There is no specific comparison against C.

>        Do you have any studies showing the cancellation
> rates of Ada projects versus projects in C?

No I do not.  Do you?  I suspect that many projects are cancelled
for non-programming language related reasons.

> 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?

I have failed to find much reliable data on this subject.
Do you have any?

> 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?

I am sure there have also been plenty of instances of an irrational
preference of Ada over C.

>           You note that the directive
> mandating the use of Ada was cancelled in 1997. Do you know why it
> was cancelled?

Is there a reason other than that stated in the quoted reference?

> 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.

While I did not say it did, it is does represent a big climb down
(given the commitment previously given to the language).

> Cancellation of the Ada mandate was part of a larger trend in the
> DoD to move towards Commercial Off The Shelf (COTS) solutions.

I don't see a causal connection between the two.

> 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.

Why do people choose to use one language over another?  It
often seems to be the case that people rationalise their decision
after they have made it.
 
> 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.

The term lower complexity is better than extra simplicity.
I would agree that reducing complexity can reduce the number
of errors made.

Ada has a particular model of concurrency.  I would expect fewer
concurrency related errors to be made, compared to C, for those
cases where the application concurrency model had a straight
forward mapping to the Ada concurrency model.  When there is not
a good fit between concurrency models it is can be very difficult
to estimate relative complexity.

> 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.

I would not make a easy/hard distinction.  People make mistakes
for a variety of reasons, including information overload (really
another term for complexity), ignorance, lack of competence, etc.