
Ada holding up F-22 Raptor upgrades - theclay
http://www.defensenews.com/story.php?i=6559166&c=AME&s=AIR
======
jameskilton
Odd story, makes software development in Ada kind of a catch-22. The DoD has
used Ada for so long because of the security and correctness constraints built
right into the language and compiler. When you're talking about software
that's flying a plane (passenger, war time, whatever) it HAS to be right,
because if it's wrong, people die. When something HAS to be right, that by
itself ensures longer development time and testing.

Now I'm not in this industry, but I know that planes these days are extremely
complicated beasts and require a ton of code to run everything properly. I
worry that if development is artificially sped up, that code problems that
would have been caught in the testing get caught in production.

Of course the above kind of assumes a decent dev team and a good code base.
What I said could be moot if what's really happening is the technical debt of
some of this code is so massive that simple changes take months to make and
ensure correct, which would be a problem for sure.

Either way, blaming the language probably isn't the right way to go about
this.

~~~
nradov
I have no idea about their overall code quality but there was a famous F-22
bug found a few years ago where it lost all navigation systems when crossing
the international date line.

[http://www.defenseindustrydaily.com/f22-squadron-shot-
down-b...](http://www.defenseindustrydaily.com/f22-squadron-shot-down-by-the-
international-date-line-03087/)

~~~
stcredzero
Date/Time code is notorious. It always seems simpler than it actually is.
There are always corner cases you forgot about. None of it is rocket science.
Instead, it's the stupid arbitrariness of it that gets you. (Commodity trading
is often the same.)

~~~
tseabrooks
My boss taught me that whenever the word date / time / etc creep into a spec
double your estimation for completion.

He was trying to be funny to make a point... but there is definitely a nugget
of truth to it. Time is hard. (I write embedded DVR software these days)

------
bugsy
But I want the lolly NOW!!!!

But seriously, Ada is well designed and not difficult. Ada is not part of the
problem, this would take longer and be less reliable in C++.

~~~
gaius
The article actually nails the real reason: the USAF bought far fewer F22s
than it originally planned, so things like this that apply equally to 1 or
1000 have to have their cost spread over far fewer individual units. I'll bet
that the F22 software is not actually that much more complicated than that
controlling a modern car, yet Ford or whoever can spread the cost over a
million units.

~~~
masklinn
> I'll bet that the F22 software is not actually that much more complicated
> than that controlling a modern car, yet Ford or whoever can spread the cost
> over a million units.

I'll bet it is. A car is significantly simpler than a fighter plane (at all
levels of resolution), even when you discount weapons and detection systems.
Which you can't discount when you're building software for a plane.

Furthermore, the risks involved in a fly-by-wire avionics soft are much
greater than in cars in case of bug or crash: there are no drive-by-wire
production cars today, although there are many electronics systems.

~~~
gaius
We've had self-landing planes and autopilots for a long time. Self-driving
cars are still a long way off. So I would say that don't underestimate what
software you need in a car.

And even if the F22 is 10x as complex, Ford still has 100,000 cars to spread
the cost across.

~~~
thaumaturgy
That's the result of a combination of two things: aircraft don't often have
one of the major problems that cars have (dense traffic and other obstacles),
and that the problem of dissimilar surfaces was solved, for aircraft, by
making the surfaces more similar. Cars instead have to be able to negotiate a
variety of terrain.

So, safely automating cars is a harder problem, but not because the car itself
is a more complex vehicle.

~~~
gaius
A harder problem requires more complex software, no? The complexity of the
vehicle itself is actually not a factor.

~~~
thaumaturgy
Oh, you're right. Somehow I misread your earlier statement as being about the
complexity of the machines themselves.

I agree totally with you then. Even accounting for avionics, control surfaces,
target acquisition, and so on and so forth, automating cars is a much harder
nut to crack, software-wise.

------
hsmyers
OK, everyone here who codes in ADA, raise your hand. Atlas?

~~~
mithaler
I hadn't known much about Ada other than that it's very old (as programming
languages go) and it has a kind of nonspecific bad reputation, but I looked it
up on Wikipedia and it actually doesn't look like an unpleasant language at
all from the article. I particularly like its built-in message-passing system
for concurrency:
[http://en.wikipedia.org/wiki/Ada_(programming_language)#Conc...](http://en.wikipedia.org/wiki/Ada_\(programming_language\)#Concurrency)

On projects like this I would worry more about accumulated technical debt from
decades of modification than the language they're written in. (I suppose the
language can complicate the task of hiring programmers who are skilled with
its idiosyncrasies, but that's hardly an insurmountable or crippling problem.)

~~~
totalc
From my defense software experience with Ada 83 and Ada 95, Ada's concurrency
features made it much easier to work with than C. Tasks/processes were a top-
level feature of the language, like classes in Java, and the "protected"
keyword functioned somewhat like "synchronized" in Java (an implementation of
the monitor pattern).

Our compiler package also came with an extensive concurrency API that offered
a variety of threadsafe containers comparable (again) to java.concurrent - and
this was software from the late 80s/early 90s!

What was bad about Ada was Ada 95. It strove to make Ada into an object-
oriented language, but did a poor job of it with some very tortured syntax.
_edit_ what Masklinn said - "bolted on" is a perfect way to put it.

------
seanwoods
What's used in place of Ada nowadays?

~~~
gaius
OCaml would be a great fit for this space, so would Haskell or Scala...

~~~
sbalea
Oh hellz no! Most of the systems ADA is used for tend to be realtime stuff.
The moment you utter the words "Garbage Collection" you throw your realtime
guarantees down the toilet.

~~~
gaius
Tell that to Airbus: <http://www.astree.ens.fr/>

~~~
_djo_
Hardly the same thing though. Astrée is a static analyzer used to help prove
avionics code written in C, it's not used in any onboard avionics systems. So
its lack of real-time processing is not important.

If you're writing real-time avionics software, your choices are really only
Ada, C and C++. Most companies I know of, including Airbus, are using C.
Typically, avionics software has to be qualified to DO-178B/ED-12B standards
which specifies certain development, testing and proofing requirements.
Software verification tools like Astrée are also governed by DO-178B/ED-12B,
though they are subject to a lighter verification process.

