[erlang-questions] let it crash erlang/ada [[was: Time for OTP to be Renamed?]
Mon Feb 17 13:29:18 CET 2014
Jesper Louis Andersen wrote:
> On Sun, Feb 16, 2014 at 10:11 PM, Miles Fidelman
> < <mailto:>> wrote:
> Good point. "Let it crash" does take on a whole different meaning
> when dealing with aircraft and such.
> This is a different point as well! You have two axis:
> * soft vs hard realtime. Some systems require hard realtime and then
> your tools are limited to languages where you have explicit memory
> control, enabling you to avoid allocating memory and triggering
> garbage collection. In soft realtime systems, you have more leeway,
> and if built the way of the Erlang runtime system, you get really good
> soft realtime capability.
> * Proactive vs Reactive error handling. The idea of "let it crash" is
> definitively reactive, whereas static type systems, proofs, model
> checking, etc are means of proactive error handling.
> My claim however, is that you need "Let it crash" in Aircrafts as well
> if you want to have a stable aircraft. The model where you blindly
> attempt to eradicate every error from a program is bound to fail
> sooner or later. Usually "let it crash" in those situations is
> implemented in hardware by having multiple redundant systems. But
> rarely are systems exempt of failure. Even in a highly controlled
We've really strayed off-topic here, but....
My all-time favorite design for seriously mission-critical systems was
the flight control system for the Space Shuttle. I'm not sure this is
true of the later versions, but originally:
- the flight control software ran on 5 parallel computers, that voted on
- 4 of the computers came from one contractor (hardware and software)
- the 5th machine, just ran mission-critical code, with a completely
separate design (both hardware and software)
- I don't remember how the tie-breaking algorithm worked
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
More information about the erlang-questions