TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Subject:
From:
"W. Wesley Groleau x4923" <[log in to unmask]>
Reply To:
W. Wesley Groleau x4923
Date:
Mon, 21 Jun 1999 10:21:46 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (48 lines)
> I need data.
>
> .....  Note also that (as others have pointed out) a small sample of
> experience does not make a good argument.

One of my favorite quotes comes from someone not even in software:
"Someone with an experience is never at the mercy of someone with an argument."

Roger Racine has said more than once, "In my experience..."  So I think
some quantified experience is going to be more useful to him than
unquantified argument.  [Even though I believe the arguments myself and
have some of my own below. :-) ]

> (everyone I know would have to be fired if this were the case.  English is
> not the best language for expressing requirements).

Especially the English produced by most engineers! :-)

> Sorry, but I have to disagree.  The common pitfalls of coding, at least in
> C, are very well known (there are books on the subject).  Therefore, in a

I read the first two-thirds of the so-called classic "C Traps and
Pitfalls" There was a nearly incomprehensible two pages about the subtle
differences between various long strings of parentheses and asterisks.
The rest of it, I thought I understood well enough to know that the errors
just plain can't occur in Ada.  I've read more than one item advising that
code should be carefully reviewed by salaried humans for certain types of
errors _before_ compiling--types of errors that an Ada compiler will find
in the time a human takes to study ten SLOC of code.

> with Ada, but the cost of fixing coding errors is well known and can be
> estimated reasonably well.  So, again, the risk of cost increase is low.

If I understand this argument, I am amazed the anyone would think an
estimate of $65K +/- 10% is better than one of $20K +/- 50%

> Myths will not go away by calling them myths.  We need to prove it ("I
> don't have to; I am in the majority, say the C people." :-(  ).

Or like someone posted here a few months ago, that he/she lost a sale in a
scenario something like this:

"So what makes your product better than this other one?"

"Ours doesn't crash."

"B.S.! Everybody knows all software crashes."  <click>

ATOM RSS1 RSS2