Customer balks at Ada -- any hope?

Customer balks at Ada -- any hope?

[mjsilva]

We're bidding on a custom industrial controller, and I've proposed to
write the firmware in Ada.  The powers-that-be here are satisfied with
that, but the customer is afraid nobody will be around to maintain it.
They're happier with C or C++, alas.  Anybody have any good answers to
their concern?

I realize that implicit in their position is a belief that Ada offers
no great tangible benefits to the project (even though the machinery to
be controlled is big, expensive and remotely-located), which I of
course strongly disagree with.  As I see it, the arguments are (1) Ada
will offer tangible benefits, both in reliability and in development
time, and (2) a decent programmer can pick up similar languages fairly
easily, especially for maintainence.  (Perhaps I should show them some
Ada source...).  Ideas?

Mike


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Customer balks at Ada -- any hope?

[Ken Garlington]

<mjsilva@my-deja.com> wrote in message news:8l01s4$gnr$1@nnrp1.deja.com...
> We're bidding on a custom industrial controller, and I've proposed to
> write the firmware in Ada.  The powers-that-be here are satisfied with
> that, but the customer is afraid nobody will be around to maintain it.
> They're happier with C or C++, alas.  Anybody have any good answers to
> their concern?

Well, I would say that you need to do at least two things:

(1) Define the advantages of Ada in tangible terms that have meaning to the
customer. For example:

(a) Are you going to charge the customer more to do it in C or C++?
(b) Is it going to take longer to do it in C or C++?
(c) How many more failures will there be in the C/C++ version -- from the
customer's point of view -- than in the Ada version? Alternately, will you
guarantee to fix any defects for free in the Ada version, but not in the
C/C++ version?

You can say "more reliable" until the cows come home, but if you can't
quantify that number somehow in relevant terms, who cares?

(2) Identify *all* of the potential risks, and their mitigation, for using
Ada. For example:

Is programmer training the only risk? What about the possibility that the
industrial controller hardware may go obsolete, and the replacement may not
have an Ada compiler? What about the host computer being used for software
development? Is it more likely that the selected Ada vendor may stop
supporting the product, or charge so much in the future that it becomes
economically infeasible to stay with Ada?

You'd better have answers to all of their questions (both current and
future), or you might as well do what they ask.

Re: Customer balks at Ada -- any hope?

[Samuel T. Harris]

Ken Garlington wrote:
> 
> Is programmer training the only risk? What about the possibility that the
> industrial controller hardware may go obsolete, and the replacement may not
> have an Ada compiler? What about the host computer being used for software
> development? Is it more likely that the selected Ada vendor may stop
> supporting the product, or charge so much in the future that it becomes
> economically infeasible to stay with Ada?

Of course the availability of Ada-to-C translators mitigates
the potential for Ada vendor not supporting, or ending support for,
current/future hardware! If there is or will be a C compiler then
there is or will be an Ada compiler.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: Customer balks at Ada -- any hope?

[Ken Garlington]

"Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote in message
news:3974A1D5.1F9AA2E5@Raytheon.com...
> Ken Garlington wrote:
> >
> > Is programmer training the only risk? What about the possibility that
the
> > industrial controller hardware may go obsolete, and the replacement may
not
> > have an Ada compiler? What about the host computer being used for
software
> > development? Is it more likely that the selected Ada vendor may stop
> > supporting the product, or charge so much in the future that it becomes
> > economically infeasible to stay with Ada?
>
> Of course the availability of Ada-to-C translators mitigates
> the potential for Ada vendor not supporting, or ending support for,
> current/future hardware! If there is or will be a C compiler then
> there is or will be an Ada compiler.

Are you sure that buying/maintaining/getting training for an Ada and a C
compiler is cheaper than just using a C compiler?

Are you sure that, if there's a C compiler that runs on the FWW (Future
Wonderful Workstation) host, there will be an Ada compiler that runs on the
FWW host?

Are you sure that there are as many vendors for Ada-to-C "translators" as
there are C vendors?

Are you sure that any translation issues will be fixed immediately by the
Ada vendor at no charge?

Re: Customer balks at Ada -- any hope?

