The F-35’s Software Is So Buggy It Might Ground the Whole Fleet
motherboard.vice.com
motherboard.vice.com
* Pilots, maintainers, and administrators at three of the five sites we visited are concerned about ALIS’s ability to deploy and function in forward locations. For example, users are concerned about the large server size and connectivity requirements, and whether the system’s infrastructure can maintain power and withstand a high-temperature environment.
* ALIS users at three of the five sites we visited are concerned that a failure in the system’s current infrastructure could degrade the system and ground the fleet. Currently, ALIS information, including data from all U.S. F-35 sites, flows from the Standard Operating Units (SOU) to a single national Central Point of Entry, and then to the lone Autonomic Logistics Operating Unit (ALOU).26 This data flow process has no back up system for continuity of operations if either of these servers were to fail.
* Maintainers and pilots at three of the five sites we visited were concerned that ALIS does not have much interoperability with legacy aircraft systems... The ability to share information between ALIS and these legacy systems is vital due to the way the services operate.
* Maintainers at four of the five sites we visited told us that the current Action Request (AR) process does not allow for the effective reporting and resolution of F-35 aircraft and ALIS issues.
* ALIS users at all five sites we visited are concerned with data accuracy issues within the system, including missing or inaccurate data and inaccessibility of raw data within ALIS.
http://www.gao.gov/assets/680/676576.pdf
Description of ALIS risks starts on page 15.
> ALIS does not have redundant infrastructure: ALIS’s current design results in all F-35 data produced across the U.S. fleet to be routed to a Central Point of Entry and then to ALIS’s main operating unit with no backup system or redundancy. If either of these fail, it could take the entire F -35 fleet offline.
That sounds like a movie plot [Independence Day] (or Battlestar Galactica)!
So, the enemy jams comms or shoots down satellites, and a F-35 squadron deployed to a base on the other side of the world can't do maintenance? An aircraft carrier is attacked and its antennas are destroyed, and they can't do maintenance? The enemy breaks into or takes offline the Central Point of Entry over the Internet (oh, but it's airgapped, of course...), and the entire F-35 fleet around the world can't do maintenance? (Or can't do it at the level required to maintain combat readiness.)
Am I misunderstanding something here?
Where was the oversight? It's beyond incompetent.
If I was paranoid I'd wonder if procurement and architecture had been taken over by hostile agents.
Short of putting a remotely controlled logic bomb and/or actual explosive device on every plane, it's hard to imagine how the F-35 could possibly have been made more vulnerable and less fit for purpose.
This makes it sound as if ALIS does maintenance. ALIS does not do the maintenance. Human beings still do the maintenance.
Well, obviously, ALIS is not a robot with mechanical arms that do the physical work (although with its name, it wouldn't be surprising if some people expected "Alice" to do just that; and the personification is creepily reminiscent of 2001: A Space Odyssey).
But from what I've read in these articles and part of that GAO report, it sounds like ALIS is part of the designed maintenance protocols. For example, Action Requests are entered into ALIS and uploaded to the contractor (!) who triages them (!) and collates data across multiple sites (noted in the GAO report are problems such as a software update preventing contractors from receiving ARs while the on-site personnel are waiting for an answer--eventually they call and ask, hey, what about those ARs? and the contractors respond, what ARs? because they didn't know they were failing). And technical manuals are accessible through ALIS instead of having to refer to paper manuals.
Of course, these are all so vague and general that it's hard for laymen to figure out what it would mean in practice. The terms used in the GAO report for expected functionality are so non-specific that it seems nearly useless to even use them.
Having said all that, the GAO report does mention (buried in the middle of a paragraph, not prominently like a major vulnerability should be) that ALIS can be used in an offline capacity:
> DOD officials told us that they recognize this issue and, for short-term losses of connection, ALIS users are able to work offline. (page 17)
But that doesn't sound very reassuring to me. In wartime, all sorts of bad things happen, and lost connectivity and communications should be at the top of the list of expectations. If maintenance is severely degraded and aircraft can't fly sorties at the needed rate, well, in a war....
If that's true, it sounds like a solution is search of a requirement. IIRC, but I don't think the US military has had problems with tampering and sabotage of military jets.
"Attention! Counterfeit hydraulics system installed. F-35 disabled until genuine system purchased".
This would stop people buying cheap F-35 spare parts from China on ebay and trying to save a couple of million dollars.
But to give a real answer:
If a jet sits for 30 days without any maintenance, then it's supposed to be preserved. This means all fuel is offloaded, all lubricants drained and then refilled and then drained again (leaving a film of clean lubricant over important parts), etc. Otherwise, you have to perform an engine run to keep the aircraft nominally flyable.
Really, if you aren't flying, you are either doing maintenance to prepare to fly, fixing something, performing scheduled inspections, or performing modifications. So if the aircraft is operational, there is no such thing as a 30 day period without maintenance.
Without ALIS, you just do all of this via the old paper processes for a while.
How the heck to do you airgap a "Central Point of Entry", lol.
But the would-be US presidential candidate suggesting free higher education is the fiscally irrespomsible fantasist, apparently.
I've seen estimations of about 1.7 trillion for the wars since 9/11. That'd be another 24 years.
Peter Dale Scott wrote a book about something he calls "The Deep State" which at least, to me helps explain how seemingly regardless of who gets elected, such unpopular expensive programs continue without elected officials people having any discussion of legislation to stop it.
What has increased is the share of that cost that is being fronted by the student, instead of the government. You want to be mad, be mad. But at least point it in the right direction.
For example - at the 'state funded' institution I was previously employed by, only 11% of our annual funding came from the state. Compare that to the 1970's, when around 60% came from the same source.
The cost of tuition didn't increase (outside of annual inflation adjustments) overall. The cost to the student increased because the state cut back so hard on their payments. Meanwhile, students demand the same, or better services every year. You can have cheap, you can have good, but you can't have both.
The fact that people going to college in the 1970's were able to pay for college on part-time summer jobs wasn't because it was miraculously cheap. It was heavily subsidized.
These aren't secrets.
For instance, there's occasional debate about defunding public broadcasting, which costs 0.013% of F35 + wars. Planned Parenthood is 0.018% of this. Even the often hotly contested NASA is 0.62% of this.
A few years ago, congress was in heated budget debates - trying to knock off PBS to save a buck - but a plane that cost 48,743 times that was never brought up for discussion.
Even if you span these budgets over the 20 years of the F35 program, something like planned parenthood cost 0.4% as much.
If we can find the time to talk about X as a huge waste of tax payer dollars and have legislation to defund it, surely we can find time to talk about something that costs 25,000% more than X.
However, other than an occasional news article and grumble of discontent, nothing actually happens. It moves forward unabated. That's a problem.
It seems such a terrible mis-allocations of resources since those same brilliant people could help the next generation learn and progress.
Or the simpler explanation is that Americans do not value public higher education as much as they value their global hegemonic position.
Secondly, teaching jobs in the US are extremely hard to come by and have such poor pay that most people in manufacturing would do better in the same communities by looking for factory work.
As it stands, most of the "brilliant" people that are motivated enough simply leave these areas for bigger metro areas and the typically rural communities that make up a very large portion of the US's population and area suffer brain drain. Over generations, this flight becomes culturalized resentment for those trying to better themselves and there is strong pressure against people from leaving. Hence, one of the strongest values among rural people here is "nobody is better than anyone else" and any hint whatsoever of arrogance is extremely chastized. The irony that this is surprisingly close to what liberals fight for in the US politically never seems to register (much of politics in this country is really strange but primarily racially divided or based purely upon economic standing at this point rather than upon actual political views - most black voters are actually conservative and most poor rural whites would vote Democrat if gun control was relaxed, for example).
Anti-intellectualism is very strong in the US compared to most countries in the world and needs to be examined much more closely than other factors IMO.
Boeing writes (nearly) everything in Ada and as far as I know has never had any software problems of this scale. Most of it is in SPARK as well, a restricted subset of Ada that can be partially formally verified[1]. Frankly, not formally verifying mission-critical software where a failure can potentially threaten someone's life seems rather irresponsible.
1. Contrary to what seems popular opinion, regular Ada is not particularly strict (less so than Rust). SPARK is very, very strict about what you can compile, and if it compiles it follows the spec (which is usually easier to audit).
http://www.militaryaerospace.com/articles/2013/10/software-c... -- but a Google search reveals much the same from any article I can find, and just reiterates what I've read in past articles on F-35 software.
As the article states: “ALIS is the ground-based computer system meant to diagnose mechanical problems, order and track replacement parts, and guide maintenance crews through repairs. It also allows pilots to plan missions and later review their performance.”
We didn't formally verify the code, its way too complex, but everything was reviewed and heavily tested. And tested again. Then integrated and tested...
Ada is pretty strict and if it compiles you usually had some confidence it was going to at least run ok.
The industry was moving to C/C++ because developers know it and promises of higher productivity.
I did kinda grow to like ada. It had its warts, but it was good. It reminds me a bit of GO with its packages.
Ada Tasks also bear some semblance to goroutines. (In the sense that they share memory by communicating instead of communicating by sharing memory.)
It's definitely a nice and well-designed language IMO—with a share of annoyances[1] and flaws—but overall deserving of more attention than it gets. Lately I've gotten comfortable enough with it that I have been making a habit of reaching for Ada for side-projects where I would formerly use C. (For example, I'm writing a toy X window manager in Ada at the moment—using XCB from Ada is a little ugly at times but definitely bearable.)
1. For example, why can't a record discriminant be a range bound? Answer: standards committee didn't think people would use it. Of course, this means if you have an array of discriminated size, you can't conveniently have a type for a position in it. e.g.
type Thing_Stack (Max_Size : Positive) is record
Elements : array (Positive range 1 .. Max_Size) of Thing;
Top_Index : Positive range 0 .. Max_Size := 0; -- 0 = Empty stack
end record;
> This restriction is left over from Ada 83 (RM83 3.7.1(6)). We considered removing this restriction in Ada 95, but ultimately decided that the implementation effort to support this modest extension would outweigh the (more?) modest benefits. Perhaps a short-sighted decision, in retrospect...
> As for why the original Ada 83 restriction existed, noone knows for sure, but it probably relates to the historical purpose of discriminants as only for controlling the "shape" of the record, rather than being seen (as in Ada 95) as more general type "parameters."
And apparently it got left in Ada 2012 also.
(For C people, this is basically:
typedef struct {
size_t max_size, top_index;
thing elements[];
} thing_stack;
2. http://computer-programming-forum.com/44-ada/82b646ab38d529a...
I liked the records in ada. You could control the position and size of each field (which was really usefully for dealing with in binary messages) We had a ton of constrained types.
If I remember we has assert 'size on some of the records to make sure type changes didn't cause some records to become unexpected sized in case the types that made up the record changed.
variant records were fun, but when you start trying to do much (array of variant records?) it fell down.
The string handling left a little to be desired though..
Not that alien a comparison, since Ada and Go both descend from Niklaus Wirth's languages. Ada was directly based on Pascal, whereas Go (and its precursors) is strongly influenced by Modula and Oberon, themselves successors to Pascal. Aside from some superficial syntax differences, Go looks a lot like Modula and Oberon.
The slightly sarcastic answer would be "C++, of course". There is even a code standars document that's floating around. (Edit) Link: http://www.stroustrup.com/JSF-AV-rules.pdf
That said, I don't really think the troubles come from the technology side of things.
https://www.csiac.org/wp-content/uploads/2016/02/2010_03_30_...
Please nobody tell them.
That is a level of scary, I'm not comfortable with in our military's data. Logistics data flying across a civilian WiFi is really not good.
As you said, security requirements that are that onerous and too rigid to relax when necessary is just shittily designed security to begin with.
I believe this picture is also a suitably canonical example.
http://www.jumpoverthere.com/wp-content/uploads/2012/10/secu...
"Hey IT dept. I understand the reason for our network restrictions, but we have a lot of data that we need to get to [some endpoint] using [some method]."
"Sorry, we can't relax the restrictions. You have to work within the parameters."
"But the parameters do not allow me to complete my job."
"Sorry."
I'd love to work within the parameters, but when IT won't budge, you're stuck with the least preferrable method.
Clearly, in the case of the F-35 systems, federal law was violated doing the offsite thing. We see developers (and frankly some sysadmins) violating HIPA and this kind of stuff has to stop.
I knew this at the time. I never blamed IT directly for the issues, because I knew that they were just doing their job as well.
I don't think your wrong, but an awful lot of system admins have ended up dealing with lawyers and courts. Your system admin having had a prior talk with the lawyers about security, HIPA, and who is liable will do wonders for their willingness to bend the rules for you.
According to both HIPAA and the major revisions in the American Reinvestment Act (aka Hurricane Sandy Bill), all HIPAA requires is non-cleartext data. It does not recommend or even define a cipher or crypto standard anywhere in the legislation. Legally speaking (IANAL), a zip file with password is fine according to HIPAA since it's non-cleartext.
So when those admins were in court it is usually due breach of contract (job spec says protect data, follow laws, etc.), heavy-handed tech illiterate lawyers, complete incompetence in hiring the sysadmin, or some other combination of madness - and not directly due to violation of Federal healthcare law.
https://www.youtube.com/watch?v=sRe77Mdna0Y
The Joint Strike Fighter (JSF) is the first major DOD aircraft program to use
C++. Much of this software is either safety critical or mission critical and so
must be written in such a way as to be clear, readable, unambiguous, testable,
and maintainable. We discuss the driving requirements behind the standard and its
evolution. We give a quick overview of our standard and discuss how it differs
from later standards such as MISRA C++. We discuss lessons learned over our nine
year history of applying the standard to a large embedded software program. We
also address ambiguities in rules and difficulties with automated checking of
conformance with the standard.It's just software...
A lot of these are "cost plus" contracts (the government pays the cost + a fixed % profit, and bonuses for meeting delivery dates). This has been railed against as wasteful compared to the private industry [1] This is some of the thought process
(from article:) "I've talked several times this year about the importance of having mature technology before you go into production," Thornberry said. "A lot of what happens with cost-plus situations is the technology's not mature so you don't know what it's going to cost because you haven't invented it yet. That's exactly what we're trying to get away from."
So the more excuses the companies make the more money make (the spec changed..), as long as you can get someone to sign off on it. The cynic in me notes that a lot of these companies have former military heads as presidents.
[1]http://www.defensenews.com/story/breaking-news/2016/02/25/mc...
This plane is highly political and its not really easy to "pull the plug" or not pay since many states will loose workforce.
Robert Gates wrote a chapter in his book about it that was fascinating.
http://www.amazon.com/Duty-Memoirs-Secretary-at-War/dp/03079...
I think it may still be in beta, or the equivalent.
But I can't help but think of Battlestar Galactica. At what point does this software become too complicated? At what point does it become a vulnerability to be exploited by the enemy, or simply a liability reducing readiness below what's needed in wartime? I don't recall hearing stories about the F-16's or F/A-18's computers crashing and needing to be rebooted (or even the F-22's).
I think a lot of it comes back to scope creep, the F-22 was designed for one branch by one branch to do one thing well, the F-35 was designed for multiple branches by multiple branches to do a bunch of things somewhat well.
It's an absolute bear of a programme.
ALIS is the logistics system for the program that has an off-jet and on-jet component. ALIS takes the role of a traditional computerized maintenance management system and expands it to include an on-aircraft prognostics and health monitoring component. The idea is to have the jet tell you what's wrong with itself.
The article you linked to is about the F-35's mission systems software, which is really a software suite that encompasses all the computers on the aircraft itself. The MS software load provides all the stuff necessary to make the jet's hardware do what it needs to do to fight.
EDIT: I am merely seeking clarification, not trying to evade answering.
I'm not sure I'm making a ton of sense. It's just really interesting, I'm in Denmark and our government are about to pick which fighter plane will replace our old F-16s, and the F-35 is the favorite right now. This is despite experts saying it's a bad plane. What I understood from your comment is that it will fly just fine, but bugs in the ALIS software would make it harder to operate than anticipated.
For years, the F-35 project has been calling ALIS absolutely critical. Now, they seem to be saying that the F-35 can fly without it and that ALIS only keeps the cost of ownership down.
I suspect that the real answer to that question is either classified or closely held amongst a core group.
So I guess we can wait and see what happens on the 31 day? SNAFU is all that comes to mind.
I'm not wholly sure '15 hours uptime' on a computer system is all that confidence-inducing, regardless of whether or not the plane can be reset after however few hours of flight-time it's able to muster.
TFA is about the "Autonomic Logistics Information System" (ALIS) system used to automatically order replacements parts and schedule service, NOT the plane itself.
It's grounding the plane because they can't schedule maintenance and order parts correctly now that they're moving to this new system, not because the plane itself is buggy. The planes have been flying (mostly bug free) for over 10 years now.
A lot of people here are using this to scapegoat C++, but although the plane is written in C++, I don't think the ALIS is...
I've lived through a few major weapons systems changes and its all the same. Heck, anyone who has ever worked on a large project knows this stuff is fairly common. A lot of people don't want this thing in the air, especially Russia, China, Iran, and North Korea. Its a very capable weapons system and fills a much needed role.
Its crazy a lazily sourced article like this could make it to the front page of HN. It reads like my grandmother wrote it, "THE AIRPLANE IS RUN BY A COMPUTER! TECHNOLOGY IS SCARY!" To compete on this level, automation and complexity are required. Its silly to think we are going to back to how planes were designed 50 years ago.
Which role?
I generally agree with your points, but not this one. I've seen no partisan bias in the criticism, and John McCain is the biggest critic of this program, which is being pushed by the Obama administration. In fact, IME most of the criticism comes from the temper-tantrum-of-the-week branch of the GOP.
Also, Democrats have become hawkish; almost everyone says they are for a strong military including Clinton and Obama. There aren't many of those knee-jerk doves left - can you name a prominent one?
"The planes have been flying (mostly bug free) for over 10 years now."
Considering first flight was in December of 2006 there's no possible way it could have been flying for a decade as of today. Also that was the maiden flight, not a take-delivery-first-production-flight, but the first flight ever.
As for bug free, I'd beg to differ: * On 18 January 2013, the F-35B was grounded after the failure of a fueldraulic line in the propulsion system on 16 January. * On 5 June 2015, the U. S. Air Education and Training Command Accident Investigation Board reported that catastrophic engine failure had led to the destruction of an Air Force F-35A assigned to the 58th Fighter Squadron at Eglin Air Force Base, Florida, on 23 June 2014. * On 23 June 2014, an F-35A preparing to take off on a training flight at Eglin Air Force Base experienced a fire in the engine area. The pilot escaped unharmed. The accident caused all training to be halted on 25 June, and all flights halted on 3 July. During the incident investigation, engine parts from the burned aircraft were discovered on the runway, indicating it was a substantial engine failure.
And a report issued in 2013 stated these amongst other major problems: * Current aircraft software is inadequate for even basic pilot training. * Ejection seat may fail, causing pilot fatality. * Several pilot-vehicle interface issues, including lack of feedback on touchscreen controls. * The radar performs poorly, or not at all. * Engine replacement takes an average of 52 hours, instead of the two hours specified. * Maintenance tools do not work.
"Bug free" I guess if those are acceptable criteria for a government defense platform that has racked up over a trillion in cost and has yet to perform much, if any, real-world value.
I said "over 10 years" because the first "official" flight was probably not the first flight ever. Change it to "over 9 years". Whatever. Practically the same thing.
The next sentence in the Wikipedia article you quoted says the grounding from 18 January 2013 was lifted 28 February 2013. Likewise the June 2014 grounding was lifted shortly after.
Regardless, I said "mostly bug free,", not "entirely bug free". Most aircraft get grounded at some point due to issues or accidents that are discovered after they've been flying a while, so it's really not very exceptional, and hardly means the entire project is a failure.
Do any of your nitpicks change the fact that that the article posted here isn't about the C++ software on the plane, but is about the non-C++ software running ground systems?
I don't have any opinion on whether the plane is a waste of money or a failure or not, but the headline is misleading, and people are missing the real point of the article.
2) The F-22 software was largely written in Ada, a sane language that's great for real-time systems that cannot fail. Apparently the F-35 software is mostly written in... C++. Writing fault-tolerant real-time C++ is like walking on a tightrope while gripping a gun with the safety off. You can do it, but it's not particularly pleasant.
3) Apparently the team was considerably expanded/replaced between the F-22 and F-35.
What the heck are we doing with these airplane projects? We build stuff we don't need, that doesn't work, and is waaay more expensive than we thought, and the starting cost point was extremely expensive to begin with.
It was canceled because it was expensive and no longer needed, because the mission it was designed for - fighting a peer enemy - no longer existed. That was 2009, when the U.S.'s primary military concern was fighting two simultaneous wars against enemies who didn't own one airplane or air defense system. Any plane could do the job; we didn't need F-22s. Also, our prior generation planes were still the best in the world.
Seven years later, Russia and China have engaged in massive military military buildups, including significantly improving their air combat capabilties, and aggressive behavior. The peer enemy mission is back at the top of the list (and some are now talking about re-starting F-22 production).
Gates is also on record as saying that the F-22 was cancelled on a cost per aircraft basis. Which is a bit of a circular argument, because the cost per aircraft would dramatically decrease if the originally planned number had been built.
>> wondering why it doesn't work now
Assembly is instruction-by-instruction, line-by-line.
Not that C++ is by nature an unstable language, but I'm sure the margin of error is higher by nature simply by not using ASM.
Please, correct me if I'm wrong.
I've often thought it programmers could be less afraid to code in ASM we would see the most incredible things on something like a PS4.
Of course, that's impractical as all hell due to millions of lines of code turning into a billion or whatever.
I used to use ASM all the time for Sega Genesis/GBA home-brew and what-not. I kind of actually miss it. :3
Who said they were flawless? Most major new platforms, including many prior fighter planes, had similar teething problems. Novel, huge, highly-complex, mission- (and life- and national-security-) critical systems are going to have a lot of them.
Also, modern systems have orders of magnitude more software, due to orders of magnitude more computer capability.
Programming languages haven't evolved much since the 70's, yet the number of lines of code we have to write to fly a 5th generation fighter jet has probably followed the same curve as the number of transistors inside it. And scaling a CPU turned out to be easier than scaling a program. Imagine the difference in complexity between the earliest computers controlling car engines, and what the computers inside a new Tesla are doing. The same with jets. Modern jets can barely stay airborne without a lot of computer power.
Even now, someone in college and spend all of their free time reading blogs and books for best practice development and can generally fit in pretty good with any development group once graduated. I don't think people had those luxuries in the 70's.
That's really, really, REALLY not true.
https://medium.com/@verne/margaret-hamilton-the-engineer-who...
^^ fairly sure that she was thinking a lot about testing
Ars ran a similar article to this one in January: http://arstechnica.com/information-technology/2016/01/f-35-s...
I was an employee at Lockheed during the time of when the "JSF" vendors were competing for the contract. While I wasn't directly involved in any F-35 programs (I was on the MS2 side supporting NATO programs, particularly ASOC / SCCAN - that's another story in itself...) I was friends with a few programmers responsible for the main flight systems of the early aircraft (I'm unsure if that system was ultimately used in the production version or not) and the attitude seemed to be that the aircraft would never make it to operational use anyway. I was a, relatively, new and naive employee (first employment after college) and it struck me as odd that the plane was a joke internally to the company, at least those "building" pieces of it and it makes me wonder today if the lackadaisical attitude was ripe across all facets of the program. If so it makes sense today of all the failures the program has endured. The aircraft has always underperformed and been overbudget.
Ultimately the tax payers foot the bill for a next-gen aircraft that continually gets beat by task-specific variants that are decades older unfortunately. I used to joke around with people about how the $1000 toilet wasn't far off once I learned about how every program's goal was to be cost plus and then milk scope creep to the Nth degree.
The programs I was involved with were selling commodity Sun + Cisco + some overpriced serial to Ethernet bridges (http://spt.sunhillo.com/products.php) tied to some archaic war/peacetime ATC software. It was absolutely astounding what those packages cost and what was actually delivered.
I saw some were asking what language for some of these systems and if it were along the lines of what I was exposed to it was a mix of anything and everything. Most critical systems were written in ADA, as suggested, but I saw Java (think awesome Java in the early 2000's), TCL, shell scripts and the like as major components to these systems. In fact I remember a dev having problems getting working out reading serial data from a GPS receiver to set proper system time - so he just bundled ntpd in the build as his own work.
Working there was an eye opening experience for both good, and bad reasons. The stereotypical jokes were, unfortunately, true to an extent and I couldn't continue to justify pretending I was working on cool, unspeakable things that were shrouded in James Bond'esque mystique.
Ultimately I was proud walking in day one and couldn't get out of there fast enough. The people were great, but the management and true colors of the company were centered on, IMO, calculated enrichment of select groups of people. It was never about the best product - it seemed it was about who was next in line to get fed.
The suggestion we sell them to Saudi Arabia is orthogonal to the subject of the article (technical problems). Your post and the article do not, from a naive perspective, have a connection.
My guess is that you think the F-35 project is not a worthwhile investment for the US defense system, but that it cost a lot of money to make, and so we should get some money out of it. Further, since Saudi Arabia has a lot of oil money and wants weapons, we should sell them this plane (which it seems you think is a failure) - even though Saudi Arabia is nominally an ally and it isn't obvious its a good idea to sell an ally weapons we consider bad investments.
My previous paragraph is a just a stab at the thinking that might inform your post - I'm probably totally wrong. Whatever the motivating factors, there's a lot you don't say - either because you don't think it's necessary or you don't want to talk about those background assertions. Obviously, we all believe the people here understand (at least some of) the context, but my guess is that people found your post to not be forthcoming enough.
C++ is unsafe by default and you have to write lots extra checks to make sure your code is bulletproof. Ada is safe by default and you have to be verbose to do powerful-but-dangerous things with pointers.
While yes, you can write secure and fault-tolerant code in any language and insecure and buggy code in any language, the sheer amount of C and C++ software that has been demonstrated to be insecure and very buggy in recent years raises some questions about whether that's the tool we want to use.
Languages are tools. C is a $5 wrench with a blade for a handle. Ada is a pocketknife where you can pull out the wrench or blade if you need it. Both of them can do the same things, but with one you have to be very, very careful to not cut yourself.
The problem wasn't programmer salary, it was that their budget was so big that they wanted to hire extra people and could not find enough Ada programmers. Yup. It got written in C++ because they wanted to spend more money and there are more experienced C++ developers than Ada developers.
Haskell doesn't even have a spec
And Haskell does actually have a spec[1], but almost everyone uses GHC extensions so I suppose that's kind of moot.
1. https://wiki.haskell.org/Language_and_library_specification
No you don't, just use RAII and you cover almost all the safety issues. Put all memory allocations, file openings, mutex locking and other resource acquisition in constructors and the matching cleanup in deconstructors and it becomes very safe. Now, not only is memory cleaned up and exception safe, but several classes of file handling and multi-threading issues are categorically fixed. There are a few other rules to enhance this to the point of preposterous safety, but with just this technique I see fewer memory leaks than I do with some garbage collected languages.
The big safety issues occur when people take the unplanned style of treating C++ as if it were C with Classes. Something that exacerbates this is a plethora of bad training material (mostly old from before C++03) and even university classes that use manual memory allocations outside a constructor (naked new statments), exceptions and manual memory releasing in exception unsafe ways.
I am sure Ada can be used incorrectly, now imagine if in an old standard not all Ada compilers supported the same language features. Imagine the subset of common features was dangerous as hell. Imagine creating a memory structure like a linked list because only some compilers provided one prewritten and some are implementations were missing core language features. However, all the compilers ship with dangerous tools to build it wrong. This was C++ in 1995, and many people who learned it then never unlearned their mistakes.
C++03 laid down a bunch of technical fixes and a minimum benchmark for decent compilers. It could have been used safely with what I described above, but much of the developer community was change averse. Now with C++11 we are changing and really cool things are happening because the developers are treating it like a different language.
I wonder if it meant "The guys who know Ada are all furiously writing F-22 software" -- parenthetical aside, the F-22 was in flight testing and development during the same years that the F-35 project was getting underway, so there would have been high demand for people experienced with developing mission critical flight software -- "and therefore we have to go with the guys we can spare, who mostly know C++ or Java or something". Or did they mean "No one coming out of school knows Ada anymore so let's go with a more widely known language"?
EDIT: But yeah, the major issue (regardless of their preference for engineers over computer scientists) is a general lack of experience in the people they hire [for the domain].