[gumby]

Seems risky. I remember the automated train control system for the Vienna Hauptbahnhof (main train station) had an x86 and a SPARC, one programmed in a procedural language and one in a production language. The idea was to make it hard to have the same bug in both systems (which could lead to a false positive in the voting mechanism).

[ThePowerOfFuet]

This is a great technique to avoid common-mode failures.

[kqr]

Do you have data to back that claim up? I remember reading evidence to the contrary, namely that programmers working on the same problem -- even in different environments -- tend to produce roughly the same set of bugs.

The conclusion of that study was that parallel development mainly accomplishes a false sense of security, and most of the additional reliability in those projects came from other sound engineering techniques. But I have lost the reference, so I don't know how much credibility to lend my memory.

[fanf2]

After some searchengineering I found Knight and Leveson (1986) “AN EXPERIMENTAL EVALUATION OF THE ASSUMPTION OF INDEPENDENCE IN MULTI-VERSION PROGRAMMING” which my memory tells me us the classic paper on common failure modes in reliability via N-version software which I was taught about in my undergrad degree http://sunnyday.mit.edu/papers.html#ft

Leveson also wrote the report on Therac 25.

[gumby]

That was the reason for the different programming paradigms (Algol-like vs Prolog-like), to reduce the probability.

[Dah00n]

Isn't this exactly what aeroplanes do? Two or more control systems made in different hardware, etc?

[kqr]

I'm not saying people aren't doing it! I'm just not sure it has the intended effect.

(Also to protect against physical failures it works, because physical failures are more independent than software ones, as far as I understand.)