[Scott Ingram`]

Ken,

Methinks that the spillover from the comp.lang.eiffel thread has
soured your milk this month.  To take your points in order:

Ken Garlington wrote:

> Are you sure that buying/maintaining/getting training for an Ada and a C
> compiler is cheaper than just using a C compiler?

o  My perception is that anyone who can write Ada, can write
in any language at the same level.  Its just a matter of having a
book at hand.  That goes for 3 & 4 GLs, naked SQL, Java, and
c++ (though I typically punt and revert to C if I am that desperate.)
I apologize for having specifications and bodies in my C code, but
it works for me.

As a GNATnik (thank you Tucker, for that wonderful term-I had
not heard it before!) I know far more about my compiler than I
would expect the average developer to know.  However, the knowledge
I would expect a developer to know isn't much.  Which switches
are to be used for a particular project is something that I would presume
to be established by edict from a "higher level."

In other words, I don't see any performance or cost penalty in
having an Ada savvy workforce.

> Are you sure that, if there's a C compiler that runs on the FWW (Future
> Wonderful Workstation) host, there will be an Ada compiler that runs on the
> FWW host?

o As far as FWWs go, there is always GNAT.  And anywhere Linux
goes, so will GNAT.  That may not cover ALL platforms, but I currently
use GNAT to do maintenance on an Ada83 16bit platform that is not
supported either by GNAT or GCC.  Its not the future that worries me,
its the past.  A countercase could be made for specialized platforms like
DSPs, the TI chips supported by DDCI being a prime example.  Will
there be economical support for them?  I believe so.  There are too
many GNATniks around.

> Are you sure that there are as many vendors for Ada-to-C "translators" as
> there are C vendors?

o  The quantity of Ada-to-C compilers is a red herring.   AFIK, there is
only one.  If I should begin a project that depends on that product and
Tucker dies (G-d forbid, I use this as an example only) I can still deliver
by taking the generated code base in C and continuing on.  My maintenance
costs will be higher, but if I haven't Ada to fall back on; who cares?

> Are you sure that any translation issues will be fixed immediately by the
> Ada vendor at no charge?

o  Ahhh, now there's a rub.  This goes directly to the heart of tort law,
a subject that is raised here in c.l.a more than any other newsgroup I've
ever seen.  (I don't frequent groups where that would be the subject of
interest.)  Obviously this is a point that must be negotiated, preferably
prior to involvement by either party.  This is outside the realm of Ada
or its viability and indeed is in a domain shared by all software products.
We now move to the "warranty" domain, can you warrant that C will
be around in 25 years?  It seems likely (although I personally detest it
as a dirty little language that shouldn't be allowed to live--I would rather
write assembly.)

Re: Customer balks at Ada -- any hope?

[Larry Kilgallen]

In article <3974EE3D.1F8E016E@silver.jhuapl.edu>, Scott Ingram` <scott@silver.jhuapl.edu> writes:

> We now move to the "warranty" domain, can you warrant that C will
> be around in 25 years?

Ok, if the answer is yes, how about 38 years ?

Re: Customer balks at Ada -- any hope?

[Scott Ingram`]

Larry Kilgallen wrote:

> In article <3974EE3D.1F8E016E@silver.jhuapl.edu>, Scott Ingram` <scott@silver.jhuapl.edu> writes:
>
> > We now move to the "warranty" domain, can you warrant that C will
> > be around in 25 years?
>
> Ok, if the answer is yes, how about 38 years ?

Larry,

I hope you have a reason that 38 would be a significant number?
As I noted in another thread, I have little formal training in anything...and I
am way too lazy to do any math in a motel room.

Re: Customer balks at Ada -- any hope?

[Larry Kilgallen]

In article <39750267.DAB18CC9@silver.jhuapl.edu>, Scott Ingram` <scott@silver.jhuapl.edu> writes:
> 
> 
> Larry Kilgallen wrote:
> 
>> In article <3974EE3D.1F8E016E@silver.jhuapl.edu>, Scott Ingram` <scott@silver.jhuapl.edu> writes:
>>
>> > We now move to the "warranty" domain, can you warrant that C will
>> > be around in 25 years?
>>
>> Ok, if the answer is yes, how about 38 years ?
> 
> Larry,
> 
> I hope you have a reason that 38 would be a significant number?
> As I noted in another thread, I have little formal training in anything...and I
> am way too lazy to do any math in a motel room.

In 2038, I am told, any 32-bit representations of a particular C
time format will start using the most significant bit.  There are
some who suspect that existing implementations may treat this as
a signed number.  There are others who claim that it should be a
signed number.  The existence of the second group substantiates
the fears of the first group.

Re: Customer balks at Ada -- any hope?

[David Starner]

On Tue, 18 Jul 2000 21:20:39 -0400, Scott Ingram` <scott@silver.jhuapl.edu> wrote:
>
>
>Larry Kilgallen wrote:
>
>> Scott Ingram` <scott@silver.jhuapl.edu> writes:
>>
>> > We now move to the "warranty" domain, can you warrant that C will
>> > be around in 25 years?
>>
>> Ok, if the answer is yes, how about 38 years ?
>
>Larry,
>
>I hope you have a reason that 38 would be a significant number?
>As I noted in another thread, I have little formal training in anything...and I
>am way too lazy to do any math in a motel room.

2038 is when the number of seconds since the start of time (Jan 1, 1970) 
overflows a 32 bit counter. Many systems using a time_t that is 32 bits
will fail at that time. Most Unix's are gradually switching to 64 bit systems
and changing time_t to be 64 bits at that time. 

-- 
David Starner - dstarner98@aasaa.ofe.org
http/ftp: x8b4e53cd.dhcp.okstate.edu
It was starting to rain on the night that they cried forever,
It was blinding with snow on the night that they screamed goodbye.
	- Dio, "Rock and Roll Children"

Re: Customer balks at Ada -- any hope?

[Scott Ingram`]

Scott Ingram` wrote:

> o As far as FWWs go, there is always GNAT.  And anywhere Linux
> goes, so will GNAT.  That may not cover ALL platforms, but I currently
> use GNAT to do maintenance on an Ada83 16bit platform that is not
> supported either by GNAT or GCC.  Its not the future that worries me,

The embedded target is not supported by its original Aonix compiler.
And while I am a GNATnik who piddles on Linux...I have no problem
choosing ANY Ada vendor who gives me the support that I need...Now
if only I could convince my boss that Ada is more cost effective than that
C crap she insists that I write, she might go for it!

Re: Customer balks at Ada -- any hope?

[Ken Garlington]

"Scott Ingram`" <scott@silver.jhuapl.edu> wrote in message
news:3974EE3D.1F8E016E@silver.jhuapl.edu...
> Ken,
>
> Methinks that the spillover from the comp.lang.eiffel thread has
> soured your milk this month.

Actually, I know all these questions because I get asked them when I have to
defend choosing Ada over C -- under very much the same conditions as the
original question. Ignore them at your peril!

> To take your points in order:
>
> Ken Garlington wrote:
>
> > Are you sure that buying/maintaining/getting training for an Ada and a C
> > compiler is cheaper than just using a C compiler?
>
> o  My perception is that anyone who can write Ada, can write
> in any language at the same level.  Its just a matter of having a
> book at hand.  That goes for 3 & 4 GLs, naked SQL, Java, and
> c++ (though I typically punt and revert to C if I am that desperate.)
> I apologize for having specifications and bodies in my C code, but
> it works for me.
>
> As a GNATnik (thank you Tucker, for that wonderful term-I had
> not heard it before!) I know far more about my compiler than I
> would expect the average developer to know.  However, the knowledge
> I would expect a developer to know isn't much.  Which switches
> are to be used for a particular project is something that I would presume
> to be established by edict from a "higher level."
>
> In other words, I don't see any performance or cost penalty in
> having an Ada savvy workforce.

However, if you look at the question, it covers a _lot_ more ground that
just programmer productivity. For example, what about the purchase price?
The licensing cost? The support costs? You have to buy the C compiler either
way, so by definition the Ada option is more (unless your Ada-to-C
translator has no costs associated with it at all).

As to an Ada savvy workforce -- are you saying that you will only hire
people if they already know Ada (knowing they can pick up C if necessary)?
What will that do to the potential risk of being unable to staff adequately
(and maintain staff -- there's a lot of demand for programmers right now).

> > Are you sure that, if there's a C compiler that runs on the FWW (Future
> > Wonderful Workstation) host, there will be an Ada compiler that runs on
the
> > FWW host?
>
> o As far as FWWs go, there is always GNAT.  And anywhere Linux
> goes, so will GNAT.

Unfortunately, GNAT does not fit the premise of the question -- an Ada-to-C
"translator".

More to the point, however, anyone who assumes that 10 or 20 years from now,
they'll be using the same OS that they are using today is not supported by
history.

> That may not cover ALL platforms, but I currently
> use GNAT to do maintenance on an Ada83 16bit platform that is not
> supported either by GNAT or GCC.  Its not the future that worries me,
> its the past.

Yeah, I used to not worry about the future... until I got burned a few
times. I wonder what the customer feels about the importance of the future?

> A countercase could be made for specialized platforms like
> DSPs, the TI chips supported by DDCI being a prime example.  Will
> there be economical support for them?  I believe so.  There are too
> many GNATniks around.

Be careful... DDC-I does NOT support all TI DSPs, only certain kinds. For
example, the TI C67 series is not natively supported by any Ada compiler, as
far as I can tell (and I have looked quite actively!). As a somewhat
less-important issue, keep in mind that the DDC-I DSP toolsets inherited
from Tartan are not Ada 95 compilers, and are not available on all
platforms.

>
> > Are you sure that there are as many vendors for Ada-to-C "translators"
as
> > there are C vendors?
>
> o  The quantity of Ada-to-C compilers is a red herring.   AFIK, there is
> only one.  If I should begin a project that depends on that product and
> Tucker dies (G-d forbid, I use this as an example only) I can still
deliver
> by taking the generated code base in C and continuing on.

Continuing on... by training your developers to write C instead of Ada? By
switching your static analysis tools from C to Ada? By switching your
debugging environment from C to Ada? Hope there's no schedule pressure when
you run into your problem with the Ada compiler (and in my experience, this
kind of problem *always* waits until you're under cost and/or schedule
pressure)!

> My maintenance
> costs will be higher, but if I haven't Ada to fall back on; who cares?
>
> > Are you sure that any translation issues will be fixed immediately by
the
> > Ada vendor at no charge?
>
> o  Ahhh, now there's a rub.  This goes directly to the heart of tort law,
> a subject that is raised here in c.l.a more than any other newsgroup I've
> ever seen.  (I don't frequent groups where that would be the subject of
> interest.)  Obviously this is a point that must be negotiated, preferably
> prior to involvement by either party.  This is outside the realm of Ada
> or its viability and indeed is in a domain shared by all software
products.

Be careful about the "if the vendor doesn't do what he promised, we'll sue"
kind of argument. Is this really the best way to address this risk? We've
had cases where a vendor couldn't perform because their revenues were too
low to provide adequate support. Your choice is to (a) give them more money
or (b) sue, and get some of the money that they don't have!

> We now move to the "warranty" domain, can you warrant that C will
> be around in 25 years?  It seems likely (although I personally detest it
> as a dirty little language that shouldn't be allowed to live--I would
rather
> write assembly.)

Certainly, the perception in a lot of areas is that C will outlast Ada. If
you're going to argue otherwise, you'd better have some evidence on your
side to back that up -- not just "well, any language could go obsolete."

Bottom line - if you're trying to convince a customer that Ada is in their
best interest, I wouldn't walk into the meeting with a "that's not a real
concern" attitude. You'd better have real answers to these questions. I've
been there, and seen that!

Re: Customer balks at Ada -- any hope?

[Scott Ingram`]

Ken Garlington wrote:

> "Scott Ingram`" <scott@silver.jhuapl.edu> wrote in message
> news:3974EE3D.1F8E016E@silver.jhuapl.edu...
> > Ken,
> >
> > Methinks that the spillover from the comp.lang.eiffel thread has
> > soured your milk this month.
>
> Actually, I know all these questions because I get asked them when I have to
> defend choosing Ada over C -- under very much the same conditions as the
> original question. Ignore them at your peril!

Ignore them I can't as the only Adaphile in a C shop.  My original intent was
to show that there ARE answers to this line of questioning.  I see these all
the time as you must.  But since we're here :)

> However, if you look at the question, it covers a _lot_ more ground that
> just programmer productivity. For example, what about the purchase price?
> The licensing cost? The support costs? You have to buy the C compiler either
> way, so by definition the Ada option is more (unless your Ada-to-C
> translator has no costs associated with it at all).

I didn't mean to imply that that the question addressed a smaller domain.  But
there ARE
sub domains available in the problem space:  you've identified three that are
applicable
in the preceding paragraph alone.  As a GNATnik, I know it costs no more to
install an
Ada capable compiler than  it does any other GNUCC suite.  While the "purchase"
cost
is not zero as some would have you believe, it can be negligible.  I expect the
cost of other
Ada compilers to drop (because of the competitive influence of GNAT, and the
influence
of comparable Java and C++ products.  It might be that Ada vendors shall always
price
their product above what a 'comparable' product would be...but since there is NO
comparable
product, this doesn't bother me.  I expect market forces to act upon licensing
costs in
the same manner.  Support costs are another fish entirely, as the ACT business
model
demonstrates:  good support is relatively expensive whether its on a per seat
basis or a
per incident basis.  But I already have to bear that cost so the difference is?
While there
don't seem to be any current competitors to ACT in the support only market, I
note that
most Ada compiler vendors list consulting as one of their available services on
their websites.

> As to an Ada savvy workforce -- are you saying that you will only hire
> people if they already know Ada (knowing they can pick up C if necessary)?

Wouldn't that be nice?  Actually, my mathematicians for some screwball
reason have had more exposure to Ada than my programmers and are
more likely to rate it up next to Fortran as a "favorite."  I am not in a
position
to hire, but if I were I would definitely see someone who wasn't frightened
by the "Ada" word as a potential asset.  Someone who's resume consists
only of C and Perl is a maintenance disaster waiting to happen:  I've just spent

a month reviewing and modifying such a person's code and still don't know
for sure what the heck it does.

> What will that do to the potential risk of being unable to staff adequately
> (and maintain staff -- there's a lot of demand for programmers right now).

And as toasters get smarter, I don't expect the demand to diminish although
the supply of programmers may grow.  I was confronted by this very question
at the SIGAda booth at the Govtech 2000 show by some SPAWAR management
types.  Unfortunately I wasn't smart enough to give them my card so I could
put them in touch with Ada friendly educators.  Further, the growing number
GNATniks also includes some youngsters who have demonstrated their skills
in C based open source projects which indicates that it is possible to woo
intelligent people from the dark side.  Robert Dewar in a recent post mentioned
that ACT now has a staff of about 30 (IIRC,) surely those people (whom I
suspect know Ada better than I do) didn't just spring up out of the ground
overnight!  My experience when I have been in a position to hire has been
that it is much easier to find who I want when I go to places where its more
likely to find them...and as far as I can tell, our HR department doesn't go
there.
I suspect that is a problem for all "large" or otherwise bureaucratically
encumbered
employers.

> > > Are you sure that, if there's a C compiler that runs on the FWW (Future
> > > Wonderful Workstation) host, there will be an Ada compiler that runs on
> > > the
> > > FWW host?
> >
> > o As far as FWWs go, there is always GNAT.  And anywhere Linux
> > goes, so will GNAT.
>
> Unfortunately, GNAT does not fit the premise of the question -- an Ada-to-C
> "translator".

I don't think Mike's original concern included the availability of an Ada-to-C
translator.  He was attempting to persuade a reluctant customer that Ada is
a better fit to a particular problem space than the alternatives.  I mentioned
GNAT and (I hope I get the right name) Averstar's Ada to C frontend in this
thread as tools that I would consider to mitigate the risk of delivering an Ada
based product.  And it was your question whether the cost of having to support
both an Ada compiler and a C compiler that led down that path.  Now that I
am almost thinking, I have to point out that there really isn't any
justification for
thinking that I need a C compiler to meet Mike's customer needs.

> More to the point, however, anyone who assumes that 10 or 20 years from now,
> they'll be using the same OS that they are using today is not supported by
> history.

Tell that to my vaxen.  Or my Ada83 embedded system.  Isn't that how Y2K
became a (non)problem?  Since Mike's original problem concerned embedded
systems, and the proliferation of runtimes like eCos, RTEMS, RTLinux and the
like seems likely to broaden the market, I would think that writing code in a
relatively system independent language is a major selling point.

> > That may not cover ALL platforms, but I currently
> > use GNAT to do maintenance on an Ada83 16bit platform that is not
> > supported either by GNAT or GCC.  Its not the future that worries me,
> > its the past.

> Yeah, I used to not worry about the future... until I got burned a few

> times. I wonder what the customer feels about the importance of the future?

To reiterate, my experience has shown that it is the past that bites my
customers
in the ...  And of course anyone who totally ignores the future repeats the
stupidity that led to my problems in the past.  I firmly believe that people who

use Ada as a tool are more likely to consider the future implications of their
work
than those who use other tools.  It could well be that my beliefs are pulled
kicking and
screaming out of a vacuum.  And since we're discussing time travel, wasn't a
major
component of the Ariane 5 failure due to a rosy past with Ariane 4?  One of
my customers recently exposed that his customers are using Quickbooks to do
their accounting, which is good on them since they can change the
past...typically
considered a bad thing by ethical accountants and the IRS.  (My friend is among
the ethical, and from an Ada standpoint most of the shortcomings of Quickbooks
would not happen because of its strong typing.)

> > A countercase could be made for specialized platforms like
> > DSPs, the TI chips supported by DDCI being a prime example.  Will
> > there be economical support for them?  I believe so.  There are too
> > many GNATniks around.
>
> Be careful... DDC-I does NOT support all TI DSPs, only certain kinds. For
> example, the TI C67 series is not natively supported by any Ada compiler, as
> far as I can tell (and I have looked quite actively!). As a somewhat
> less-important issue, keep in mind that the DDC-I DSP toolsets inherited
> from Tartan are not Ada 95 compilers, and are not available on all
> platforms.

I thought that the word "specialized" would be a tip that I was trying to
be careful!  Will Ada be available for everything?  Of course not!

> >
> > > Are you sure that there are as many vendors for Ada-to-C "translators"
> as
> > > there are C vendors?
> >
> > o  The quantity of Ada-to-C compilers is a red herring.   AFIK, there is
> > only one.  If I should begin a project that depends on that product and
> > Tucker dies (G-d forbid, I use this as an example only) I can still
> deliver
> > by taking the generated code base in C and continuing on.
>
> Continuing on... by training your developers to write C instead of Ada? By
> switching your static analysis tools from C to Ada? By switching your
> debugging environment from C to Ada? Hope there's no schedule pressure when
> you run into your problem with the Ada compiler (and in my experience, this
> kind of problem *always* waits until you're under cost and/or schedule
> pressure)!

My developers still haven't recovered from the shock of moving from Fortran
on Vaxen to C on Unix.  Do we meet schedules?  Yes.  Do we run into compiler
bugs?  Yes.  Do we have problems switching just from the Sun debugger to the
Solaris debugger, both for C?  Yes.  So far nothing but business as usual.  So
your
point is?

> > My maintenance
> > costs will be higher, but if I haven't Ada to fall back on; who cares?
> >
> > > Are you sure that any translation issues will be fixed immediately by
> the
> > > Ada vendor at no charge?
> >
> > o  Ahhh, now there's a rub.  This goes directly to the heart of tort law,
> > a subject that is raised here in c.l.a more than any other newsgroup I've
> > ever seen.  (I don't frequent groups where that would be the subject of
> > interest.)  Obviously this is a point that must be negotiated, preferably
> > prior to involvement by either party.  This is outside the realm of Ada
> > or its viability and indeed is in a domain shared by all software
> > products.
>
> Be careful about the "if the vendor doesn't do what he promised, we'll sue"
> kind of argument. Is this really the best way to address this risk? We've
> had cases where a vendor couldn't perform because their revenues were too
> low to provide adequate support. Your choice is to (a) give them more money
> or (b) sue, and get some of the money that they don't have

That is not an argument I would ever make.  You cannot get blood from a stone.
I would suggest that you carefully examine the viability of a vendor before
entanglement.
As my accountant friend explicates, a company that won't open their books to you

is not someone to trust.  This is not an Ada specific problem.  When the Coast
Guard
refurbished its fleet of 378' cutters, the west coast yard chosen was not up to
the task,
and they chose (a ) from above...I still think should have chosen (b) and sent
the remaining
work to another yard.  But it does illustrate that this is just a business
decision that is
not language specific.

> > We now move to the "warranty" domain, can you warrant that C will
> > be around in 25 years?  It seems likely (although I personally detest it
> > as a dirty little language that shouldn't be allowed to live--I would
> rather
> > write assembly.)
>
> Certainly, the perception in a lot of areas is that C will outlast Ada. If
> you're going to argue otherwise, you'd better have some evidence on your
> side to back that up -- not just "well, any language could go obsolete."
>
> Bottom line - if you're trying to convince a customer that Ada is in their
> best interest, I wouldn't walk into the meeting with a "that's not a real
> concern" attitude. You'd better have real answers to these questions. I've
> been there, and seen that!

I agree with your bottom line, but many of the concerns expressed to me
about the viability of  Ada are genuinely a case of the "vapors" rather than
real concerns.  That there are valid arguments to dispell those is not a point
I am willing to concede, even though you make a formidable devil's
advocate.

Re: Customer balks at Ada -- any hope?

[Ken Garlington]

"Scott Ingram`" <scott@silver.jhuapl.edu> wrote in message
news:3975C3E6.DF4956F4@silver.jhuapl.edu...
> But I already have to bear that cost so the difference is?

If you choose to use C, you only have to bear the support costs for the C
compiler.
If you choose to use Ada and C, you have to bear the support costs for the
Ada and C compiler.

I'm still confused as to why you discuss GNAT with respect to this question.
GNAT doesn't convert Ada to C (the original suggestion), so why is it
relevant?

> > > > Are you sure that, if there's a C compiler that runs on the FWW
(Future
> > > > Wonderful Workstation) host, there will be an Ada compiler that runs
on
> > > > the
> > > > FWW host?
> > >
> > > o As far as FWWs go, there is always GNAT.  And anywhere Linux
> > > goes, so will GNAT.
> >
> > Unfortunately, GNAT does not fit the premise of the question -- an
Ada-to-C
> > "translator".
>
> I don't think Mike's original concern included the availability of an
Ada-to-C
> translator.  He was attempting to persuade a reluctant customer that Ada
is
> a better fit to a particular problem space than the alternatives.

Mike said: "We're bidding on a custom industrial controller, and I've
proposed to write the firmware in Ada."

To which Samuel T. Harris added: "Of course the availability of Ada-to-C
translators mitigates the potential for Ada vendor not supporting, or ending
support for, current/future hardware! If there is or will be a C compiler
then there is or will be an Ada compiler."

This was the basis of my most recent discussions.

However, feel free to choose your own path:

(a) I will limit myself to the controllers with native Ada support
(b) I will target (and maintain) GNAT for any controller selected
(c) I will assume that any selected controller has a C compiler, and will
use an Ada-to-C translator

Each has advantages and disadvantages. However, you can't pick the
advantages of all of them simultaneously.

>  I mentioned
> GNAT and (I hope I get the right name) Averstar's Ada to C frontend in
this
> thread as tools that I would consider to mitigate the risk of delivering
an Ada
> based product.

However, you can't apply the GNAT advantages (e.g. price, wide availability)
for Averstar, nor the Averstar advantages (can target C) for GNAT.

> And it was your question whether the cost of having to support
> both an Ada compiler and a C compiler that led down that path.
> Now that I
> am almost thinking, I have to point out that there really isn't any
> justification for
> thinking that I need a C compiler to meet Mike's customer needs.

Except now you have some new risks to go address (see prior posts).

> > More to the point, however, anyone who assumes that 10 or 20 years from
now,
> > they'll be using the same OS that they are using today is not supported
by
> > history.
>
> Tell that to my vaxen.

I can speak volumes about VAXen, being responsible for about a hundred of
them. Have you purchased a new one lately? Are you running GNAT on
VAX/OpenVMS? Has Compaq sent you an Ada (95) compliant version of DEC Ada
yet? As a member of the GNAT team said to me not long ago, "What are you
doing with those boat anchors?"

Why are you switching from FORTRAN on the VAX to C on Unix? Why not just
stay with FORTRAN on the VAX?

> I thought that the word "specialized" would be a tip that I was trying to
> be careful!  Will Ada be available for everything?  Of course not!

Will C be available for most industrial controllers? I suspect so...

> My developers still haven't recovered from the shock of moving from
Fortran
> on Vaxen to C on Unix.  Do we meet schedules?  Yes.  Do we run into
compiler
> bugs?  Yes.  Do we have problems switching just from the Sun debugger to
the
> Solaris debugger, both for C?  Yes.  So far nothing but business as usual.
So
> your
> point is?

My point is, if it's that hard switching from the Sun to the Solaris
debugger, how much harder is it to switch from an Ada environment to a C
environment midway through a project (as a fallback if the Ada-to-C compiler
doesn't work out)?

You seem to be making a very persuasive argument that your environment is
quite volatile, which would seem to imply that choices that minimize the
chance and impact of change are good choices.

> That there are valid arguments to dispell those is not a point
> I am willing to concede, even though you make a formidable devil's
> advocate.

As long as you understand that the original problem is 180 degrees from your
position. No one is trying to convince an Ada advocate to switch to C.
You're trying to convince a C advocate (the customer) that Ada is a better
choice. If you base your argument solely on abstractions, without both (a)
quantitative, applicable evidence of the value of Ada and (b) acknowledging
that there are risks (which you intend to address), they very likely will
assume that you're not qualified to work on their project!

Do you tend to win over your management (and customers) often with your
approach?

Re: Customer balks at Ada -- any hope?

[Samuel T. Harris]

Ken Garlington wrote:
> 
> However, feel free to choose your own path:
> 
> (a) I will limit myself to the controllers with native Ada support
> (b) I will target (and maintain) GNAT for any controller selected
> (c) I will assume that any selected controller has a C compiler, and will
> use an Ada-to-C translator
> 

Actually, the path (as you describe above) to which I was
alluding was to initially go with (a) with the knowledge
that I can always switch to (c) if I absolutely need to.
Switching to (c) should have minimal impact on my existing
Ada code (which is a primary concern in such cases).

My initial response concerning Ada-to-C translators was
in the context of future changes to the architecture
involving components with C but no Ada support!

Knowing I can support Ada where ever C is supported
mitigates that particular risk. Of course, path
(b) can also be kept in mind to mitigate that same
risk but I believe that (c) will nearly always be
much cheaper than (b).

Also, the pun of you letter scheme is not lost on me :)

To expand further on the notion, it is true that
Averstar produces an Ada-to-C translator. Introducing
an "new" C compiler to that mix does involve issues
of who will perform the integration work and who
will warrant the result. Please note that ICC also
produces Ada compilers which produce C. The difference
is that they do all the integration work making
the use of C as an intermediary nearly invisible
to the user organization! Of course that work comes
at some cost which. So all the elements of a make/buy
decision are available is path (c) becomes necessary.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: Customer balks at Ada -- any hope?

[Ken Garlington]

"Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote in message
news:397776F4.EB998A2B@Raytheon.com...
> Ken Garlington wrote:
> >
> > However, feel free to choose your own path:
> >
> > (a) I will limit myself to the controllers with native Ada support
> > (b) I will target (and maintain) GNAT for any controller selected
> > (c) I will assume that any selected controller has a C compiler, and
will
> > use an Ada-to-C translator
> >
>
> Actually, the path (as you describe above) to which I was
> alluding was to initially go with (a) with the knowledge
> that I can always switch to (c) if I absolutely need to.
> Switching to (c) should have minimal impact on my existing
> Ada code (which is a primary concern in such cases).

Then you haven't been reading my responses :)

(Speaking with the experience of someone who has just gone through what you
describe...)

Re: Customer balks at Ada -- any hope?

[mjsilva]

I should have included an email address: mjsilva@jps.net

In article <8l01s4$gnr$1@nnrp1.deja.com>,
  mjsilva@my-deja.com wrote:
> We're bidding on a custom industrial controller, and I've proposed to
> write the firmware in Ada.  The powers-that-be here are satisfied with
> that, but the customer is afraid nobody will be around to maintain it.
> They're happier with C or C++, alas.  Anybody have any good answers to
> their concern?
>
> I realize that implicit in their position is a belief that Ada offers
> no great tangible benefits to the project (even though the machinery
to
> be controlled is big, expensive and remotely-located), which I of
> course strongly disagree with.  As I see it, the arguments are (1) Ada
> will offer tangible benefits, both in reliability and in development
> time, and (2) a decent programmer can pick up similar languages fairly
> easily, especially for maintainence.  (Perhaps I should show them some
> Ada source...).  Ideas?
>
> Mike
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Customer balks at Ada -- any hope?

[Larry Kilgallen]

In article <8l01s4$gnr$1@nnrp1.deja.com>, mjsilva@my-deja.com writes:
> We're bidding on a custom industrial controller, and I've proposed to
> write the firmware in Ada.  The powers-that-be here are satisfied with
> that, but the customer is afraid nobody will be around to maintain it.
> They're happier with C or C++, alas.  Anybody have any good answers to
> their concern?

Just give them a higher bid to do it in C*.

Higher enough that if they give it to you on that basis, you won't
mind not using Ada.

Re: Customer balks at Ada -- any hope?

[Scott Ingram`]

Larry Kilgallen wrote:

> In article <8l01s4$gnr$1@nnrp1.deja.com>, mjsilva@my-deja.com writes:
> > We're bidding on a custom industrial controller, and I've proposed to
> > write the firmware in Ada.  The powers-that-be here are satisfied with
> > that, but the customer is afraid nobody will be around to maintain it.
> > They're happier with C or C++, alas.  Anybody have any good answers to
> > their concern?
>
> Just give them a higher bid to do it in C*.
>
> Higher enough that if they give it to you on that basis, you won't
> mind not using Ada.

To quote the audience of a fortunately defunct game show:
"GOOD ANSWER, GOOD ANSWER!"

Re: Customer balks at Ada -- any hope?

[Larry Kilgallen]

In article <2Nw+bJW42E9n@eisner.decus.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:
> In article <8l01s4$gnr$1@nnrp1.deja.com>, mjsilva@my-deja.com writes:
>> We're bidding on a custom industrial controller, and I've proposed to
>> write the firmware in Ada.  The powers-that-be here are satisfied with
>> that, but the customer is afraid nobody will be around to maintain it.
>> They're happier with C or C++, alas.  Anybody have any good answers to
>> their concern?
> 
> Just give them a higher bid to do it in C*.
> 
> Higher enough that if they give it to you on that basis, you won't
> mind not using Ada.

Or give them a longer warranty period in Ada.

Re: Customer balks at Ada -- any hope?

[Ted Dennison]

In article <8l01s4$gnr$1@nnrp1.deja.com>,
  mjsilva@my-deja.com wrote:
> We're bidding on a custom industrial controller, and I've proposed to
> write the firmware in Ada.  The powers-that-be here are satisfied with
> that, but the customer is afraid nobody will be around to maintain it.
> They're happier with C or C++, alas.  Anybody have any good answers to
> their concern?

This sounds like a job for the Rational paper:

http://www.rational.com/sitewide/support/whitepapers/dynamic.jtmpl?doc_k
ey=337

Things to point out:

   o  They found that for the whole life-cycle, *including* maintenance,
Ada was about twice as cost-effective as C.

   o  This was achieved with a workforce that was *much* more
experienced in C than in Ada.

   o  "In general, developers each do better in Ada than in C,
regardless of their level of experience and salary."

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Customer balks at Ada -- any hope?

[mjsilva]

In article <8l1np1$mv7$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> In article <8l01s4$gnr$1@nnrp1.deja.com>,
>   mjsilva@my-deja.com wrote:
> > We're bidding on a custom industrial controller, and I've proposed
to
> > write the firmware in Ada.  The powers-that-be here are satisfied
with
> > that, but the customer is afraid nobody will be around to maintain
it.
> > They're happier with C or C++, alas.  Anybody have any good answers
to
> > their concern?
>
> This sounds like a job for the Rational paper:
>
> http://www.rational.com/sitewide/support/whitepapers/dynamic.jtmpl?
doc_k
> ey=337
>
> Things to point out:
>
>    o  They found that for the whole life-cycle, *including*
maintenance,
> Ada was about twice as cost-effective as C.
>
>    o  This was achieved with a workforce that was *much* more
> experienced in C than in Ada.
>
>    o  "In general, developers each do better in Ada than in C,
> regardless of their level of experience and salary."

Yep, I'll certainly include this paper, and thanks for the bullet
points.

Mike


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Customer balks at Ada -- any hope?

[Tucker Taft]

mjsilva@my-deja.com wrote:
> 
> We're bidding on a custom industrial controller, and I've proposed to
> write the firmware in Ada.  The powers-that-be here are satisfied with
> that, but the customer is afraid nobody will be around to maintain it.
> They're happier with C or C++, alas.  Anybody have any good answers to
> their concern?

With the appearance of Java and C#, I would guess finding good
programmers with C++ experience may be harder in the future (and it is 
hard enough  already).  Interestingly, Ada usage remains relatively 
steady while other languages seem to go up and down the hype roller coaster.

Note that Ada is specifically designed for projects that have
a very long life time (25 years +) such as aviation, shipping,
transportation systems, International Space Station, etc.  
So you can be certain Ada will be around in some form in 25 years, 
for what that's worth.  And given the growing number of GNATniks, 
there will probably be a continuing active Ada community, and not
just a bare-bones Jovial-ish life-support office.

Another important point is that good programmers can learn new languages
quickly, and Ada compilers provide excellent "training wheels" because
of their abundant compile-time error checking.

> I realize that implicit in their position is a belief that Ada offers
> no great tangible benefits to the project (even though the machinery to
> be controlled is big, expensive and remotely-located), which I of
> course strongly disagree with.  As I see it, the arguments are (1) Ada
> will offer tangible benefits, both in reliability and in development
> time, and (2) a decent programmer can pick up similar languages fairly
> easily, especially for maintainence.  (Perhaps I should show them some
> Ada source...).  Ideas?
> 
> Mike
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

Re: Customer balks at Ada -- any hope?

[Stanley R. Allen]

Tucker Taft wrote:
> 
> Another important point is that good programmers can learn new languages
> quickly, and Ada compilers provide excellent "training wheels" because
> of their abundant compile-time error checking.
> 

This is a positive factor in some project manager's minds concerning
the long-term maintenance issues.  The typical project has high
skills (analysts and contract-rate programmers) at the front end
and lower skills (college grads) at the back end.  Because the
language catches so many problems up front, the less skilled
developers/maintainers are able to be more productive and
introduce fewer problems during maintenance.

-- 
Stanley Allen
mailto:Stanley_R_Allen-NR@raytheon.com

Re: Customer balks at Ada -- any hope?

[Rennie Allen]

"Stanley R. Allen" wrote:
> 
> Tucker Taft wrote:
> >
> > Another important point is that good programmers can learn new languages
> > quickly, and Ada compilers provide excellent "training wheels" because
> > of their abundant compile-time error checking.
> >
> 
> This is a positive factor in some project manager's minds concerning
> the long-term maintenance issues.  The typical project has high
> skills (analysts and contract-rate programmers) at the front end
> and lower skills (college grads) at the back end.  Because the
> language catches so many problems up front, the less skilled
> developers/maintainers are able to be more productive and
> introduce fewer problems during maintenance.

Dude !  Where do you find these managers (i.e. the ones with minds :).  They
must have skipped the (usually required) lobotomy phase of management school.

I have never encountered a "manager" that was either bright enough to realize a
long term benefit, or ethical enough to implement something that makes their
budgeting look bad (high upfront costs), and someone else's look good (lower
long-term costs - once the original manager has "moved up" - as management types
like to do).  Many management types I have encountered, derive extreme
satisfaction from pointing out the maintenance cost over-runs associated with
projects that they initiated, but some recently
lobotomized^H^H^H^H^H^H^H^H^H^H^H recruited lower management type is now
responsible for.

Of course, I have worked for some great individuals, but the good ones, have
generally been reticent to refer to themselves as managers...

-- 
To succeed in this world it is not enough to be stupid; you must also be
well-mannered. - Voltaire

Re: Customer balks at Ada -- any hope?

[Stanley R. Allen]

Rennie Allen wrote:
> 
> "Stanley R. Allen" wrote:
> >
> > This is a positive factor in some project manager's minds concerning
> > the long-term maintenance issues.  
> 
> Dude !  Where do you find these managers (i.e. the ones with minds :).  They
> must have skipped the (usually required) lobotomy phase of management school.
> 
> I have never encountered a "manager" that was either bright enough to realize a
> long term benefit, or ethical enough to implement something that makes their
> budgeting look bad (high upfront costs), and someone else's look good (lower
> long-term costs - once the original manager has "moved up" - as management types
> like to do).  Many management types I have encountered, derive extreme
> satisfaction from pointing out the maintenance cost over-runs associated with
> projects that they initiated, but some recently
> lobotomized^H^H^H^H^H^H^H^H^H^H^H recruited lower management type is now
> responsible for.
> 

Ok, Ok, I said *some* project managers.  Specifically, I'm thinking
of some in my plant who perhaps are more software-savvy than many.
I've had some bean-counters turned 'managers' around here who
don't know Java from Japan, but at least a couple (surprise,
surprise) used to be programmers.  The head of my department used
to teach Ada at the local university.  Another supervisor was a
member of the Posix/Ada mapping review group.  Another likes to
get his hands dirty with GNAT/Linux in his spare time.  

Heck, one day even *you* might become a manager, like some
other people that read this group regularly.

-- 
Stanley Allen
mailto:Stanley_R_Allen-NR@raytheon.com

Re: Customer balks at Ada -- any hope?

[Joseph C Williams]

"Stanley R. Allen" wrote:
> 
> but at least a couple (surprise,
> surprise) used to be programmers.  The head of my department used
> to teach Ada at the local university.  Another supervisor was a
> member of the Posix/Ada mapping review group.  Another likes to
> get his hands dirty with GNAT/Linux in his spare time.
> 
> Heck, one day even *you* might become a manager, like some
> other people that read this group regularly.

  To give Stanley credit (and I do that a lot), he is right.
Ada is intended to be used on 'reasonably' sized projects...
stuff that is not done in a week or two....stuff that can take
years to finally deploy.  This long lead time is not due to
Ada, but to the nature of the problems being solved (heck, the
NEXT space station we build will not be like this...).
  This means that some of today's floor engineers may someday be
tomorrow's team/group/IPT leads, maybe even work up to
upper management someday.  All while still working on the exact
same project or something very similar.  You (hopefully)
end up with a lot of corporate knowledge walking around in
the leadership ranks.  Your 1991 new-grad screwup may be your
2001 department manager.
  Agreeably, some of them still are mentally fighting the battles
of yesteryear.  But surprisingly, the same problems still are
applicable today:  CM issues, multiple baselines, memory
constraints, timing constraints, race conditions, plain bad
code, short schedules, employee burnout, customer expectations,
etc. etc. etc.
  Of course, everyone has employee turnover and such.  But with
a 'good' Ada project, I think your leadership ranks' average 
technical skill base will tend to increase over time.
They will have a certain sense of ownership in the project and
a personal knowledge of its history, both successes and failures.
  You probably would not see this on a short-term C/C++ project.
-- 
----------------------------------------------
Joe Williams 
Aerospace Engineering Services, RAYTHEON TECHNICAL SERVICES COMPANY
Joseph_C_Williams@Raytheon.com

Re: Customer balks at Ada -- any hope?

[Ted Dennison]

In article <39772BA6.F72AC7FB@raytheon.com>,
  joseph_c_williams@raytheon.com wrote:
>   Of course, everyone has employee turnover and such.  But with
> a 'good' Ada project, I think your leadership ranks' average
> technical skill base will tend to increase over time.

That is assuming your company doesn't adhere to the "Dilbert Principle"
(Roughly: incompetents are promoted to management in order to prevent
them from doing any further technical damage. Conversly, very good
engineers are far too valuable to promote)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Customer balks at Ada -- any hope?

[mjsilva]

In article <39748F35.72CBC45A@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> mjsilva@my-deja.com wrote:
> >
> > We're bidding on a custom industrial controller, and I've proposed
to
> > write the firmware in Ada.  The powers-that-be here are satisfied
with
> > that, but the customer is afraid nobody will be around to maintain
it.
> > They're happier with C or C++, alas.  Anybody have any good answers
to
> > their concern?
>
> With the appearance of Java and C#, I would guess finding good
> programmers with C++ experience may be harder in the future

That's a good point -- C++ seems to be the language that everybody
wants to fix...
>
> Another important point is that good programmers can learn new
languages
> quickly, and Ada compilers provide excellent "training wheels" because
> of their abundant compile-time error checking.

I definitely want to select some clear Ada source code to back this
point.  I also suspect that when one selects only embedded-savvy
programmers the balance isn't nearly so lopsided for C++.  It's pretty
obvious to me that it's easier to teach an embedded-savvy programmer
Ada (especially "maintainence" Ada) than to teach a "generic" C++
programmer embedded smarts.

Mike


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Customer balks at Ada -- any hope?

[Scott Ingram`]

mjsilva@my-deja.com wrote:

> In article <39748F35.72CBC45A@averstar.com>,
>   Tucker Taft <stt@averstar.com> wrote:
> >
> > Another important point is that good programmers can learn new
> >languages
> > quickly, and Ada compilers provide excellent "training wheels" because
> > of their abundant compile-time error checking.
>
> I definitely want to select some clear Ada source code to back this
> point.  I also suspect that when one selects only embedded-savvy
> programmers the balance isn't nearly so lopsided for C++.  It's pretty
> obvious to me that it's easier to teach an embedded-savvy programmer
> Ada (especially "maintainence" Ada) than to teach a "generic" C++
> programmer embedded smarts.
>
> Mike

Hmmm....I have no formal training in programming.  (Come to think
of it, I have very little formal training in anything!)  But I must point
out
from my perspective as an electronic technician that maintaining an
embedded system in Ada (which is one of my jobs) is much easier than
maintaining a system of equal complexity in C (also one of my jobs.)
Once your management types twig to the fact that they don't need the
equivalent of Leonardo da'Vinci to maintain code, they may be more
convincing to your customer.

An added benefit in my case is that my Ada experience made it
simple for me to learn to write test benches in VHDL, again freeing
resources that get paid more than I do for the equivalent work.

Re: Customer balks at Ada -- any hope?

[nabbasi]

In article <3974D54B.3D2449FD@silver.jhuapl.edu>, Scott says...
 
>from my perspective as an electronic technician that maintaining an
>embedded system in Ada (which is one of my jobs) is much easier than
>maintaining a system of equal complexity in C (also one of my jobs.)

I think maintaining a large program in Ada is much easier than in any
other language. Ada was designed from the ground up with constructs
to support this. Real Packages, the Ada central library concept, 
separate compilation, the fact that it is impossible to build an 
inconsistant program in Ada (whose parts are out of date with other parts), 
strong typing, etc.. 

I download Ada code written more than 10 years ago, and it will just compile
with no errors or warnings. Try that with C or C++ or Java. 
 
The more I work in the software industry, the more I am amazed on how
much time is wasted by not using the better tool for the job. 
 
As others said, any programmer worth half his salary should be able to 
learn Ada in few days, and become good enough at it in few short weeks.

As far as Ada going away, this is IMPOSSIBLE. Gnat source code is
out, and unless all the hard drives in the world that have a copy
of the gnat source code suddenlly all break down at the same time,
it is a physical impossiblity for Ada to go away, such as it is a
physical imossibility for gcc and all the gnu tools to go away. If you
have the source code, it will always be here.  Having the source
code is the most security you can evern have.

Can you say the same about your VC++ code? What if MS tommorrow decided
to stop VC++, how will you compile your VC++ programs on tommrrow's
machines that have no VC++ compiler on them?  You do not have the source
code for VC++, so you are stuck.  This will never happen with Ada/Gnat.
MS is now killing J++, now what will happen to all that J++ code? 

Nasser
 

Re: Customer balks at Ada -- any hope?

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]


nabbasi@pacbell.net.NOSPAM a �crit dans le message
<8l2q5o$1o9e@drn.newsguy.com>...
>In article <3974D54B.3D2449FD@silver.jhuapl.edu>, Scott says...
>
>>from my perspective as an electronic technician that maintaining an
>>embedded system in Ada (which is one of my jobs) is much easier than
>>maintaining a system of equal complexity in C (also one of my jobs.)
>
>I think maintaining a large program in Ada is much easier than in any
>other language.

I second that.

>I download Ada code written more than 10 years ago, and it will just
compile
>with no errors or warnings. Try that with C or C++ or Java.

Same experience, I have some nice package created in 1986 that are just
working fine. I've never fixed the code since then. I have not a single C
source
of this kind.

>The more I work in the software industry, the more I am amazed on how
>much time is wasted by not using the better tool for the job.


I second that.

>As others said, any programmer worth half his salary should be able to
>learn Ada in few days, and become good enough at it in few short weeks.


Definitly. Everybody seems to worry about training... except when it is for
the hype languages. It stange that there is only problems when we talk about
Ada. The is just no problem for C++, Java and wait for C# ! Does somebody
will say well C# is good but we'll have to train our programers ? I don't
think so... And again we will restart from scratch, C# is good but we could
had
that, and every single good component will be trashed and rewritted in C#
(with many bugs added), programmers will be less efficient in C# because
it is new, programmers doing C# will be more expensive for some time...
well until the next very-good-killer-to-of-the-art language :) Whose turn
after
SUN and Microsoft ?

Pascal.

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Customer balks at Ada -- any hope?

[Florian Weimer]

"Pascal Obry" <p.obry@wanadoo.fr> writes:

> Definitly. Everybody seems to worry about training... except when it is for
> the hype languages. It stange that there is only problems when we talk about
> Ada. The is just no problem for C++, Java and wait for C# ! Does somebody
> will say well C# is good but we'll have to train our programers ? I don't
> think so...

Very soon there will be jobs ads requiring "five years of experience
in C# programming". ;-)

Re: Customer balks at Ada -- any hope?

[Robert I. Eachus]

Florian Weimer wrote:

> Very soon there will be jobs ads requiring "five years of experience
> in C# programming". ;-)

  Not five years, ten years.  At the ARG meeting held in Germany a few
years ago (May or June of 1988 I think) there was a discussion of a
wonderfully silly ad asking for ten years of Ada programming
experience.  We went around the table and concluded that only one person
really qualified--Jean Ichbiah.  Of course, Jean felt that he didn't
qualify because he hadn't spent all that time programming.

Re: Customer balks at Ada -- any hope?

[Philip Anderson]

"Robert I. Eachus" wrote:
> 
> Florian Weimer wrote:
> 
> > Very soon there will be jobs ads requiring "five years of experience
> > in C# programming". ;-)
> 
>   Not five years, ten years.  At the ARG meeting held in Germany a few
> years ago (May or June of 1988 I think) there was a discussion of a
> wonderfully silly ad asking for ten years of Ada programming
> experience.  We went around the table and concluded that only one person
> really qualified--Jean Ichbiah.  Of course, Jean felt that he didn't
> qualify because he hadn't spent all that time programming.

And I wonder how many people applied claiming that experience :-)


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: Customer balks at Ada -- any hope?

[Ken Garlington]

"Philip Anderson" <phil.anderson@amsjv.com> wrote in message
news:398149AA.F0A7DB3@amsjv.com...
> "Robert I. Eachus" wrote:
> >
> > Florian Weimer wrote:
> >
> > > Very soon there will be jobs ads requiring "five years of experience
> > > in C# programming". ;-)
> >
> >   Not five years, ten years.  At the ARG meeting held in Germany a few
> > years ago (May or June of 1988 I think) there was a discussion of a
> > wonderfully silly ad asking for ten years of Ada programming
> > experience.  We went around the table and concluded that only one person
> > really qualified--Jean Ichbiah.  Of course, Jean felt that he didn't
> > qualify because he hadn't spent all that time programming.
>
> And I wonder how many people applied claiming that experience :-)

Of course, if you were working with the average Ada compiler in the early
'80s, it didn't take long for you to *feel* like it was 10 years :)

