Re: Customer balks at Ada -- any hope?

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

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