Re: employment with ada

[Richard Riehle <richard@adaworks.com>]

DPH wrote:

> On Sat, 03 May 2003 12:17:31 -0700, Richard Riehle
> <richard@adaworks.com> wrote:
>
>
> >Reading through the list of reasons given for abanonding Ada in JSF,
> >I cannot agree with their decision.   There are plenty of opportunities
> >for Ada training outside the university environment, some of it of
> >better quality than they would get in college classes.
>
> Yes, and training people is counterproductive when you're exit
> interviews are turning up reasons like "I don't want to be stuck with
> experience only in a dead language."

I have trained a lot of LMCO programmers over the years.  From time
to time, I have heard one of them grumble about Ada.   Most of the
time, they have been quite positive about Ada.

> >The LMCO programmers are, as with any other kind of employee,
> >expected to work with the tools and resources appropriate to the
> >job.   Looking for another job is secondary to that.
>
> Its not secondary to the person looking for another job because they
> fear personal obsolescence.

An irrational fear, of course.  It is the responsibilty of management to
deal with such fears.   The reality is that any technology they might
select will be obsolete at some point, including C.

> >The focus of the JSF effort is to produce the best quality software
> >possible for the aircraft.
>
> Not true for any business.  The focus of any company is to make money.

Au contraire.  In this case, the focus is to build the best quality aircraft
possible.   Knowing the engineers at LMCO as I do, I have not doubt
they will do everything possible to do just that, regardless of what
programming language they are required to use.

If this were a commerical software product, I might agree with you
in some measure.  However,  any project that has as its primary
focus, "making money" is doomed to failure.    One must focus
on building the correct product correctly.   They money will
follow.

> >Instead, they cobble together a set of
> >restrictions for C, restrictions we can be assured will be ignored
> >over the lifetime of the project.
>
> They're using an automated tool to enforce them, so ignoring them will
> be difficult.

I'm glad you countered this point.   It highlights the widespread
miconception
that Ada is about what one cannot do rather what one can do.  This is a
problem not easily overcome when trying to compare C to Ada.

There are many other characteristics of Ada that lead to quality besides
those
that seem, at first, restrictive.    Some of these support what Grady Booch
calls, the "ilities."    For example, let's consider traceability.
Well-formed
Ada code tends to be easy to trace from unit to unit, in part because of the
strict visibility rules.  The fundamental language constructs, from separate
compilation, through child library units provide a structural integrity not
easily achieved in a low-level language such as C.   More trivial, but
important features such as named association provide a level of readability
that one might be able to emulate with automated tools, but not as well
as when they are integrated into the language.

Putting aside the newer features of Ada such as protected types, inheritance,

and dynamic binding, since these are not as useful in safety-critical
avionics,
one cannot ignore the other features of Ada that contribute to a powerful
capability for project-level code reuse.

Yes.  One can certainly constrain (even cripple) C, so it is a little bit
safer than its standard language description.   One cannot promote any
construct in C so it will correspond to the built-in capabilities an Ada
designer or programmer can enjoy.

> >Some Ada compiler publishers have vanished.   Many of those
> >were simply acquired by Ada compiler publishers that still exist.  Some
> >should have gone out of business a long time ago.   A few are hanging
> >on by a slim margin, and this decision does not help.  The hardware
> >vendor compilers (HP, Tandem, etc.) actually used Alsys (now
> >Aonix) compilers with their own label so the list of compilers is
> >smaller, but the original developers are still around.
>
> Dec never made an Ada 95 for VMS.  I just learned that Rational Rose
> RealTime doesn't speak Ada.  What's with that?  If you can't generate
> code automatically from one of the most popular UML tools in
> existence, what does that say?

There are people using Rational Rose and Ada together quite
comfortably.   Also, Rational is not the only game in town.  Aonix
will soon announce a new set of tools, and they are still very much
in the Ada business.   Aonix also has a UML tool, Software Through
Pictures.   I recently talked with the President of Green Hills and
learned they are doing really well with the Ada component of their
business.  Also, they support an excellent inter-language development
capability along with a pretty slick development environment.  Some
of my clients are using Green Hills quite happily.

There are certainly some excellent Ada embedded development
options out there.   Even GNAT, public as it might be, is currently
serving in the embedded marketplace.   ICC and DDC-I both continue
to produce good products for embedded systems.   If it is not sufficient
to be able to select from a least six good compiler publishers, how
many do we need?

> Its the BetaMax - VHS scenario all over again.  Being technically
> superior doesn't really count for much nowdays.

I have heard this argument before.   When we are building safety-critical,
high-integrity weapon systems, technically superior should count.  This
is not a mass-market consumer product.  People's lives depend on the
end product.

> >if the reasons they gave are the real reasons, it was a wrong
> >decision.
>
> Doesn't sound like it to me.

We will have to agree to disagree.

> If they really can't find programmers, which is a common complaint
> heard from many sources, so is probably true, then that's a valid
> factor.

Not a good reason.   The programmers are out there, right now looking
for jobs.   I know a lot of unemployed programmers at present.  This
is am employer's market.  And those programmers will write code
in any language they are given as long as they have a paycheck.

> If they really do lose people simply by assigning them to Ada, then
> that's a factor.

I know lots of programmers, including LMCO programmers, who are
delighted to be programming in Ada.

> If Ada compiler vendors are going out of business, 1 by 1, as time
> goes by, and unnneccesary source code conversions will be required
> simply for this purpose, then that's a factor.

Actually, when looks at this issue, it becomes clear that they are not
necessarily all going of business.   In some cases they are consolidating,
in others diversifying.  Rational began life as an Ada company.  They
still have Ada customers and would be happy to continue to have
Ada customers if those customers buy their products.   This is the
real case of a company being in business to make money.   However,
they began their Ada business with the combined goal of creating
a quality product and making a profit.    They now have a quality
product.  They cannot support the product if they have not customers.

When a potential customer such as LMCO decides to abandon Ada
for one of its critical projects (not all of LMCO has abandoned
Ada), it helps to fulfill its own vision of Ada in decline.   Also,
some Ada compiler publishers are enjoying an upturn in success
with Ada, perhaps at the expense of those who are not providing
as much support as their prospective clients might expect.

> >It will cost them more in the long run,  they will be
> >fighting with quality issues in C they would not encounter with
> >Ada, and the programmers they are trying to retain with C will
> >leave just as quickly if not more so than if they were using Ada.
>
> If you don't know the particulars of the 172 C language restrictions,
> nor the tool used to enforce them and check the code for other errors,
> I don't see how you can say that.  I doubt there are any studies
> outside of LM comparing the error rates between Ada and their own
> particular way of doing C.  This C strategy may indeed be close enough
> to Ada in error avoidance to be superior to Ada when considering the
> stated drawbacks that would be incurred by using Ada.

As noted earlier, this is a shortsighted view of the benefits of Ada.  It
presupposes that Ada is valuable for what it restricts rather than for
what it enables.   Taking that view, C cannot begin to approach Ada
for what it enables.   Also, even with automated error avoidance,
it is difficult to take a language in which the default is "unsafe" and
make it more safe.   As for the "stated drawbacks" I have commented
on these earlier and consider them wrongly concluded.

> I always condemned the short-sighted idea that companies must be able
> to hire people that already program in the language of interest
> instead of training them, but when they leave because they fear
> obsolescense, then that is a real problem that can't be ignored.

In this we agree.

Richard Riehle