On Sunday, 5 October 2014 at 03:34:31 UTC, Walter Bright wrote:
> On 10/4/2014 2:45 PM, Andrei Alexandrescu wrote:
>> On 10/3/14, 9:26 PM, ketmar via Digitalmars-d wrote:
>>> 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!
>>
>> awesome feature -- Andrei
>
> I agree, I like it very much.

This is a great feature where we lack a really solid IDE experience (which would have intellisense and auto-completion that could be accurate and prevent such errors from occurring in the first place.)  Otherwise it would probably be redundant.

On Saturday, 4 October 2014 at 22:24:08 UTC, Nick Sabalausky wrote:
> And the "specification" itself may have flaws as well, so again, there are NO guarantees here whatsoever. The only thing proofs do in an engineering context is decrease the likelihood of problems, just like any other engineering strategy.

Machine validated proofs guarantee that there are no bugs in the source code for any reasonable definition of "guarantee". There is no reason for having proper asserts left in the code after that.

If the specification the contract is based on is inadequate, then that is not an issue for the contractor. You still implement according to the spec/contract until the contract is changed by the customer.

If an architect didn't follow the requirements of the law when drawing a house, then he cannot blame the carpenter for building the house according to the drawings.

On Sat, 04 Oct 2014 14:45:42 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> On 10/3/14, 9:26 PM, ketmar via Digitalmars-d wrote:
> > 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!
> awesome feature -- Andrei
the only bad thing with this future is that it is useless. a simple typo is not worth of additional noise, and in complex cases feature is not working (i.e. it can't guess method name from another module, especially if it's not imported). all in all this adds noise for nothing. ah, and for some fake coolness.

On Sun, 05 Oct 2014 03:47:31 +0000
Cliff via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> This is a great feature where we lack a really solid IDE experience (which would have intellisense and auto-completion that could be accurate and prevent such errors from occurring in the first place.)  Otherwise it would probably be redundant.
i'm not using IDEs for more than a decade (heh, i'm using mcedit to write code). yet this feature drives me mad: it trashes my terminal with useless garbage output. it was *never* in help, there were no moment when i looked at suggested identifier and thinked: "aha, THAT is the bug!" but virtually each time i see usggestion i'm thinking: "oh, well, i know. 'cmon, why don't you just shut up?!"

it's like colorizing the output, yet colorizing can be turned off, and suggestions can't.

On Sunday, 5 October 2014 at 05:46:56 UTC, ketmar via Digitalmars-d wrote:
> On Sun, 05 Oct 2014 03:47:31 +0000
> Cliff via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> This is a great feature where we lack a really solid IDE experience (which would have intellisense and auto-completion that could be accurate and prevent such errors from occurring in the first place.)  Otherwise it would probably be redundant.
> i'm not using IDEs for more than a decade (heh, i'm using mcedit to
> write code). yet this feature drives me mad: it trashes my terminal
> with useless garbage output. it was *never* in help, there were no
> moment when i looked at suggested identifier and thinked: "aha, THAT is
> the bug!" but virtually each time i see usggestion i'm thinking: "oh,
> well, i know. 'cmon, why don't you just shut up?!"
>
> it's like colorizing the output, yet colorizing can be turned off, and
> suggestions can't.

That you even make the bug at all which triggers the error is an indication the developer workflow you use is fundamentally flawed.  This is something which should be caught much earlier - when you are at the point the typo was made - not after you have committed a change to disk and presented it to the compiler, where your train of thought may be significantly different.

I'd much rather energy be directed at the prevention of mistakes, not the suppression of help in fixing them - if I had to choose.  But I wouldn't object to having a switch to turn off the help if it bothers you that much.  Seems like a very small thing to add.

On 10/4/2014 10:24 PM, Ola Fosheim Grostad wrote:
> On Saturday, 4 October 2014 at 22:24:08 UTC, Nick Sabalausky wrote:
>> And the "specification" itself may have flaws as well, so again, there are NO
>> guarantees here whatsoever. The only thing proofs do in an engineering context
>> is decrease the likelihood of problems, just like any other engineering strategy.
>
> Machine validated proofs guarantee that there are no bugs in the source code for
> any reasonable definition of "guarantee". There is no reason for having proper
> asserts left in the code after that.
>
> If the specification the contract is based on is inadequate, then that is not an
> issue for the contractor. You still implement according to the spec/contract
> until the contract is changed by the customer.
>
> If an architect didn't follow the requirements of the law when drawing a house,
> then he cannot blame the carpenter for building the house according to the
> drawings.

Carpenters can be liable for building things they know are wrong, regardless of what the spec says.

On Sun, 05 Oct 2014 05:55:37 +0000
Cliff via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> That you even make the bug at all which triggers the error is an indication the developer workflow you use is fundamentally flawed.
what we are talking about here? sorry, i'm lost.

>  This is something which should be caught much earlier -
> when you are at the point the typo was made - not after you have
> committed a change to disk and presented it to the compiler,
> where your train of thought may be significantly different.
i'm writing code in big pieces, and fixing typos, etc. then works as a "background thread" in my brain, while "main thread" is still thinking about the overall picture. no IDE helps me to improve this, and i don't need all their tools and their bloat. and i'm not making alot of typos. ;-)

> But I wouldn't object to having a switch to turn off the help if it bothers you that much.  Seems like a very small thing to add.
this is a spin-off ;-) of the actual discussion. what i'm talking about originally is that compiler should stop after first error it encountered, not trying to parse/analyze code further. and there i was talking about IDEs which helps to fix alot of typos and other grammar bugs even before compilation starts.

and what i'm talking about is that trying to make sense from garbage input is not a sign of robust software, if that software is not a special case software which was designed to parse garbage.

and that's why i'm against any "warnings" in compilers: all warnings should be errors.

On Sunday, 5 October 2014 at 06:09:44 UTC, Walter Bright wrote:
> Carpenters can be liable for building things they know are wrong, regardless of what the spec says.

You can be made liable if you don't notify the responsible entity you work for that the solution is unsuitable for the purpose.

How it works in my country is that to raise a building you need a qualified entity that is "responsible for the quality of the construction" which could be an architect, a building engineer or a carpenter with some extra certification. They are responsible for ensuring/approving the overall quality. They are required to ensure the quality of the spec/work and are therefore liable vs the customer.

On Sunday, 5 October 2014 at 06:55:16 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 5 October 2014 at 06:09:44 UTC, Walter Bright wrote:
>> Carpenters can be liable for building things they know are wrong, regardless of what the spec says.
>
> You can be made liable if you don't notify the responsible entity you work for that the solution is unsuitable for the purpose.
>
> How it works in my country is that to raise a building you need a qualified entity that is "responsible for the quality of the construction" which could be an architect, a building engineer or a carpenter with some extra certification. They are responsible for ensuring/approving the overall quality. They are required to ensure the quality of the spec/work and are therefore liable vs the customer.

Oh, I think that here in Italy we outperform your country with that, as for sure we are the most bureaucratised country on the hearth.
So it happens that we have people "responsible for the quality" for pretty everything, from building houses to doing pizzas.
And guess it, here the buildings made by ancient romans are still "up and running", while we have schools building made in the '90 that come down at every earthquake...

Guru meditation... ;-P

---
/Paolo

On Sunday, 5 October 2014 at 09:06:45 UTC, Paolo Invernizzi wrote:
> On Sunday, 5 October 2014 at 06:55:16 UTC, Ola Fosheim Grøstad
>
> Oh, I think that here in Italy we outperform your country with that, as for sure we are the most bureaucratised country on the hearth.

/hearh/earth

I must stop writing while doing breakfast *sigh*

---
/P