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.

_________________
Curt J. Sampson - github.com/0cjs

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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.


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.

_________________
Curt J. Sampson - github.com/0cjs

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