Re: Customer balks at Ada -- any hope?

[Harry Erwin]

Robert I. Eachus <rieachus@earthlink.net> wrote:

> Florian Weimer wrote:
> 
> > Very soon there will be jobs ads requiring "five years of experience
> > in C# programming". ;-)
> 
>   Not five years, ten years.  At the ARG meeting held in Germany a few
> years ago (May or June of 1988 I think) there was a discussion of a
> wonderfully silly ad asking for ten years of Ada programming
> experience.  We went around the table and concluded that only one person
> really qualified--Jean Ichbiah.  Of course, Jean felt that he didn't
> qualify because he hadn't spent all that time programming.

It's not unusual for a HR department to have a search image consisting
of a 25-year-old PhD with 10 years of experience and willing to work for
$30,000 a year.

-- 
Harry Erwin, PhD, <mailto:herwin@gmu.edu>,Computational Neuroscientist 
(modeling bat behavior), Senior SW Analyst and Security Engineer, and 
Adjunct Professor of Computer Science, GMU. Looking--CV available at: 
<http://mason.gmu.edu/~herwin/CV.htm>

Re: Customer balks at Ada -- any hope?

[Ted Dennison]

In article <1eemlm5.1h19b38vw85osN%herwin@gmu.edu>,
  herwin@gmu.edu (Harry Erwin) wrote:
