Re: best ADA 95 bible ? (fwd)

Re: best ADA 95 bible ? (fwd)

[Barbara W. Barnes]

My wife kindly sent me copies of some recent messages regarding books
on comp.lang.ada. Some of the information was a little out of date and
so I felt it might be helpful to add a few notes.

>---------- Forwarded message ----------
>Date: Sat, 19 Feb 2000 02:52:30 -0000
>From: Nick Roberts <nickroberts@callnetuk.com>
>Newsgroups: comp.lang.ada
>Subject: Re: best ADA 95 bible ?
>
>"Programming in Ada 95" by John Barnes [Addison-Wesley 1996, ISBN
>0201877007] is often considered to be the canonical book on Ada 95.

Please note that Programming in Ada 95 is now in its second edition
(as from June 98) and the new ISBN number is 0-201-34293-6.

>
>I think its greatest strengths are that it covers nearly all aspects
of the
>language, that it is always precise, and that it covers the important
>subjects in some depth. However, this book discusses the language
largely
>from the point of view of a computer scientist or experienced
programmer; it
>might be rather overwhelming for someone learning to program.

A significant change from the first edition is the addition of some
real working programs and a CD containing them and the Aonix compiler.
There are quite a few other improvements as well. Even so by creative
type-setting, I manged to keep the page count unchanged by setting the
answers in double columns. I hope the examples will help a lot
especially for the beginner.

But rats!  Perfection is not easily acheived and the book is not
always 100% precise despite Nick's kind words Just as the third
printing of this edition came out, a friend from British Aerospace
pointed out an error in one example. The rational number package
raises Constraint_Error on attempting to divide by a negative number.
How awful! And it was tested by many famous Ada folk who will remain
anonymous.

Indeed this error can be traced right back to the first edition of the
predecessor book which I wrote in 1981. This has at last convinced me
of the value of testing. It is clearly not enough just to write a
program and assume that it will be correct. The really old reader
might recall that programmers were surprised to find in the 1950s that
they made mistakes. Why should one write incorrect programs they
thought.

My apologies.

Incidentally, a French translation just came out ISBN 2-7117-8651-X.
The above error is corrected in that translation. Mais, peut-etre,
autres erroirs, may avez been introduced - tiens!

John Barnes

Re: best ADA 95 bible ? (fwd)

[Nick Roberts]

My thanks to John for updating my information (that's another book on my
shopping list :-).

I think anyone who has had much experience with technical books will agree
that one error in an entire book is a pretty good standard. I've bought
technical books - especially from a publisher which I shall identify only as
sounding like a playwright, a Scotsman, and a small geographical feature -
in which I could, quite literally, count at least one technical error on
each and every page (that contained technical information). And this would
be in addition to copious spelling mistakes and grammatical errors, as well
as clumsy phraseology.

So, I think John can feel extremely proud that he has found just one
significant error in his book (after publication), which otherwise IMHO
displays exemplary standards for this tricky kind of subject.

As for testing, my motto, after many, many years of programming experience
(I hate saying that ;-), could easily be "test, test, and test again". One
of the things, possibly, that marks out the professional programmer from the
wannabees, is the habit of writing test code that is as sophisticated as the
code it tests. (Now, all I have to do is to remember my own advice :-)

--
Nick Roberts
http://www.adapower.com/lab/adaos

Re: best ADA 95 bible ? (fwd)

[JP Thornley]

In article <38b32dc9@eeyore.callnetuk.com>, Nick Roberts
<nickroberts@callnetuk.com> writes
>As for testing, my motto, after many, many years of programming experience
>(I hate saying that ;-), could easily be "test, test, and test again".

Which would be a more convincing argument if the error in the Rational
package had been found by testing, rather than by simply reading the
code.

Isn't it true that every study into the effectiveness of different
verification techniques shows that code reviews are the most effective?

Cheers,

Phil Thornley

-- 
JP Thornley