August 03, 2014
Am 04.08.2014 00:15, schrieb Andrei Alexandrescu:
>
> That said, should we proceed carefully about realizing this advantage?
> Of course; that's a given. But I think it's very important to fully
> understand the advantages of gaining an edge over the competition.
>

Gaining an edge over the competition?

"A new DMD release broke my code in a totally unexpected way and people tell me it's because I'm using assert() wrong.
I've been using it like this in C/C++/Java/Python and D since forever and *now*, after >10years, they changed D's meaning of assert() to somehow imply assume() and optimize my safety-checks away.. they pretend it was always planned like this but they never got around to tell anyone until recently.
It took me a week to find this freaking bug!"

Doesn't really sound like the kind of advantage over the competition that many people would appreciate.

If some rant like this (from Reddit or whatever) is the first impression someone gets of D, he's unlikely to ever take a closer look, regardless of the many merits the language actually has.

(Yes, Johhannes Pfau actually brought a similar  argument somewhere in the depth of one of the other threads)

D could still get this kind of edge over the competition by doing these kind of optimizations when another keyword (like assume()) is used - without breaking any code.

Cheers,
Daniel
August 03, 2014
04-Aug-2014 02:35, Daniel Gibson пишет:
> Am 04.08.2014 00:15, schrieb Andrei Alexandrescu:
>>
>> That said, should we proceed carefully about realizing this advantage?
>> Of course; that's a given. But I think it's very important to fully
>> understand the advantages of gaining an edge over the competition.
>>
>
> Gaining an edge over the competition?
>
> "A new DMD release broke my code in a totally unexpected way and people
> tell me it's because I'm using assert() wrong.
> I've been using it like this in C/C++/Java/Python and D since forever
> and *now*, after >10years, they changed D's meaning of assert() to
> somehow imply assume() and optimize my safety-checks away.. they pretend
> it was always planned like this but they never got around to tell anyone
> until recently.
> It took me a week to find this freaking bug!"

Wait a sec - it's not any better even today, it already strips them away. So unless debugging "-release -O -inline" programs is considered a norm nothing changes.



-- 
Dmitry Olshansky
August 03, 2014
Am 04.08.2014 00:45, schrieb Dmitry Olshansky:
> 04-Aug-2014 02:35, Daniel Gibson пишет:
>> Am 04.08.2014 00:15, schrieb Andrei Alexandrescu:
>>>
>>> That said, should we proceed carefully about realizing this advantage?
>>> Of course; that's a given. But I think it's very important to fully
>>> understand the advantages of gaining an edge over the competition.
>>>
>>
>> Gaining an edge over the competition?
>>
>> "A new DMD release broke my code in a totally unexpected way and people
>> tell me it's because I'm using assert() wrong.
>> I've been using it like this in C/C++/Java/Python and D since forever
>> and *now*, after >10years, they changed D's meaning of assert() to
>> somehow imply assume() and optimize my safety-checks away.. they pretend
>> it was always planned like this but they never got around to tell anyone
>> until recently.
>> It took me a week to find this freaking bug!"
>
> Wait a sec - it's not any better even today, it already strips them
> away. So unless debugging "-release -O -inline" programs is considered a
> norm nothing changes.
>

It strips them away, but it doesn't eliminate other code based on the (removed) assertion. See my other post for an example.

August 03, 2014
On Sunday, 3 August 2014 at 22:19:16 UTC, Ola Fosheim Grøstad wrote:

> But go ahead. This will lead to a fork.

What should fork is the two opposing intentions for assert.

They should have two different names and different consequences.

On Sunday, 3 August 2014 at 22:18:29 UTC, John Carter wrote:

> It comes down to two opposing view of what we use asserts for.


To give a more concrete example of this... in the team I work with we have the following issue.

When the DbC type programmers turn "asserts are fatal" on, we get asserts firing all over the place in non-DbC programmers code.

On closer inspection these come down to things like "stupid factory didn't connect cable A to device B, the installation instructions are clear, the cable always should be attached in the production model".

And the solution is one of...
 * Find a Device B and plug cable A into it.
 * There is a bug somewhere in the firmware.
 * There is a bug in the firmware of device B
 * You have a debugger in the entrails of device B, so the heartbeat stopped.
 * Something somewhere increased the latency so the timeout fired, maybe increase timeout..

Whereas for DbC programmers a pre-condition assert firing meant _very_ directly that the function that _directly_ invoked me is clearly defective in this manner. The bug is undoubtably there, there may be a bug elsewhere as well, but it is undoubtably a bug in my calling routine if it let defective values propagate as far as me.

Or if a postcondition assert fired, it means, _this_ function is defective in this manner.

The simple harsh fact is DbC type programmers mean completely different things to non DbC type programmers by "assert", yet unfortunately it is mapped on to the same thing with the same name.