> It's not unusual for a HR department to have a search image consisting
> of a 25-year-old PhD with 10 years of experience and willing to work
> for $30,000 a year.

Of course my "search image" for companies to hire me often isn't much
more realistic. :-)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Customer balks at Ada -- any hope?

[Rennie Allen]

nabbasi@pacbell.net.NOSPAM wrote:

> The more I work in the software industry, the more I am amazed on how
> much time is wasted by not using the better tool for the job.

Tell me about it.
 
> As others said, any programmer worth half his salary should be able to
> learn Ada in few days, and become good enough at it in few short weeks.

Here I think you are exaggerating a bit (well it depends on what you consider
"good enough").  I really don't think that many programmers can be reasonably
expected to employ all the features of Ada that make it valuable, after only a
"few short weeks".  I think that reasonable competency (which I define as a Ada
expert not having to hand hold the trainee through a complete design to
implementation phase) can be achieved in around 6 months.  The point is if you
are doing a large software project, one can reasonably expect that 6
months/developer is equivalent to the time one will spend fixing bugs that would
not have made it into the runtime using Ada.  The real question is what is your
endpoint.  If you are prepared to ship buggy products (as many companies seem
prepared to do) then the 6 months doesn't pay off (since you reach your endpoint
- shipping buggy code - effectively without resorting to Ada).

