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.
http://www.defenseindustrydaily.com/f22-squadron-shot-down-b...
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++.
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.
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.)
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.
1. It's a very lawyery language, there are very few things the compiler will accept to infer, which makes Ada tedious to read and write.
2. The strange mix of underscores and uppercases that is the normal Ada writing style (I believe Ada identifiers are case-insensitive, code from the 80s tends to be VERY_UPPERCASE_HEAVY while the same code now Tends_To_Be_Strangely_Capitalized) makes my head hurt.
And since this is avionics, they're probably dealing with embedded code (which tends to be even less readable) as well...
And as totalc notes, the OO additions of Ada 95 (if you have access to them) feel very bolted on and unnatural.
Though I can't claim any professional experience, lots of my college education was straight from DoD/Navy expats who wrote military software.
There are lots of firms in the midwest that write this kind of software. John Deere, Lockheed, etc.
The Ada class started in '94 if a timeframe helps
Well not really, but Ada is alive and well in the guise of PL/SQL. You can see it if you look closely, type "desc sys.diana" into any Oracle DB, DIANA is "descriptive intermediate annotated notation for Ada".
