I think I Found and Fixed a bug.

[cjs]

teamtempest wrote:

I suspect NASA would hate my Python code, since I love to use function indirection :-)

It's Python code, so different rules apply. Most of the rules you see in that video are much more to do with dealing the C programming language than to do with safe code in general.

Function indirection, and function composition in general, really helps with code clarity and making sure things work right: consider how hard it is to make an error with map(f, somelist) than with writing a loop yourself. (Essentially, you're re-using "loop" code that's already been written and verified.)

Recursion is also limited due to the nature of C; in other languages you would prefer it because it's easier to verify (both manually and with automated tools) than loops are. Blowing up the stack isn't an issue if you use tail recursion (also easily verified) and your compiler does tail call optimisation.

With a good type system you can even easily make sure code that ignores return values can't compile, have "pointer" values that cannot be null, ensure that all memory you allocate on the heap is freed within a certain boundary, automatically put limits on loops and recursion without it having to be explicit code visible wherever it's used (it's not hard to write a monad in Haskell that does this for you), have list and array lengths type checked at compile time (e.g., writing a function that you can't call with an empty list), and so on.

[BigEd]

Some interesting links on NASA software (specifically the Curiosity rover on Mars) here.

[BigDumbDinosaur]

JenniferDigital wrote:

After all... Who wants to loose a multi-billion pound mission with years of work behind them and jobs on the line over a single bit out of place.

We’ve had airplanes punch a hole in the ground over “a single bit out of place”—if you can believe the lawyers who are suing Boeing over the 737 MAX8 crashes¹ from a number of years ago. I’ve never been a nervous flyer, but I am somewhat uneasy about the degree to which dependence on computer control in modern airliners has arisen. The fine folks at Airbus have had some unfortunate incidents caused by aggressive computer control and questionable programming, with at least one resulting in a fatal crash during an air show.

The reality is if a body of software is large enough, there will be bugs. If the body of software is really large, e.g., of the size of Micro$oft Windows, there will be bugs that will never be found. I write a lot of assembly language and know all-too-well how difficult it can be to track down bugs. It takes disciplined coding habits to keep a lid on the problem, which tends to eventually weed out “lazy” programmers.

————————————————————
¹According to a buddy who flies left seat in 737 MAXs for a major US airline, simulator runs in the “accident configuration” strongly suggested that while the MCAS software did indeed have problems, the planes were manually controllable at all times, as well as 100 percent airworthy, a finding that indirectly faulted the competence of the cockpit crew of the doomed airliners. It’s significant to note that both MAX8 crashes were of “budget” airlines’ planes—no major carriers have had such problems. Disclaimer: I do not work for Boeing, nor do I have Boeing stock.

[cjs]

BigDumbDinosaur wrote:

According to a buddy who flies left seat in 737 MAXs for a major US airline, simulator runs in the “accident configuration” strongly suggested that while the MCAS software did indeed have problems, the planes were manually controllable at all times, as well as 100 percent airworthy, a finding that indirectly faulted the competence of the cockpit crew of the doomed airliners.

That whole incident doesn't really speak to software quality, though, since the main issue was that not only had the pilots not been trained on how to deal with the MCAS, but it was a new system not on previous 737s even the existence of which was deliberately concealed from the pilots. (And it relied on a single sensor even though a backup sensor was available.)

The pilots certainly were not competent to handle the MCAS problem, but that's not the fault of the pilots themselves, but those who designed the system and those who trained the pilots.

Quote:

It takes disciplined coding habits to keep a lid on the problem, which tends to eventually weed out “lazy” programmers.

It does indeed take a fair amount of discipline to keep a lid on the problem, but from decades of experience as a professional software developer, no, I don't find that tends to weed out the "lazy" or less competent developers. In fact, more often than not in my career I've seen them encouraged, and the developers who tried to focus on reliability (or even understanding the software well) discouraged.

[barnacle]

See also MISRA, which takes a similarly dim view of what you can and can't do. Although there are very few absolute prohibitions, there are an awful lot of 'don't do this without a bloody good reason and a written explanation thereof' conditions. And a few outright 'musts', for example, a conditional phrase must be included in braces, and each brace shall have its own line. Structs are OK but Unions are Right Out.

I find it very helpful, if for nothing else than to have a consistent C style.

Neil