-- 
To succeed in this world it is not enough to be stupid; you must also be
well-mannered. - Voltaire

Re: Customer balks at Ada -- any hope?

[nabbasi]

In article <3975C461.13EA3E92@computermotion.com>, Rennie says...

>
>nabbasi@pacbell.net.NOSPAM wrote:
>
 
>> As others said, any programmer worth half his salary should be able to
>> learn Ada in few days, and become good enough at it in few short weeks.

>
>Here I think you are exaggerating a bit (well it depends on what you consider
>"good enough").  I really don't think that many programmers can be reasonably
>expected to employ all the features of Ada that make it valuable, after only a
>"few short weeks". 

Not all the Ada features, but the most common ones. 

I was thinking of a programmer who allready been programming for 2-3 years
at least. Such a programmer can definitly become productive in Ada in
less than one month. of course to become as good as Tucker or Robert Dewar or
others like them on this news group will take years, but I am taking 
about the ability to use the common features of Ada to start writing 
usefull code.

I think if one loves to program, they wil learn programming in any
new languge fast. 

> I think that reasonable competency (which I define as a Ada
>expert not having to hand hold the trainee through a complete design to
>implementation phase) can be achieved in around 6 months. 

OK, we agree. 6 months is 'few short months' :)

reagrds,
Nasser
 

