TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: "Team Ada: Ada Programming Language Advocacy (83 & 95)" <[log in to unmask]>
Date: Wed, 26 Jan 2005 17:45:34 -0800
MIME-version: 1.0
Reply-To: Art Vanden Berg <[log in to unmask]>
Content-type: text/plain; format=flowed; charset=iso-8859-1
From: Art Vanden Berg <[log in to unmask]>
X-cc: Paul Colin Gloster <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Content-transfer-encoding: quoted-printable
Parts/Attachments: text/plain (96 lines)
Paul,

All valid points, but sadly Ada is not available for the micro-controllers 
I'm using in the Mark II glider. And I would have to write all my libraries 
from scratch, rather than working on a base of other's proven code.  There 
is also the issue that I would need to learn a new language, which I admit 
I'm somewhat lazy about.

As things turned out, the only onboard software bug that caused any problem 
was a single case of forgetting to use fabs(float) in one conditional line.

Microsoft's stuff is a different story, however. But the ground software is 
non-critical.

Sincerely,
Art Vanden Berg


At 05:32 AM 26/01/2005, you wrote:
>Laurent GUERBY quoted from http://members.shaw.ca/sonde/software.htm on
>the Team Ada email list:
>
>"[...]
>What Language / Platform?
>
>[..]
>
>[..] But Ada's structure and design-for-reliability approach is
>burdened by poor support on "civilian" platforms, and in particular a
>very large instruction set that, in the view of many experts in the
>field, hinders its in-practice suitability for reliable systems, no
>matter what its reputation is. [..]"
>
>Uhh, how about the proper affordable x86 Ada compilers which do not even
>need an 80286; which are still available on the market; and which are not
>the GNAT DJGPP trash?
>
>"What I settled on was using an old language, C, in a rigorous way. [..]
>
>[..] The book Safer C - Developing Software for
>High-Integrity and Safety-Critical Systems, has also been a great help,
>as have numerous websites (most of which I've since lost track of), on
>developing good programming practices.
>[...]"
>
>Losing your rationale does not seem like a good practice. Can even 60% of
>the problems Les Hatton points out in his book even occur in Ada? I am
>reminded of a colleague some of whose plans I had to review a few months
>ago, who acknowledged that C is dangerous but said that it can be (and
>worse, should be) used so long as special care is taken to write safe C.
>
>A quotation from that document written last year which purported to be
>following safe C coding:
>
>"No Magic Numbers
>[..]
>One of the many useful features of the C language is the #define construct
>which allows the definition of a value, which can be used anywhere in the
>code, for example:
>#define FOO 13
>// lots of code
>jibble = FOO * myVar;
>bar = quux/FOO;
>This allows for a simple alteration to the first line, to alter the value
>through out the program."
>
> From page 20 of Brian W. Kernighan's and Rob Pike's "The Practice of
>Programming": "DEFINE NUMBERS AS CONSTANTS, NOT MACROS. C programmers have
>traditionally used #define to manage magic number values. The C
>preprocessor is a powerful but blunt tool, however, and macros are a
>dangerous way to program because they change the lexical structure of the
>program underfoot. Let the language proper do the work." They recommend
>a couple of alternatives for constant numbers in C. Interestingly, another
>of Kernighan's books was cited by the aforementioned colleague.
>
>More noteworthy still is the contrast between expert C practitioners'
>advice conflicting with the aforementioned recommendation of #define
>CONSTANT and the second item in the same document's bibliography:
>
>"Bibliography
>F. P. Brooks (1995). "The Mythical Man Month and Other Essays on Software
>Engineering". Addison.
>Wesley Publishing Company.
>
>L. Hatton (1994). "Safer C: Developing Software in High-integrity and
>Safety-critical Systems". McGraw-
>Hill Education - Europe."
>
>Furthermore, the aforementioned colleague cited one of Steve C.
>McConnell's books on software engineering, but as Steve C. mac Chonaill
>actually defended Microsoft in an interview in "Dr. Dobb's Journal" does
>not help his credibility.
>
>Regards,
>Paul Nicolas Cóilin Gloster

ATOM RSS1 RSS2