I've worked in the defense software industry for over 25 years, and lately I've been thinking about programming languages.
Now first off, the vast majority of defense systems take a long time to develop and deploy. No small part of that is because of what these systems are intended to do, which is to directly or indirectly destroy an opponent's equipment, infrastructure, and people, and prevent their weaponry from doing the same to you.
This is something you want to get right, and so a great deal of care is warranted.
There are perils endemic to a long, drawn-out, (justifiably) risk-averse development process. Such as working with and deploying old technology, requirements creep, bureaucracy, hierarchies of reviews and sign-offs, and expending lots of effort on a multitude of specification and management tasks and documents, far too few of which really have much to do with actually putting a weapon system in the field.
There's a number of issues that could be gone into about this industry and its development practices, but as a software guy, I want to focus on programming, specifically the issue of the succession of defense software implementation languages.
My characterization of programming language succession within the defense software industry from the early 80s to the present is that this industry lags about 10 years or so behind commercial practices. Sure, there are pockets of development that are concurrent with commercial development, but a programming language doesn't achieve widespread use--which means used on major program starts and upgrades--on DOD (Department of Defense) projects until at least ten years after its use is widespread in the commercial software industry. And the defense industry is pretty cocooned when it comes to programming language practices, i.e. for the most part developers and technical leads don't really realize just how far behind they are. (One software architect expressed shock when I told him that Perl was not considered one of the hottest technologies in software development, and the days when it was cool and leading edge to program in Perl were now many years in the past. Another co-worker was equally surprised to hear that Java is now often considered the language you have to program in for work.)
I entered the industry just when the defense industry was trying a new approach, at that time trying to deal with a proliferation of industry and system-specific programming languages (Fortran, JOVIAL, CMS-2, and numerous assembly languages). The Ada programming language was the result of a language competition and it was subsequently mandated for all defense system starts and major upgrades. For a variety of reasons, mostly involving politics, organizational resistance, and greed, the initiative failed. There were a few technical flaws in the language, but it was quite capable of meeting defense software requirements at the time (and did and does so in deployed systems today), but by the time the flaws and the greed were dealt with, the window of opportunity for mainstream acceptance of Ada had passed.
Commercial software development, which was starting to become the driver of computer technology innovation (rather than the military) was driving towards C and then C++ at this time, and with the Commercial Off-The-Shelf "COTS Initiative" and "best industry practices" becoming defense industry focuses, the defense industry began looking to the commercial world for its software development technologies.
By the mid-90s many (but not all :-) defense programmers were becoming disdainful of Ada, and it was not uncommon to hear laments about not being able to have C++ on one's resume.
I had the opportunity in the mid-90s to do a clean-sheet redesign of a poorly-designed and implemented command & control subsystem. It had been implemented in Ada, but the developers were skeptical of the language, and barred the use of features of the language that they didn't understand, sometimes very basic features (like subtyping, for those of you familiar with Ada). I had no such qualms, the team now supporting the system was well-versed in Ada (with only one of the original developers remaining), and so the redesign took advantage of Ada's strengths and capabilities, rather than fearing them.
My biggest obstacles were two system engineers, who were adamant that the reimplementation should be done in C++. One even went so far as to surreptitiously add a slide to my presentation the night before a customer review stating that while we were reimplementing in Ada now, the long term plan was to move to C++. It was not, and I had to explain this in front of the customer, because it was too late to pull the slides. (Still pissed about that? Why yes, I'm soaking in it.) These two were not in my management chain, from whom I had full confidence, but they lobbied the Chief Engineer to try to get him to mandate a language change, to no avail, and to his credit.
The point of this whole little rant of mine on this particular career event is what one of those "engineer's" put forth as a primary justification to use C++:
"C++ is where the market is going."
How silly does that sound today? Yes, there's a lot of C++ around, now mostly considered legacy stuff, and my sense is that young programmers seem to hold C++ with about the same disdain that defense programmers had for Ada in the mid-90s. The market changes, and committing large, long-lived system development to "where the market is going", as if that's where it's going to settle at for all time, is ridiculously naive and short-sighted.
Java is now all the rage in the defense software development industry, and while it is probably still the most widely used programming language for commercial software development, there's definitely the sense that it has passed its prime and has begun to wane in mindshare and interest. The reasons why aren't my point, my point is that it's hot in defense, while outside of that industry Java is now "your father's programming language" from 15 years ago.
I don't know, and that's the part that bothers me about where the defense software industry is heading.
The programming language that's grabbing the commercial industry now I would be expecting to be dominating defense software development in about 10 or 15 years. And, well, first off I don't perceive a dominating candidate yet, and the candidates that I do see lack an aspect I consider fundamental to safety- and mission-critical software systems.
That aspect is an intentional, well thought out, unifying principle, ideally envisioned by an individual or small team of language designers.
Ada was explicitly designed for safety-critical systems and was designed around a "type model". The original version was designed by Jean Ichbiah, and the first and only major revision of the language (Ada 95) was done by Tucker Taft. (Subsequent enhancements are essentially incrementally improving its capabilities.)
C is a "portable assembly language", designed by Kernighan & Ritchie.
While I think C++ is inappropriate for critical software outside of the hands of experts, it was consciously designed by Bjarne Stroustrop as "C with classes".
And I feel that the fundamental feature of James Gosling's Java is that it is designed around the "interface" concept and construct.
I don't get any sense of this kind of intentional, unified, design from the currently up-and-coming languages; they exist to make string handling easier, or programming easier, or Web development easier. That's all great, but is that foundation industrial strength enough that you'd trust it to guide and target a missile moving at Mach 2 that has to take out an incoming nuke?
Like I said at the beginning, I'm concerned. Maybe I'm just being a Luddite here, and VMs and programming language refinements will meet the requirements of the warfighter by the time the defense industry moves past Java.
There's just nothing jumping out at me right now, and given the iconoclasm and cocooning of defense software industry programmers, I am concerned about "where the market is going."