The obvious simple correct resolution is to give them two different names.
August 03, 2014
On Sunday, 3 August 2014 at 22:18:29 UTC, John Carter wrote:
> My view, which I think corresponds with Walter's and Betrand Meyer's, is that asserts define what correct behaviour is.

No. The propositions describe what the correct behaviour ought to be. The asserts request them to be proved.

> And the sooner you know that, preferably at compile time, the better.

And to do that you need a theorem prover capable of solving NP-Hard problems. So you need a veeeery intelligent programmer to write provably correct code without any special tools.

> Continuing past such an assert inevitably results in defective, possibly catastrophic, possibly flaky behaviour.

And Walter thinks it would a great idea to make that catastrophic behaviour occur with a much greater probability and also every time you execute your program, undetected, not only in the select few cases where slight overlap in conditions were detected.

So basically if your program contains an assert that states that the program should stop working in 30 years from now, it is a good idea to make it fail randomly right away. That's the view that Andrei, Don and Walter has expressed very explicitly.

People who thinks this is a great idea defies reason. They only learn from failure.

You have to realize that a deduction engine cannot tolerate a single contradiction in axioms. If there is a single contradiction it can basically deduce anything, possibly undetected.

Turning asserts in program+libaries into globally available axioms is insane.

August 03, 2014
On 08/04/2014 12:15 AM, Andrei Alexandrescu wrote:
>> I suspect it is one of those ideas of Walter's that has consequences
>> that reach further than anyone foresees..... but that's OK, because it
>> is fundamentally the correct course of action, it's implications
>> foreseen and unforeseen will be correct.
>
> Agreed.

No, please hold on. Walter is not a supernatural being.

>
> Walter has always meant assert the way he discusses it today.

This argument has no merit. Please stop bringing it up.

>
> That said, should we proceed carefully about realizing this advantage? Of course; that's a given.

That is reasonable.

>But I think it's very important to fully understand
> the advantages of gaining an edge over the competition.

Note that this is achievable without claiming the Humpty Dumpty privilege once again. Furthermore the potential for the development of concepts is actually usually larger if concepts stay properly separated from the beginning.

E.g. the current proposal already has the issue that an assumption of unreachability cannot be expressed in the straightforward way:

switch(x){
    // ...
    default:
        assert(0); // cannot be optimized away in -release
}
August 03, 2014
On 08/04/2014 12:51 AM, John Carter wrote:
> On Sunday, 3 August 2014 at 22:19:16 UTC, Ola Fosheim Grøstad wrote:
>
>> But go ahead. This will lead to a fork.
>
> What should fork is the two opposing intentions for assert.
>
> They should have two different names and different consequences.

Yes. :)
August 03, 2014
On Sunday, 3 August 2014 at 22:51:58 UTC, John Carter wrote:
> The obvious simple correct resolution is to give them two different names.

Agreed, but it remains to see if those in favor of the original proposal will agree also.
August 03, 2014
On Sunday, 3 August 2014 at 22:57:24 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 3 August 2014 at 22:18:29 UTC, John Carter wrote:
>> My view, which I think corresponds with Walter's and Betrand Meyer's, is that asserts define what correct behaviour is.
>
> No. The propositions describe what the correct behaviour ought to be. The asserts request them to be proved.
>
>> And the sooner you know that, preferably at compile time, the better.
>
> And to do that you need a theorem prover capable of solving NP-Hard problems. So you need a veeeery intelligent programmer to write provably correct code without any special tools.
>
>> Continuing past such an assert inevitably results in defective, possibly catastrophic, possibly flaky behaviour.
>
> And Walter thinks it would a great idea to make that catastrophic behaviour occur with a much greater probability and also every time you execute your program, undetected, not only in the select few cases where slight overlap in conditions were detected.
>
> So basically if your program contains an assert that states that the program should stop working in 30 years from now, it is a good idea to make it fail randomly right away. That's the view that Andrei, Don and Walter has expressed very explicitly.
>
> People who thinks this is a great idea defies reason. They only learn from failure.
>
> You have to realize that a deduction engine cannot tolerate a single contradiction in axioms. If there is a single contradiction it can basically deduce anything, possibly undetected.
>
> Turning asserts in program+libaries into globally available axioms is insane.

John proposes a separate function, so I think you two are in agreement on what really matters. Let's try to avoid going too deep into tangents, unlike the other threads - it didn't work well last time.
August 03, 2014
On 3.8.2014 21:47, David Bregman wrote:
> Walter has proposed a change to D's assert function as follows [1]: "The compiler can make use of assert expressions to improve optimization, even in -release mode."

Couldn't this new assert behaviour be introduced as a new optimization switch ? Say -Oassert ? It would be off by default and would work both in debug and release mode.

-- 
mk