Re: Customer balks at Ada -- any hope?

["Ken Garlington" <Ken.Garlington@computer.org>]

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