On Saturday, 4 October 2014 at 03:16:08 UTC, ketmar via Digitalmars-d wrote:
> On Fri, 03 Oct 2014 19:25:53 -0700
> Brad Roberts via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> Where's the contradiction?  The compilers state hasn't been corrupted just because it encounters errors in the text file.
> but compiler is in unknown state.

It's not. It just detected that another system would enter in an unknown state if built. The compiler is like the engineer that examines the design of a project and discovers an error on it, so it refuses to build the product. Is the engineer in an unknown state?

No, it is, just like the compiler is, outside its/his/her normal execution flow, wich is "take the design and build the product". It is a known state of the compiler/engineer, namely the error processing path.

While on the error processing path you allow yourself to be slower and take time to guess. This is important. Just as for the engineer, this will educate the designers and will not come again so often with the same design mistake. Then, working/building fast is measured on the normal execution path, not on the error recovery path since the latters is assumed to occur quite rarely (in any case, its seen like an exceptional issue).

Of course, the engineer has to handle the work conflict with the designer in a polite form. For the compiler this means printing a nice error message to the user.

Guessing might not be good, but it is nice effort to do. Do you really miss the super-cryptic C (let's not even talk about C++) error messages that you sometimes receive?

On Sat, 04 Oct 2014 04:10:49 +0000
eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> >> Where's the contradiction?  The compilers state hasn't been corrupted just because it encounters errors in the text file.
> > but compiler is in unknown state.
> It's not. It just detected that another system would enter in an unknown state if built. The compiler is like the engineer that examines the design of a project and discovers an error on it, so it refuses to build the product. Is the engineer in an unknown state?
sorry. i meant that compiler WILL be in unknown state if it will continute to processing invalid source. that's why it should stop right after the first error.

> Guessing might not be good, but it is nice effort to do. Do you really miss the super-cryptic C (let's not even talk about C++) error messages that you sometimes receive?
yes. DMD attempts to 'guess' what identifier i mistyped drives me crazy. just shut up and stop after "unknown identifier", you robot, don't try to show me your artificial idiocity!

On Saturday, 4 October 2014 at 04:26:45 UTC, ketmar via Digitalmars-d wrote:
> On Sat, 04 Oct 2014 04:10:49 +0000
> eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> >> Where's the contradiction?  The compilers state hasn't been corrupted just because it encounters errors in the text file.
>> > but compiler is in unknown state.
>> It's not. It just detected that another system would enter in an unknown state if built. The compiler is like the engineer that examines the design of a project and discovers an error on it, so it refuses to build the product. Is the engineer in an unknown state?
> sorry. i meant that compiler WILL be in unknown state if it will
> continute to processing invalid source. that's why it should stop right
> after the first error.


No. It might produce an invalid product. Just like a real engineer could produce a flawed product on the basis of wrong designs.

Yes, you might reach a state where you are no longer be able to continue because physically impossible. "Build a round square". Both the engineer and the compiler will bark when they see this.

>> Guessing might not be good, but it is nice effort to do. Do you really miss the super-cryptic C (let's not even talk about C++) error messages that you sometimes receive?
> yes. DMD attempts to 'guess' what identifier i mistyped drives me
> crazy. just shut up and stop after "unknown identifier", you robot,
> don't try to show me your artificial idiocity!

Could we add a flag to the compiler for that?

-cassandramode=[yes/no/whatever]

Joke :)

Anyway, the Cassandra name for the compiler is just perfect: it might be right, but you won't believe!

On Sat, 04 Oct 2014 04:36:48 +0000
eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> > sorry. i meant that compiler WILL be in unknown state if it will
> > continute to processing invalid source. that's why it should
> > stop right
> > after the first error.
> No. It might produce an invalid product. Just like a real engineer could produce a flawed product on the basis of wrong designs.
i can't see any sane reason to process garbage data, 'cause result is known to be garbage too.

> Could we add a flag to the compiler for that?
> 
> -cassandramode=[yes/no/whatever]
> 
> Joke :)
but this will be fine. let beginners get suggestions about importing 'std.stdio' on unknown 'writeln', but don't spit that on me. i tend to read compiler messages, and additional noise is annoying.

On Saturday, 4 October 2014 at 05:02:04 UTC, ketmar via Digitalmars-d wrote:
> On Sat, 04 Oct 2014 04:36:48 +0000
> eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> > sorry. i meant that compiler WILL be in unknown state if it will
>> > continute to processing invalid source. that's why it should stop right
>> > after the first error.
>> No. It might produce an invalid product. Just like a real engineer could produce a flawed product on the basis of wrong designs.
> i can't see any sane reason to process garbage data, 'cause result is
> known to be garbage too.

The same reason why a schoolteacher will process garbage exam sheets.

On Friday, 3 October 2014 at 20:31:42 UTC, Paolo Invernizzi wrote:
> On Friday, 3 October 2014 at 18:00:58 UTC, Piotrek wrote:
>> On Friday, 3 October 2014 at 15:43:59 UTC, Sean Kelly wrote:

>
> As one that has read the original report integrally, I think that you have taken a bad example: despite the autopilot was disengaged, the stall alarm ringed a pletora of times.
>
> There's no real alternative to the disengagement of the autopilot is that fundamental parameter is compromised.
>
> It took the captain only a few moment to understand the problem (read the voice-recording transcription), but it was too late...

For the curious, the flight analysis here:

http://www.popularmechanics.com/technology/aviation/crashes/what-really-happened-aboard-air-france-447-6611877

Captain's first error was to leave the cockpit when approaching storm. Second, was to give command to the lower-experienced co-pilots. Not only for quality of the flight, but also for the quality of the team. His third error was to have neglected the fact that the radar was not correctly set up. And his most important (and final) error was to not take commands back while coming back in to the cockpit.

And it was airliner's fault to embark on transatlantic flights just one experienced man and two very low experienced copilots.

This is a beginner mistake:

"the insanity of pulling back on the controls while stalled"

and this passage resumes it quite well:

"the captain of the flight makes no attempt to physically take control of the airplane. Had Dubois done so, he almost certainly would have understood, as a pilot with many hours flying light airplanes, the insanity of pulling back on the controls while stalled"

If you read the analysis you get scared.

On Sat, 04 Oct 2014 05:19:32 +0000
eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> > i can't see any sane reason to process garbage data, 'cause
> > result is
> > known to be garbage too.
> The same reason why a schoolteacher will process garbage exam sheets.
it can be true if DMD will has advanced AI someday -- to clearly understand what programmer wants to write. but then there will be no reason to emit error messages. and to writing code manually too.

On 10/3/2014 8:15 PM, ketmar via Digitalmars-d wrote:
> there is no reason to guess what code programmer meant to write,

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.

On 10/3/2014 4:27 AM, Kagamin wrote:
> Do you interpret airplane safety right? As I understand, airplanes are safe
> exactly because they recover from assert failures and continue operation.

Nope. That's exactly 180 degrees from how it works.

Any airplane system that detects a fault shuts itself down and the backup is engaged. No way in hell is software allowed to continue that asserted.

On 10/3/2014 5:16 AM, Jacob Carlborg wrote:
> I have no idea of airplane works but I think Walter usual says they have at
> least three backup systems. If one system fails, shut it down and switch to the
> backup.

It's a "dual path" system, meaning there's one backup.

Some systems are in triplicate, such as the hydraulic system.