Hacker News Reader

Comment by outworlder | Hacker News Reader

> Much of the F-35's software is written in C and C++ due to programmer availability

This sounds ridiculous. Surely it would be very easy to get as many programmers as they wanted for whatever tech they need with the 1 trillion USD that they have.

It would be fine if C++ was the best tool for the job, but I suspect it isn't. If it is not the best tool for the job, then whatever is gained in "programmer availability" is lost in productivity, correctness, reliability or whatever metric a fighter jet's software development is measured against.

Furthermore, this whole IT industry fetish with hiring for a particular programming language is completely misguided. Domain knowledge is usually the bottleneck. I'd expect that to be even more so in flight or sensor software.

View on HN

> Surely it would be very easy to get as many programmers as they wanted for whatever tech they need with the 1 trillion USD that they have.

That's not the experience of very wealthy Silicon Valley companies, who not only can pay much better than government defense contractors, but offer other incredible perks - yet still can't get all the talent they need.

They have strict coding standards and only (are supposed to) use a subset: http://www.stroustrup.com/JSF-AV-rules.pdf

The $1T didn't go to the programmers. The places are inherently body shops. Domain knowledge is the purview of "systems engineers" or "architects". Hilarity ensues.

The use of C++ is a (non)reaction to the explosion of pet language systems. It got coded into whatever documentation was in process at the time, and probably cannot be changed.

C++ is likely the best bet for this kind of thing. Or rather, a strict subset of C++.

You want real time, you want a minimal OS and you probably want some of the nicer type capabilities over c.

>strict subset of C++

http://www.stroustrup.com/JSF-AV-rules.pdf

Here's the link that gets posted in all of these conversations. A strict subset of C++ is exactly what's been used.

It depends muchly. In general, I'd rather have a seasoned set of 'C' programmers rather than people who are unconcerned with what happens at the level of the metal.

But that's probably a personal bias, one that's been hard-earned. It's a way of leveraging the decades of mistakes made by those folks - and aid for by previous employers.

A "'C' with classes" approach is probably a good one - but I'd hate to find some subtle template or Boost bug in mid flight...

This is all IMO, but an approach like Bruce Powell Douglass "Doing Hard Time' is a pretty good way to satisfy the "systems engineer" customers for UML charts and still have rigorous development.

UML is quite the anti-pattern and Rose is kind of awful but this should be a compromise that can work. CASE tools have gone out of fashion.

> A "'C' with classes" approach is probably a good one - but I'd hate to find some subtle template or Boost bug in mid flight...

I'm not sure how much benefit that would bring, especially since dynamic dispatch is probably not encouraged. As for templates I'm not much of a c++ guy but wouldn't most template errors exist at compile time?

Templates are mostly problems at compile time, but it's also possible to have subtle issues with complicated template specializations where it doesn't call the function you expect. So complicated usages are discouraged, BUT simple ones that give code reuse with strong typing are great advantages over c in most cases.

I think dynamic dispatch would be more permissible than you might think. You end up doing it in c manually in complicated code bases, might as well let the compiler dou the heavy lifting.

I'm not thinking of any specific pathology. It's just been my experience that with templates, there is always some risk of harder to catch errors. If it's explicit in 'C'/C++ , its just explicit and nobody's making any assumptions.

Reply on news.ycombinator.com