Re: Customer balks at Ada -- any hope?

[Scott Ingram` <scott@silver.jhuapl.edu>]

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.