It's likely worth noting that the shuttle has a famously robust computer system. The Challenger was related to an engineering flaw in the mechanical design of the system.
I forget my source, but IIRC the computer system actually noticed the pressure drop from the fuel lines (what with the exploding) and started the shutdown process, spinning down the turbos before the system was forcefully disassembled. Takes a while to turn off the turbos; a few hundred milliseconds really isn't enough time...
The flaw of the O-rings was known, but the risk was considered acceptable by management.
This is specifically why I couched my answer in terms of risk. This was not specifically about the computer system, this was about the mis-assessment of risk.
The article isn't saying that letting errors happen is the best way to go about things in all cases. There is certainly room for proof and extreme caution!
That said, you do not need to prove everything about your algorithm. I imagine that in the future, we'll write software with base runtime system that has some basic sanity properties (proved) and on top of that, there will be layer that handles things in a more flexible way. Kind of like having Challenger JVM which is provably correct and never crashes and lots of apps on top of that :-)
I suspect as Moore's law runs out we will see a rise in speculative computing, where we write our code to work off of fast estimates of slow calculations (ie, detectable mistakes), and then double-check the work before committing the answer at the end.
Video games already do something like this to hide latency in multi-player scenarios. A generalized solution would be interesting, although given our track record with shared state concurrency, it may prove too confusing for the average dev.
6 comments
[ 2.7 ms ] story [ 67.1 ms ] threadEveryone has to evaluate the risk of the errors and act accordingly.
I forget my source, but IIRC the computer system actually noticed the pressure drop from the fuel lines (what with the exploding) and started the shutdown process, spinning down the turbos before the system was forcefully disassembled. Takes a while to turn off the turbos; a few hundred milliseconds really isn't enough time...
[0] Obligatory link to the Feynman report
http://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_...
[1] A cool article on the software running the shuttle
http://www.fastcompany.com/28121/they-write-right-stuff
This is specifically why I couched my answer in terms of risk. This was not specifically about the computer system, this was about the mis-assessment of risk.
That said, you do not need to prove everything about your algorithm. I imagine that in the future, we'll write software with base runtime system that has some basic sanity properties (proved) and on top of that, there will be layer that handles things in a more flexible way. Kind of like having Challenger JVM which is provably correct and never crashes and lots of apps on top of that :-)
Video games already do something like this to hide latency in multi-player scenarios. A generalized solution would be interesting, although given our track record with shared state concurrency, it may prove too confusing for the average dev.