On Saturday, 4 October 2014 at 08:28:40 UTC, Walter Bright wrote:
> On 10/3/2014 11:00 AM, Piotrek wrote:
>> http://en.wikipedia.org/wiki/Air_France_Flight_447
>>
>> I just pick some interesting statements (there are other factors described as
>> well):
>
> The overriding failure in that accident was the pilot panicked and persistently did the wrong thing, the opposite of what every pilot is relentlessly trained to do.

One point that the report stressed: when the co-pilots pulled back repeatedly the joystick to raise the plane, the second one could not see that action, as the two joystick are not connected, and they are not moving in sync in the airbus.

Basically, the info-path regarding the joystick between two disconnected systems (the co-pilots) is cut in modern plane, so it's more difficult to check if their "output" (push/pull/etc) is coherent at the end.

That, in my opinion, was the biggest problem in that tragedy.
---
/Paolo

On 9/29/2014 8:13 AM, Steven Schveighoffer wrote:
> I can think of cases where it's programmer error, and cases where it's
> user error.

More carefully design the interfaces if programmer error and input error are conflated.

On 9/28/2014 11:08 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> It does not have to be known, it is sufficient that it is isolated or that it is
> improbable to be global or that it is of low impact to long term integrity.

You cannot make such presumptions and then pretend you've written robust software.


> By your line of reasoning no software should ever be shipped, without a formal
> proof, because they most certainly will be buggy and contain unspecified
> undetected state.

You're utterly misunderstanding my point. Perhaps this will help:

http://www.drdobbs.com/architecture-and-design/safe-systems-from-unreliable-parts/228701716

On Sat, 04 Oct 2014 08:26:53 +0000
Paolo Invernizzi via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I think that there's a big confusion about terms: there's nothing unknown in the parser state when it reach an error in the grammar.
just like nothing unknown in program state when it gets garbage input. yet there is no sense in processing garbage input to produce garbage output. the best thing the program can do is to complain and shut down (if this is not a special recovery program which tries to get all possible bits of info).

On 9/29/2014 12:09 PM, Sean Kelly wrote:
> I'm not saying the errors should be ignored, but rather that
> there are other approaches to handling errors besides (or in
> addition to) terminating the process.

Those "other methods" are not robust and are not acceptable for a system claiming to be robust.


>> Remember the Apollo 11 lunar landing, when the descent computer software
>> started showing self-detected faults? Armstrong turned it off and landed
>> manually. He wasn't going to bet his ass that the faults could be ignored. You
>> and I wouldn't, either.
>
> And this is great if there's a human available to take over.  But
> what if this were a space probe?

A space probe would have either:

1. an independent backup system.

   -- or --

2. a "can't fail" system that fails and the probe will be lost


http://www.drdobbs.com/architecture-and-design/safe-systems-from-unreliable-parts/228701716


Any system designed around software that "cannot fail" is doomed from the start. You cannot write such software, and nobody else can, either. Attempting to do so will only reap expensive and bitter lessons :-(

On 10/1/2014 7:17 AM, Bruno Medeiros wrote:
> Sean, I fully agree with the points you have been making so far.
> But if Walter is fixated on thinking that all the practical uses of D will be
> critical systems, or simple (ie, single-use, non-interactive) command-line
> applications, it will be hard for him to comprehend the whole point that "simply
> aborting on error is too brittle in some cases".

Airplane avionics systems all abort on error, yet the airplanes don't fall out of the sky.

I've explained why and how this works many times, here it is again:

http://www.drdobbs.com/architecture-and-design/safe-systems-from-unreliable-parts/228701716

On 10/1/2014 7:32 AM, bearophile wrote:
> Bruno Medeiros:
>
>> But if Walter is fixated on thinking that all the practical uses of D will be
>> critical systems, or simple (ie, single-use, non-interactive) command-line
>> applications,
>
> There's still some of way to go for D design to make it well fit for high
> integrity systems (some people even use a restricted subset of C for such
> purposes, but it's a bad language for it).


No matter what language is used, a high integrity system cannot be constructed from continuing after the program has entered an unknown state.

On 10/3/2014 10:38 AM, Brad Roberts via Digitalmars-d wrote:
> The part of Walter's point that is either deliberately overlooked or somewhat
> misunderstood here is the notion of a fault domain.  In a typical unix or
> windows based environment, it's a process.  A fault within the process yields
> the aborting of the process but not all processes.  Erlang introduces within
> it's execution model a concept of a process within the higher level notion of
> the os level process.  Within the erlang runtime it's individual processes run
> independently and can each fail independently.  The erlang runtime guarantees a
> higher level of separation than a typical threaded java or c++ application.  An
> error within the erlang runtime itself would justifiably cause the entire system
> to be halted.  Just as within an airplane, to use Walter's favorite analogy, the
> seat entertainment system is physically and logically separated from flight
> control systems thus a fault within the former has no impact on the latter.
>
> So, where you have domains which must not impact each other, you reach for tools
> that allow complete separation such that faults within one CANNOT impact the
> other.  You don't leave room for 'might not'.

Thanks, Brad, that is a correct formulation.

On Saturday, 4 October 2014 at 08:15:51 UTC, Walter Bright wrote:
> On 10/3/2014 8:43 AM, Sean Kelly wrote:

> In NO CASE does avionics software do anything after an assert but get shut down and physically isolated from what it controls.
>
> I've explained this over and over. It baffles me how twisted up this simple concept becomes when repeated back to me.

AFAICT, you hold the righ idea. Either the discussion fellows argue about a different thing and this is a communication problem, either they are on a wrong path.

Once an inconsistency in its own state is detected, any program quits guessing, and shuts down, sometimes with a minimal logging (if not harmless).

An inconsistency is when a software or a system finds intself in a situation for which it wasn't designed to face. It simply breaks the ultimat variants of all that any critical program makes. This invariant is: "I know what I'm doing."

Yes, a software might detect inconsistencies in the rest of the system and try to correct those *if it is designed (read: if it is made to know) what is doing. Majority voting, for example, is such case, but there the basic hypothesis is that sensors are not 100% reliable. And, sometimes, even the majority voting is directly wired.

But, a critical software (and, for the general case, any software) only goes as far as it (believes) that it knows what's doing. When this is not the case, it does not continue, it stops immediately.

On Saturday, 4 October 2014 at 08:15:57 UTC, ketmar via Digitalmars-d wrote:
> On Sat, 04 Oct 2014 01:06:14 -0700
> Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> It doesn't do that anymore (at least mostly not). The compiler only
>> continues to issue error messages for code that is not dependent on
>> the code that caused an error message.
> but first it trues to guess what to skip to "get in sync" again. that's
> exactly the guessing i'm against. got error? stop parsing/analyzing and
> die.

The compiler or the parser is not guessing "what I should do", but "what the user wanted to do". They are very different things. The parser itself is as sound as ever. It is on its user input error processing path but, hey, it was designed to do that. It knows what it is doing.