Re: Customer balks at Ada -- any hope?

[Scott Ingram`]

Scott Ingram` wrote:

> An added benefit in my case is that my Ada experience made it
> simple for me to learn to write test benches in VHDL, again freeing
> resources that get paid more than I do for the equivalent work.

Oops...that didn't come out right.  What I meant was, there is no
reason to waste resources that could be doing "real work" like
development while maintenance assets like me can "sweat the small
stuff."  It might be better from a quality standpoint that a hardware
guy like me writes test benches since I have no preconceived expectations
about what the software does.  Either way, it gives me a chance to alternate
between my 8' swing lathe and pounding a keyboard, so I get the best
of many worlds!  And I get paid for this job! which just astounds me...

Re: Customer balks at Ada -- any hope?

[wv12]

In article <8l01s4$gnr$1@nnrp1.deja.com>,
  mjsilva@my-deja.com wrote:
> We're bidding on a custom industrial controller, and I've proposed to
> write the firmware in Ada.  The powers-that-be here are satisfied with
> that, but the customer is afraid nobody will be around to maintain it.
> They're happier with C or C++, alas.  Anybody have any good answers to
> their concern?

>
> I realize that implicit in their position is a belief that Ada offers
> no great tangible benefits to the project (even though the machinery
to
> be controlled is big, expensive and remotely-located),

C has been known to control big, expensive hardware. One such
example is the mutinode Deep Blue capable of searching a few million
nodes per second. Is the speed critical in this project? If so, I see
on reason to avoid Ada that checks every shift, rotate, add, multiply
in your software.

> course strongly disagree with.  As I see it, the arguments are (1) Ada
> will offer tangible benefits, both in reliability and in development
> time, and (2) a decent programmer can pick up similar languages fairly
> easily, especially for maintainence.  (Perhaps I should show them some
> Ada source...).  Ideas?
Maybe you could try to sell the safety critical side of Ada. But
software that does not get tested will crash, kill, dump core, etc...
(Ariane comes to mind)
>
> Mike
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
You are not convincing me. Besides, the customer is always right.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Customer balks at Ada -- any hope?

[Larry Kilgallen]

In article <8l2pqo$im7$1@nnrp1.deja.com>, wv12@my-deja.com writes:

> In article <8l01s4$gnr$1@nnrp1.deja.com>,
>   mjsilva@my-deja.com wrote:

>> I realize that implicit in their position is a belief that Ada offers
>> no great tangible benefits to the project (even though the machinery
> to
>> be controlled is big, expensive and remotely-located),
> 
> C has been known to control big, expensive hardware. One such
> example is the mutinode Deep Blue capable of searching a few million
> nodes per second. Is the speed critical in this project? If so, I see
> on reason to avoid Ada that checks every shift, rotate, add, multiply
> in your software.

I gather your argument is to use the controls on the Ada compiler
to disable checking in the production version.  My understanding
is that many embedded developers do that, but I think we should
leave that decision up to the technical staff on a module-by-module
basis, rather than restricting them from ever using checking by
choosing a language that does not provide it.

Re: Customer balks at Ada -- any hope?

[Kieran Mckey]

Larry Kilgallen wrote:

> I gather your argument is to use the controls on the Ada compiler
> to disable checking in the production version.  My understanding
> is that many embedded developers do that, but I think we should
> leave that decision up to the technical staff on a module-by-module
> basis, rather than restricting them from ever using checking by
> choosing a language that does not provide it.

It is true that often embedded developers do turn off run-time checks in
production code. I think this is an unwise practice. It can mean that
whether or not your code meets performance requirements is dependent on
compiler switches. You should design the system so that the code will
meet performance requirements regardless of whether run-time checks are
enabled or not. Furthermore, run-time checks are required for exception
handling which can provide valuable diagnostic data. IMO too many
developers regard the production version as the final version of the
code and expect it to be bug free, disabling run-time checks means that
finding the 'in service' bugs much more difficult. The code should be
viewed as a evolving product throughout its expected life.

Kieran Mckey

Re: Customer balks at Ada -- any hope?

[fdebruin]

Kieran Mckey <kieran.mckey@baesystems.com> writes:

>compiler switches. You should design the system so that the code will
>meet performance requirements regardless of whether run-time checks are
>enabled or not. 
>
Sometimes, you don't have that luxury.

For example, on-board systems for spacecrafts usually have very limited
resources available and you're faced with restricitions w.r.t. the
selection of processor and memory size avaible. 

In larger space projects, in order to fix power consumption and heat
dissipation budgets, these aspects are fixed very early the hardware
design phase. You should consider yourself lucky if you can have a
complete/adequate software specification in that phase. It is rare,
if it happens at all, to have the software design ready before the
hardware is frozen.

I know that in theory one should design the hardware with sufficient
margins etc. etc. But the day-to-day practice is different and more
difficult than that.


Frank de Bruin

Re: Customer balks at Ada -- any hope?

[Ken Garlington]

"fdebruin" <fdebruin@xs4.xs4all.nl> wrote in message
news:8l40kb$7na$1@xs4.xs4all.nl...
> Kieran Mckey <kieran.mckey@baesystems.com> writes:
>
> >compiler switches. You should design the system so that the code will
> >meet performance requirements regardless of whether run-time checks are
> >enabled or not.
> >
> Sometimes, you don't have that luxury.
>
> For example, on-board systems for spacecrafts usually have very limited
> resources available and you're faced with restricitions w.r.t. the
> selection of processor and memory size avaible.

Don't forget another aspect of run-time checks that is particularly
important to embedded systems: Run-time checks are completely worthless...
unless you have a proper course of action to take when they occur.

For example, consider the Ariane 5 case. Let's assume that run-time checking
was completely enabled, and a Constraint_Error was therefore raised on the
floating-point to integer conversion (instead of the machine interrupt).
Unless there had been a local exception handler to take an appropriate
action (and it's somewhat of an open question as to the right action,
although saturating the output would have been the obvious choice), then the
exception would have propagated to the gloabl exception handler -- and the
exact same outcome would have occurred. Adding these local exception
handlers, of course, will use up some resources (memory, programmer time,
etc.) so they're certainly not "free".

Re: Customer balks at Ada -- any hope?

[Kieran Mckey]

Ken Garlington wrote:
> 
> "fdebruin" <fdebruin@xs4.xs4all.nl> wrote in message
> news:8l40kb$7na$1@xs4.xs4all.nl...
> > Kieran Mckey <kieran.mckey@baesystems.com> writes:
> >
> > >compiler switches. You should design the system so that the code will
> > >meet performance requirements regardless of whether run-time checks are
> > >enabled or not.
> > >
> > Sometimes, you don't have that luxury.
> >

That is very true Frank, I've been on projects where RTC was turned off
to meet performance targets. All I am saying is that IMHO this is poor
engineering practice and the issue should be considered during initial
system design. 

> 
> Don't forget another aspect of run-time checks that is particularly
> important to embedded systems: Run-time checks are completely worthless...
> unless you have a proper course of action to take when they occur.
> 

That is right. A proper course of action may be just logging the event
in a non-volatile store (admittedly not much use when this blows up !)
or you could attempt some error recovery. Personally, I think Ada could
be better in the area of exception handling, it still being a rather
crude Goto at the moment, is there no way of informing the caller that
an exception has occurred in the sub-program except to re-raise the
exception ?

Kieran Mckey

Re: Customer balks at Ada -- any hope?--Warning Significant Thread Drift Ahead

[Jeff Creem]

I almost hate to respond in such a heated thread since I am sure it will
get lost in the shuffle but.
"Kieran Mckey" <kieran.mckey@baesystems.com> wrote in message

> enabled or not. Furthermore, run-time checks are required for exception
> handling which can provide valuable diagnostic data. IMO too many

Apart from everything else you said, the above statement is not exactly
correct. You can suppress checks and still get exception handling for
explicitly raised exceptions as well as those exceptions which are "free".
Granted the meaning of the latter is compiler and target specific but there
is
a big difference between suppressing automatic run time checks and loosing
exception handling all together...

Jeff

Re: Customer balks at Ada -- any hope?--Warning Significant Thread Drift Ahead

[Kieran Mckey]

Jeff Creem wrote:
> 
> "Kieran Mckey" <kieran.mckey@baesystems.com> wrote in message
> 
> > enabled or not. Furthermore, run-time checks are required for exception
> > handling which can provide valuable diagnostic data. IMO too many
> 
> Apart from everything else you said, the above statement is not exactly
> correct. You can suppress checks and still get exception handling for
> explicitly raised exceptions

Agreed.

> as well as those exceptions which are "free".

By "free" I assume you mean processor exceptions, e.g. divide by zero,
which are not the same as Ada exceptions.

> Granted the meaning of the latter is compiler and target specific but there
> is a big difference between suppressing automatic run time checks and loosing
> exception handling all together...

Ok, a quick reword gives : 

run-time checks are required for Ada exception handling, excluding
explicitly raised exceptions.

Kieran Mckey

Re: Customer balks at Ada -- any hope?--Warning Significant Thread Drift Ahead

[Robert I. Eachus]

Kieran Mckey wrote:
  
> Ok, a quick reword gives :
> 
> run-time checks are required for Ada exception handling, excluding
> explicitly raised exceptions.

  Not right yet.  You really have to read and understand RM 11.6,
Exceptions and Optimization,
to have some clue as to what is required.  (And probably read Ada 83
AI-315 or have Brother Dewar or Brother Hilfinger preach on reasoning
from erroneousness.)  But the reality can best be summed
up in three principles:

   Ada checks are really on stored VALUES (or on subtype conversions)
not on operations.

   Ada compilers can and do STATICALLY eliminate most required checks.

   If your program runs efficiently with checks enabled, it will
probably run slower if you
disable them.  (Translation, only turn off checks where you know the
compiler is generating
"junk" checking code for some particular computation.   And it is often
much better to "turn checking off" by doing a complex computation in
type'Base, then converting the result.)

   And yes, I have seen code run slower when compiled with checks
disabled.  (Note that earlier version of GNAT did have significant
overhead for integer constraint checks, so by default they
were turned off.  They are still disabled by default for compatibility
reasons, but the code generated now is much more efficient than before.)

    Of course, in any discussion of supressing checks it is assumed that
the exception cannot or will not occur.  If a check for a particular
exception is suppressed and an exception occurs that results in
externally visible effects, then program speed is irrelevant.  I have
used the
compiler to validate my understanding of a section of code by compiling
with checks on and then
checking the generated code to see if it contains a call to raise an
exception.  (This only works if the hardware sets condition codes which
have to be checked.  If the hardware traps on overflow, or if there are
calls to run-time routines which actually do the test, the method
doesn't work.)
But on most modern hardware, look at the generated code.  Then make
minor changes to see how the checking code is affected.  Often moving a
bound from a parameter to a variable or vice-versa, or even putting it
in both places, will have a significant effect on compiler overhead.

Re: Customer balks at Ada -- any hope?

[Scott Ingram`]

wv12@my-deja.com put out some flame bait to which I responded:

> C has been known to control big, expensive hardware. One such

C has controlled big, expensive hardware...and people died.

> example is the mutinode Deep Blue capable of searching a few million
> nodes per second. Is the speed critical in this project? If so, I see
> on [sic]  reason to avoid Ada that checks every shift, rotate, add,
> multiply
> in your software.

Okay, I am feeling particularly pugnacious this evening after a day of
determining things like "are you big-endian?"  wv12, what possible
justification
do you have for implying that speed suffers when Ada is used?  I see nothing

in the ARM or the implementation supplied docco that implies processor
operations are checked at each iteration.  Further, I am rewriting speed
sensitive ATM code in Ada because nobody knows what the current (C
written in a Perl style) code does.

> > course strongly disagree with.  As I see it, the arguments are (1) Ada
> > will offer tangible benefits, both in reliability and in develophatment
> > time, and (2) a decent programmer can pick up similar languages fairly
> > easily, especially for maintainence.  (Perhaps I should show them some
> > Ada source...).  Ideas?

> Maybe you could try to sell the safety critical side of Ada. But
> software that does not get tested will crash, kill, dump core, etc...
> (Ariane comes to mind)

My proggies only core dump when they import buggy C code,
and most of the time I can recover from that if I am feeling defensive.
As for crashes, not in my lifetime--that is totally unacceptable.  As a
tech, my code has to be better than my programmers, otherwise they
won't believe me when I tell 'em the hardware is okay.

> You are not convincing me. Besides, the customer is always right.

Why the heck you threw this flamebait out is beyond me.  I doubt that
you wanted to be convinced.  And since I have years of experience
in customer service, I must note that you're correct; the customer is always

right.  It just sometimes takes a while to persuade them to do what is
in their own best interest.  (NB Mike Silva's thread regarding customers.)

And what kind of name is wv12 anyway?

Re: Customer balks at Ada -- any hope?

[Dale Pontius]

In article <3974F7A1.E806B092@silver.jhuapl.edu>,
	Scott Ingram` <scott@silver.jhuapl.edu> writes:
> wv12@my-deja.com put out some flame bait to which I responded:
>
>> C has been known to control big, expensive hardware. One such
>
> C has controlled big, expensive hardware...and people died.
>
Point of curiousity - can you expand on this? Tales of death
due to software error are surprisingly uncommon, given what we
seem to consider the poor general state of software development.


Dale Pontius
NOT speaking for IBM

Re: Customer balks at Ada -- any hope?

[Scott Ingram]

Dale Pontius wrote:
> 
> In article <3974F7A1.E806B092@silver.jhuapl.edu>,
>         Scott Ingram` <scott@silver.jhuapl.edu> writes:
> > wv12@my-deja.com put out some flame bait to which I responded:
> >
> >> C has been known to control big, expensive hardware. One such
> >
> > C has controlled big, expensive hardware...and people died.
> >
> Point of curiousity - can you expand on this? Tales of death
> due to software error are surprisingly uncommon, given what we
> seem to consider the poor general state of software development.
> 
> Dale Pontius
> NOT speaking for IBM

The device I was thinking of was a medical radiation generator for
the treatment of cancer.  However, a reference that Ken Garlington
gave earlier on c.l.a. led me (eventually) to a report on the 
Therac-25 which I believe is the machine that made it into urban
legend as the killing machine.  I have not completed reading the 
report yet, but I also have not discovered any incidents of morbidity
directly attributable to the massive radiation overdoses that some
patients were exposed to.  A Google search on "therac 25" pops up
about 1050 links.
-- 
Scott Ingram
Vice-Chair, Baltimore SIGAda
Sonar Processing and Analysis Laboratory
Johns Hopkins University Applied Physics Laboratory

Re: Customer balks at Ada -- any hope?

[Florian Weimer]

Scott Ingram <scott@silver.jhuapl.edu> writes:

> A Google search on "therac 25" pops up about 1050 links.

I guess you've omitted the quotes.  If you enter them, the first hit is:

    http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html

(A reprint of a IEEE Computer article, which is the canonical source
for information on the Therac 25 incident, I think.)

Fortunately, you cannot blame any higher-level computer language
for killing people, at least based on this incident.  The offending
software was written in PDP-11 assembly language, according to:

    http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Side_bar_1.html

Re: Customer balks at Ada -- any hope?

[Ken Garlington]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87puo0eg2m.fsf@deneb.enyo.de...
> Scott Ingram <scott@silver.jhuapl.edu> writes:
>
> > A Google search on "therac 25" pops up about 1050 links.
>
> I guess you've omitted the quotes.  If you enter them, the first hit is:
>
>     http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html
>
> (A reprint of a IEEE Computer article, which is the canonical source
> for information on the Therac 25 incident, I think.)

Pfleeger in her text Software Engineering: Theory and Practice (1998) refers
to this 1993 Leveson/Turner article as the "Definitive analysis of a famous
software failure that resulted in loss of life." As far as I know, pretty
much everyone else accepts this as the canonical description of the
Therac-25 as well.

> Fortunately, you cannot blame any higher-level computer language
> for killing people, at least based on this incident.  The offending
> software was written in PDP-11 assembly language, according to:
>
>     http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Side_bar_1.html

Re: Customer balks at Ada -- any hope?

[Pat Rogers]

"Scott Ingram" <scott@silver.jhuapl.edu> wrote in message
news:397F442E.E132EFDF@silver.jhuapl.edu...
> Dale Pontius wrote:
> >
> > In article <3974F7A1.E806B092@silver.jhuapl.edu>,
> >         Scott Ingram` <scott@silver.jhuapl.edu> writes:
> > > wv12@my-deja.com put out some flame bait to which I responded:
> > >
> > >> C has been known to control big, expensive hardware. One such
> > >
> > > C has controlled big, expensive hardware...and people died.
> > >
> > Point of curiousity - can you expand on this? Tales of death
> > due to software error are surprisingly uncommon, given what we
> > seem to consider the poor general state of software development.
> >
> > Dale Pontius
> > NOT speaking for IBM
>
> The device I was thinking of was a medical radiation generator for
> the treatment of cancer.  However, a reference that Ken Garlington
> gave earlier on c.l.a. led me (eventually) to a report on the
> Therac-25 which I believe is the machine that made it into urban
> legend as the killing machine.  I have not completed reading the
> report yet, but I also have not discovered any incidents of
morbidity
> directly attributable to the massive radiation overdoses that some
> patients were exposed to.  A Google search on "therac 25" pops up
> about 1050 links.

Nancy Leveson's book Safeware indicates deaths were actually a result,
but not in all cases.  (She also states that the software was
developed in assembly language.)

--
Pat Rogers                            Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: Customer balks at Ada -- any hope?

[Ken Garlington]

<wv12@my-deja.com> wrote in message news:8l2pqo$im7$1@nnrp1.deja.com...
> I see
> on [sic] reason to avoid Ada that checks every shift, rotate, add,
multiply
> in your software.

I see several reasons to avoid any language that does this. Fortunately, Ada
isn't one of them!

Re: Customer balks at Ada -- any hope?

[mjsilva]

In article <8l2pqo$im7$1@nnrp1.deja.com>,
  wv12@my-deja.com wrote:
>
>
> In article <8l01s4$gnr$1@nnrp1.deja.com>,
>   mjsilva@my-deja.com wrote:
> > We're bidding on a custom industrial controller, and I've proposed
to
> > write the firmware in Ada.  The powers-that-be here are satisfied
with
> > that, but the customer is afraid nobody will be around to maintain
it.
> > They're happier with C or C++, alas.  Anybody have any good answers
to
> > their concern?
>
> >
> > I realize that implicit in their position is a belief that Ada
offers
> > no great tangible benefits to the project (even though the machinery
> to
> > be controlled is big, expensive and remotely-located),
>
> C has been known to control big, expensive hardware. One such
> example is the mutinode Deep Blue capable of searching a few million
> nodes per second.

Nowhere did I say otherwise (only a fool would suggest such a thing).
However, I firmly believe, as do most Ada users, that for a given
amount of effort an Ada program will have fewer defects than a C
program.  To argue otherwise goes against all the evidence.  According
to NASA, "The choice of 'C' is to be avoided for our domain of interest
because the language lacks the features that permit robust, reliable
programming."  I have the added datapoint of having determined over
this last year that about 90% of customer-discovered bugs in one of our
current C products would have been caught by Ada before the product got
out the door.

 Is the speed critical in this project? If so, I see
> on reason to avoid Ada that checks every shift, rotate, add, multiply
> in your software.

How much do you actually know about Ada?  A great many checks can be
optimized out, and others can be turned off at the discretion of the
programmer.  I have seen a figure of 7% for "typical" Ada overhead
(that's less than 2 months on the Moore curve).  So as I see it, 7% vs
1/10 the in-field bugs -- it may not be exact, but it sure looks like a
"tangible benefit" to me.
>
> > course strongly disagree with.  As I see it, the arguments are (1)
Ada
> > will offer tangible benefits, both in reliability and in development
> > time, and (2) a decent programmer can pick up similar languages
fairly
> > easily, especially for maintainence.  (Perhaps I should show them
some
> > Ada source...).  Ideas?
> Maybe you could try to sell the safety critical side of Ada. But
> software that does not get tested will crash, kill, dump core, etc...
> (Ariane comes to mind)

Who said anything about not testing software?!  Am I writing in
invisible letters that only you can read?  It's a known metric that for
each additional development phase that a defect persists after its
introduction, the cost of finding and fixing the defect rises by as
much as an order of magnitude.  Bugs caught in testing are much more
expensive to fix than bugs caught at compile time.  I have personally
spent hours or days finding bugs that Ada would have caught in
seconds.  And I *hate* debugging!

BTW, Ariane was not an Ada failure.  It would have come apart exactly
the same if the software had been written in C.
>
> You are not convincing me. Besides, the customer is always right.

I didn't set out to convince you, and you clearly are determined not to
be convinced, so we'll have to call this one a draw.  Why are you so
actively antagonistic?  I have a longtime C background and I happen to
be convinced that Ada is a better solution.  If you have evidence that
this isn't the case then maybe you can try to convince *me*.

Mike


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Customer balks at Ada -- any hope?

[Richard Riehle]

mjsilva@my-deja.com wrote:

> We're bidding on a custom industrial controller, and I've proposed to
> write the firmware in Ada.  The powers-that-be here are satisfied with
> that, but the customer is afraid nobody will be around to maintain it.
> They're happier with C or C++, alas.  Anybody have any good answers to
> their concern?
>

This situation is so common that we should have some kind of canned
response.   However,
there are a lot of people out there who will never be persuaded about the
virtues of Ada over
C and C++ regardless of what facts are presented.    A bunch of misinformed
software developers
at a mid-west USAF base comes to mind.

Someone once said, "He convinced against his will is of the same opinion
still."   Your customer
will continue to be wary of Ada simply because of the widespread mythology
about it.

A few things can be said that might make sense.   An Ada program,
well-written will probably be
more readable ten years from now than any program in C or C++ by a
programmer who has never
seen any of the above mentioned languages.   The Ada compiler you used for
the project will
still be around somewhere.   If someone understands the nature of firmware,
that same someone
will have no difficulty understanding your Ada code unless you make it so
cryptic that it reads like
C or C++ just to be mischievous.

That being said, I doubt you will have any success persuading the customer
that Ada is a better
choice.  Such people make up their minds, like the previously mentioned
software developers, and
simply close their minds to anything different from what they have already
decided.  You could write
the code in both languages and let them see the difference.  Doubt that
will help, but it might be worth
a try.

On the bright side, there seems to be a growing awareness that Ada has some
important benefits and
the increase in job postings here along with the increase in new companies
seeking Ada training seems
to indicate that all is not lost.

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

Re: Customer balks at Ada -- any hope?

[mjsilva]

In article <397CCF84.D54A1BC2@ix.netcom.com>,
  Richard Riehle <laoXhai@ix.netcom.com> wrote:
>
>
> mjsilva@my-deja.com wrote:
>
> > We're bidding on a custom industrial controller, and I've proposed
to
> > write the firmware in Ada.  The powers-that-be here are satisfied
with
> > that, but the customer is afraid nobody will be around to maintain
it.
> > They're happier with C or C++, alas.  Anybody have any good answers
to
> > their concern?
> >
>
> This situation is so common that we should have some kind of canned
> response.   However,
> there are a lot of people out there who will never be persuaded about
the
> virtues of Ada over
> C and C++ regardless of what facts are presented.    A bunch of
misinformed
> software developers
> at a mid-west USAF base comes to mind.
>
> Someone once said, "He convinced against his will is of the same
opinion
> still."   Your customer
> will continue to be wary of Ada simply because of the widespread
mythology
> about it.
>
> A few things can be said that might make sense.   An Ada program,
> well-written will probably be
> more readable ten years from now than any program in C or C++ by a
> programmer who has never
> seen any of the above mentioned languages.   The Ada compiler you
used for
> the project will
> still be around somewhere.   If someone understands the nature of
firmware,
> that same someone
> will have no difficulty understanding your Ada code unless you make
it so
> cryptic that it reads like
> C or C++ just to be mischievous.
>
> That being said, I doubt you will have any success persuading the
customer
> that Ada is a better
> choice.  Such people make up their minds, like the previously
mentioned
> software developers, and
> simply close their minds to anything different from what they have
already
> decided.  You could write
> the code in both languages and let them see the difference.  Doubt
that
> will help, but it might be worth
> a try.

I don't sense they have an active animus towards Ada, but only a
concern about maintenance.  I've prepared a response that tries to
point out the technical benefits of Ada and the relative unsuitability
of C/C++ for high reliability software (I found quite a few quotes from
DoD and NASA documents that help).  I've also tried to emphasize that a
decent embedded programmer should pick up maintenance Ada quickly and
that, OTOH, most of the vast pool of C/C++ programmers are not
necessarily qualified to do embedded programming.

Anyway, I'll give it my best shot.  The more I step back from C/C++ the
more unsuitable it seems to me for creating reliable software (and the
more important reliability becomes in my priorities).

Mike


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Customer balks at Ada -- any hope?

[gdemont]

> I don't sense they have an active animus towards Ada, but only a
> concern about maintenance.  I've prepared a response that tries to
> point out the technical benefits of Ada and the relative unsuitability
> of C/C++ for high reliability software (I found quite a few quotes from
> DoD and NASA documents that help).  I've also tried to emphasize that a
> decent embedded programmer should pick up maintenance Ada quickly and
> that, OTOH, most of the vast pool of C/C++ programmers are not
> necessarily qualified to do embedded programming.

You can make a good use of the following bright paper,
with killer examples (behind Java's problems there are
archaism or bad designs of old C...) and spiritual titles:

ftp://cs.nyu.edu/pub/gnat/jgnat/papers/ada95-benefits-on-the-jvm.pdf

HTH
______________________________________________________
Gautier  --  http://members.xoom.com/gdemont/gsoft.htm



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Customer balks at Ada -- any hope?

[Gary Scott]

Hi,
I hope that you will post/summarize your conclusions here in some detail
(as someone with an interest in discouraging the stampede towards C++ in
my company, I would like to distribute them more widely, if possible).

Thanks

mjsilva@my-deja.com wrote:
> 
> In article <397CCF84.D54A1BC2@ix.netcom.com>,
>   Richard Riehle <laoXhai@ix.netcom.com> wrote:
> >
> >
> > mjsilva@my-deja.com wrote:
> >
> > > We're bidding on a custom industrial controller, and I've proposed
> to
> > > write the firmware in Ada.  The powers-that-be here are satisfied
> with
> > > that, but the customer is afraid nobody will be around to maintain
> it.
> > > They're happier with C or C++, alas.  Anybody have any good answers
> to
> > > their concern?
> > >
> >
> > This situation is so common that we should have some kind of canned
> > response.   However,
> > there are a lot of people out there who will never be persuaded about
> the
> > virtues of Ada over
> > C and C++ regardless of what facts are presented.    A bunch of
> misinformed
> > software developers
> > at a mid-west USAF base comes to mind.
> >
> > Someone once said, "He convinced against his will is of the same
> opinion
> > still."   Your customer
> > will continue to be wary of Ada simply because of the widespread
> mythology
> > about it.
> >
> > A few things can be said that might make sense.   An Ada program,
> > well-written will probably be
> > more readable ten years from now than any program in C or C++ by a
> > programmer who has never
> > seen any of the above mentioned languages.   The Ada compiler you
> used for
> > the project will
> > still be around somewhere.   If someone understands the nature of
> firmware,
> > that same someone
> > will have no difficulty understanding your Ada code unless you make
> it so
> > cryptic that it reads like
> > C or C++ just to be mischievous.
> >
> > That being said, I doubt you will have any success persuading the
> customer
> > that Ada is a better
> > choice.  Such people make up their minds, like the previously
> mentioned
> > software developers, and
> > simply close their minds to anything different from what they have
> already
> > decided.  You could write
> > the code in both languages and let them see the difference.  Doubt
> that
> > will help, but it might be worth
> > a try.
> 
> I don't sense they have an active animus towards Ada, but only a
> concern about maintenance.  I've prepared a response that tries to
> point out the technical benefits of Ada and the relative unsuitability
> of C/C++ for high reliability software (I found quite a few quotes from
> DoD and NASA documents that help).  I've also tried to emphasize that a
> decent embedded programmer should pick up maintenance Ada quickly and
> that, OTOH, most of the vast pool of C/C++ programmers are not
> necessarily qualified to do embedded programming.
> 
> Anyway, I'll give it my best shot.  The more I step back from C/C++ the
> more unsuitable it seems to me for creating reliable software (and the
> more important reliability becomes in my priorities).
> 
> Mike
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.