Isn't the F35 program considered a failure? Or am I confusing it with some other program?
It freely flies in territory protected by state of the art airdefense made by the country that spreads those claims.
The C++ standard for the F-35 Fighter Jet [video]
161–170 of 451 posts
Re: The C++ standard for the F-35 Fighter Jet [video]
#162a = a; // misra Actual code i have seen with my own eyes. (Not in F-35 code) Its a way to avoid removing an unused parameter from a method. Unused parameters are disallowed, but this is fine? I am sceptical that these coding standards make for good code!
I've (unfortunately) written plenty of "safety critical" code professionally and coding standards definitely have a negative effect overall. The thing keeping planes from falling out of the sky is careful design, which in practice means fail-safes, watchdogs, redundancy, and most-importantly, requirements that aren't overly ambitious.
While maybe 10% of rules are sensible, these sensible rules also tend to be blindingly obvious, or at least table stakes on embedded systems (e.g. don't try to allocate on a system which probably doesn't have a full libc in the first place).
Re: The C++ standard for the F-35 Fighter Jet [video]
#163a = a; // misra Actual code i have seen with my own eyes. (Not in F-35 code) Its a way to avoid removing an unused parameter from a method. Unused parameters are disallowed, but this is fine? I am sceptical that these coding standards make for good code!
Studies have looked at MISRA, I'm not aware of any for the JSF guidelines. For MISRA there's a mix, some of the rules seem to be effective (fewer defects in compliant software), some are the opposite (code which obeys these rules is more likely to have defects) and some were irrelevant. Notably this document is from 2005. So that's after C++ was standardized but before their second bite of that particular cherry and…
The "good" rules are like "don't write off the end of an array", and the bad ones are like "no early returns" or "variable names must not be longer than 6 characters". 95% of the "good" rules are basically just longer ways of saying "don't invoke undefined behavior".
Re: The C++ standard for the F-35 Fighter Jet [video]
#164I wonder if Lockheed Martin has an Electron based future fighter in the works?
Re: The C++ standard for the F-35 Fighter Jet [video]
#165Earlier quoted context omitted.
Depends on the company in my experience. I've seen some suppliers that basically just wire up the diagram in Matlab/simulink and hit Autocode. No humans actually touch the C that comes out. Honestly I think that's probably the correct way to write high reliability code.
You’re joking right? That autogenerated code is generally garbage and spaghetti code. It was probably the reason for Toyotas unintended acceleration glitch.
This isn't necessarily a problem if you don't consider the output to be "source" code. Assembly is also garbage spaghetti code but that doesn't stop you from using a compiler does it?
Re: The C++ standard for the F-35 Fighter Jet [video]
#166Earlier quoted context omitted.
No I'm not joking at all. The Autocode feature generates code that has high fidelity to the model in simulink, and is immensely more reliable than a human. It is impossible for a simulink model to accidentally type `i > 0` when they meant `i >= 0`, for example. Any human who tells you they have not made this mistake is a liar. Unless there was a second uncommanded acceleration problem with Toyotas, my understanding i…
> It is impossible for a simulink model to accidentally type `i > 0` when they meant `i >= 0` The Simulink Coder tool is a piece of software. It is designed and implemented by humans. It will have bugs. Autogenerated code is different from human written code. It hits soft spots in the C/C++ compilers. For example, autogenerated code can have really huge switch statements. You know, larger than the 15-bit branch offse…
>But it's not 100% bug free either.
Nobody said it was bug free, and this is a straw man argument of your own construction.
Using Autocode completely eliminates certain types of errors that human C programmers have continued to make for more than half a century.
Re: The C++ standard for the F-35 Fighter Jet [video]
#167For those interested, the F-35 (née Joint Strike Fighter) C++ coding standards can be found here, all 142 pages of it: https://www.stroustrup.com/JSF-AV-rules.pdf
As is common in hard real time code, there is no dynamic allocation during operation: allocation/deallocation from/to the free store (heap) shall not occur after initialization. This works fine when the problem is roughly constant, as it was in, say, 2005. But what do things look like in modern AI-guided drones?
"AI" comes in various flavors. It could be a expert system, a decision forest, a CNN, a Transformer, etc. In most inference scenarios the model is fixed, the input/output shapes are pre-defined and actions are prescribed. So it's not that dynamic after all.
Re: The C++ standard for the F-35 Fighter Jet [video]
#168Re: The C++ standard for the F-35 Fighter Jet [video]
#169Isn't the F35 program considered a failure? Or am I confusing it with some other program?
You’re confusing clickbait articles with reality.
There have been over 1,200 F-35s built so far, with new ones being built at a rate of about 150 per year. For comparison, that’s nearly as many F-35s built per year as F-22s were built ever, and 1,200 is a large amount for a modern jet fighter. The extremely successful F-15 has seen about that many built since it first entered production over 50 years ago.
That doesn’t mean it must be good, but it’s a strong indicator. Especially since the US isn’t the only customer. Many other countries want it too. Some are shying away from it now, but only for political reasons because the US is no longer seen as a reliable supplier.
In terms of actual capabilities, it’s the best fighter jet out there save for the F-22, which was far more expensive and is no longer being made. It’s relatively cheap, comparable in cost to alternatives like the Gripen or Rafale while being much more capable.
There have been a lot of articles out there about how terrible it is. These fall into a few different categories:
* Reasonable critiques of its high development costs, overruns, and delays, baselessly extrapolated to “it’s bad.”
* Teething problems extrapolated to “it’s terrible” as if these things never get fixed.
* Analyses of outcomes from exercises that misunderstand the purpose and design of exercises. You might see that, say, an F-35 lost against an F-16 in some mock fights. But they’re not going to set up a lot of exercises where the F-35 and F-16 have a realistic engagement. The result of such an exercise would be that the F-16 gets shot out of the sky without ever knowing the F-35 was there. This is uninformative and a waste of time and money. So such a matchup will be done with restrictions that actually make it useful. This might end up in a dogfight, where the F-16 is legitimately superior. This then gets reported as “F-35 worse than F-16,” ignoring the fact that a real situation would have the F-35 victorious long before a dogfight could occur.
* Completely legitimate arguments that fighter jets are last century’s weapons, that drones and missiles are the future, and the F-35 is like the most advanced battleship in 1941: useful, powerful, but rapidly becoming obsolete. This may be true, but if it is, it only means the F-35 wasn’t the right thing to focus on, not that it’s a failure. The aircraft carrier was the decisive weapon of the Pacific war but that didn’t make the Iowa class battleships a failure.
Re: The C++ standard for the F-35 Fighter Jet [video]
#170Earlier quoted context omitted.
For control systems like avionics it either passes the suite of tests for certification, or it doesn't. Whether a human could write code that uses less memory is simply not important. In the event the autocode isn't performant enough to run on the box you just spec a faster chip or more memory.
I’m sorry, but I disagree. Building these real-time safety-critical systems is what I do for a living. Once the system is designed and hardware is selected, I agree that if the required tasks fit in the hardware, it’s good to go — there’s no bonus points for leaving memory empty. But the sizing of the system, and even the decomposition of the system to multiple ECUs and the level of integration, depends on how effici…
>And there are step functions here — even a decade ago it wasn’t possible to get safety processors with sufficient performance for eVTOL control loops (there’s no “just spec a faster chip”)
The idea that processors from the last decade were slower than those available today isn't a novel or interesting revelation.
All that means is that 10 years ago you had to rely on humans to write the code that today can be done more safely with auto generation.
50+ years of off by ones and use after frees should have disabused us of the hubristic notion that humans can write safe code. We demonstrably can't.
In any other problem domain, if our bodies can't do something we use a tool. This is why we invented axes, screwdrivers, and forklifts.
But for some reason in software there are people who, despite all evidence to the contrary, cling to the absurd notion that people can write safe code.