>The fly-by-wire flight software for the Saab Gripen (a lightweight

>fighter) went a step further. It disallowed both subroutine calls and

>backward branches, except for the one at the bottom of the main loop.

>Control flow went forward only. Sometimes one piece of code had to leave

>a note for a later piece telling it what to do, but this worked out well

>for testing: all data was allocated statically, and monitoring those

>variables gave a clear picture of most everything the software was doing.

>The software did only the bare essentials, and of course, they were

>serious about thorough ground testing.

>No bug has ever been found in the "released for flight" versions of that code.

I was pretty excited to learn more about that style, and then I came across...

https://www.flightglobal.com/FlightPDFArchive/1989/1989%20-%...

...but I'd still like to know more about this style of programming, and languages that facilitate programming in that manner.

If I read that article right, it sounds like the software fault attributed to the crash is that the "control laws" that the software implemented were improperly chosen, not that the software did not function as intended.

Which is to say, a serious problem, but if we take "bug" to mean a difference between designed function and realized function, not a "bug", and therefore not something which should tarnish the record of the coding style to which the bug-free nature of the Grippen software is attributed. The problem seems to have been at a different level than coding.

You're correct to point out that the coding style isn't to blame for the software fault. And IMO The last paragraph of the article hints at the most probable fundamental cause.

But I just don't buy that this was not a software fault. It clearly was a case of a faulty software specification.

> The problem seems to have been at a different level than coding.

This makes me queasy. Software engineers working on these sorts of systems -- -- or at least a few senior ones -- should understand enough of the domain to say "this spec is not adequate" or "bad things might happen under conditions xyz; what's the correct behavior in these cases?". And of course all software should notice and then degrade gracefully when assumptions are observably violated.

To absolve the software engineer of any responsibility for understanding the context surrounding his software is to wrongly assume there's not much to software engineering beyond programming to someone else's spec.

I absolutely see it as a software problem and a software engineering problem, just one orthogonal to considerations of the value of the coding style adopted in preventing code that deviated from specifications.

Does anyone know where this quotation comes from?

It's very hard to formulate a clear and easily enforced rule that restricts complexity. No large function is one way to do it.

Really long functions that have very low complexity (very few nested control structures, ideally none) and do not contain any loops that aren't trivial are easy to reason with. They are essentially the one case I'm familiar with where longer is not worse after a point.