Free e-book discussing the C Standard

Free e-book discussing the C Standard

[Derek M Jones]

All,

Fans of Ada often talk a lot of nonsense about C

Those of you not willing to fork out $18 for a copy of the C
Standard can search for material in the C Standard (at least
you will be once google gets around to indexing it) here:
http://c0x.coding-guidelines.com

A detailed analysis is provided in my book "The New C Standard:
An economic and cultural commentary".  The complete book is
available as a freely downloadable pdf (8M byte).  You can
download a copy from one of:

http://www.cwic-solutions.co.uk/docs/cbook1_0a.pdf
http://homepage.ntlworld.com/dmjones/cbook1_0a.pdf

The material also includes a significant amount of discussion
on coding guidelines.  In particular it attempts to use the
results of cognitive psychology studies to suggest and/or reject
coding guidelines (ie, the human factors of programming).

Other book material, and some subsets of it (including just the
coding guideline subsections), can be found at:
http://www.knosof.co.uk/cbook/cbook.html

You can get the background here:
http://theinquirer.net/?article=24092

Re: Free e-book discussing the C Standard

[Pascal Obry]

Derek M Jones <derek@NOSPAMknosof.co.uk> writes:

> Fans of Ada often talk a lot of nonsense about C

That's a nice start for an invitation to read you book :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Free e-book discussing the C Standard

[Derek M Jones]

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

Re: Free e-book discussing the C Standard

[jimmaureenrogers]

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

Re: Free e-book discussing the C Standard

[Derek M Jones]

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.

Re: Free e-book discussing the C Standard

[jimmaureenrogers]

Derek M Jones wrote:
> 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.

Perhaps, but I also think you are looking at Ada with C '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.

If there is no comparison against C, then why is this contents even
in a work about C? Without a comparison, at least implied, there seems
to be no reason to mention Ada in your writing.

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

I agree. There are very few useful studies comparing languages.
My experience shows that most projects are cancelled for many
reasons that have no bearing on the language used.

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

I have only one such study.
http://www.adaic.com/whyada/ada-vs-c/cada_art.html

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

I am not so sure. If there had been, then Ada would be used more
instead of 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?

The reason stated by Rod Page at the time he cancelled the mandate
was that Ada was now a mature language and did not need any special
protection. It also appeared at the time that the DoD no longer wanted
to fund its Ada enforcement bureaucracy.

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

It certainly appeared that way at the time. It still does appear
that way.

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

Ada was viewed by DoD upper management as a language designed
specifically for military use. In their mind they associated Ada
with $1000.00 toilet seats and other costly items designed specifically
for military use. The reasoning seemed to be along the lines of
"If the military can get by with commercial toilet seats, then
why not also use commercial programming practices and tools?"

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

That is certainly true about human behavior in general, and is not
isolated to choosing programming languages.

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

The only currently popular concurrency model not directly supported
by the Ada concurrency model is lock-free synchronization. Ada is
no more complex to use for lock-free algorithms than is C.

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

I was making the broad assumption that "all other factors are equal"
with regard to ignorance, lack of competence, etc.

Jim rogers

Re: Free e-book discussing the C Standard

[Frank J. Lhota]

Derek M Jones wrote:
> 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

And if an Ada fan does so, I hope s/he does it in a less confrontational 
  manner.