On 08/01/2014 05:37 PM, Andrei Alexandrescu wrote:
> On 8/1/14, 8:28 AM, Timon Gehr wrote:
>> On 08/01/2014 01:53 PM, Don wrote:
>>> If you are disabling your asserts, but still believe that they may fail,
>>> that means you're expecting your program to enter undefined behaviour!
>>
>> Nonsense. This claim is ignoring the current reality of software
>> development. One would be expecting one's program to be buggy, but one
>> would still think that _almost all_ assertions pass always and those
>> that don't would be expected to pass _almost always_. How many pieces of
>> non-trivial bug-free software did you write or _were required to work on
>> without full knowledge about the code base_?
>>
>> In any case if one is _disabling_ one's asserts, one doesn't expect them
>> to have any kind of effect whether they may fail or not.
>
> This doesn't ring true at all in the circles I frequent. I'm with Don.
> -- Andrei

It wouldn't ring true in a circle where it is popular to deny one's own imperfection, or the imperfection of one's co-workers. Such an attitude is dangerous. It puts innocent people at risk.

What other circles does it not ring true in?

On Fri, Aug 01, 2014 at 04:08:56PM +0200, Daniel Gibson via Digitalmars-d wrote:
> Am 01.08.2014 05:17, schrieb Walter Bright:
> >
> >Frankly, it never occurred to me that it wasn't obvious. When something is ASSERTED to be true, then it is available to the optimizer. After all, that is what optimizers do - rewrite code into a mathematically equivalent form that is provably the same (but cheaper to compute). Its inputs are things that are known to be true.
> >
> >For example, if a piece of code ASSERTS that x is 3, thereafter the optimizer knows that x must be 3. After all, if the optimizer encounters:
> >
> >    x = 3;
> >
> >do I need to then add a note saying the optimizer can now make use of that fact afterwards? The use of "assert" is a very strong word, it is not "maybe" or "possibly" or "sometimes" or "sort of".
> >
> >When you write:
> >
> >    assert(x == 3);
> >
> >then at that point, if x is not 3, then the program is irretrievably, irredeemably, undeniably broken, and the default action is that the program is terminated.
> >
> >The idea expressed here by more than one that this is not the case in their code is astonishing to me.
> >
> 
> Well, this all sounds sane and makes sense in a way.
> 
> The thing is, I never considered assert() to mean this up to now, which is probably influenced by the following reasons:
> 
> In programming I've always encountered assert() in an "check if
> assertions are enabled/you're in debug mode, do nothing otherwise" way
> (that's what C, C++, Java and Python do).

Whoa. I've never heard this before, but yeah, it explains a lot. :-O

I suppose people have come to associate assert with the way it's implemented in C/C++, and may not have been aware of the rationale behind it. That's kinda scary.


> In unit tests the "checks" are also often called assertions.
[...]

Yes, because if those checks failed, it means your program isn't conforming to the unittests, which means it is horribly broken and must be fixed before it's allowed to reach the customers' hands.

I suppose you could interpret it as, "this unittest asserts that XYZ holds in this part of the program; if it doesn't, it means something is broken in the program logic". So it would be treated as a unittest failure, which aborts the program.


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.

On 8/1/2014 4:53 AM, Don wrote:
> If you're removing all your asserts I'd say you're playing a dangerous game
> already. If an assert would have failed, but execution continued anyway, you're
> in undefined behaviour -- at the very least, you're in a condition that the
> programmer believed could never happen.

Yes. (At the very least, the switch will tell you how much runtime speed the asserts cost you.) Asserts not only can detect programming bugs, they can provide optimizer hints that significantly improve code generation. It's going to be necessary to keep D competitive in high performance computing.


> If you are disabling your asserts, but still believe that they may fail, that
> means you're expecting your program to enter undefined behaviour! That seems to
> be a rather illogical position.

Of course. Don't ask the Godfather to do favors for you if you are unwilling to return the favor :-)


> I think very strongly that we should rename the "-release" switch, especially if
> we do start to make use of asserts. It's going to cause no end of confusion and
> passionate debate.

The name came about as a result of my experience with newbies benchmarking my compilers and publishing the results. They'd spend 2 or 3 seconds scanning the documentation to figure out how to set up the compiler to generate the fastest code. -disableasserts is meaningless to them, and they won't use it, and the compiler would fare poorly. -release speaks to them "faster code", so they use that one.

It's worked out well for that purpose.

I would expect someone who spends more time developing code with the compiler to spend at least a little effort reading the two lines of documentation for -release and understanding that it disables the runtime assert checks.

I agree that the documentation can be improved.


> In one of the 2013 DConf talks a lint tool was discussed that disallowed you
> from you writing a condition that was provably impossible based on 'in' contracts.
> eg:
>
> void foo( int x)
> in{
>     assert(x > 6);
> }
> body {
>      if (x > 2)   // ERROR! This is always true!
>      ...
> }
>
> Which is an interesting approach.

When writing generic code, or any generative code, these situations can come up a lot and be legitimate.


> By definition, any optimisations that are performed on the basis of an assert()
> that could affect control flow, are detectable with 100% accuracy by a lint
> tool. And so, if you wanted to remove all your asserts but were worried about
> this issue, it's detectable at compile time.

You're right, but that means the lint tool would have to replicate the data flow analysis in the optimizer, and would have to account for different DFA as implemented in each D compiler.

On 8/1/2014 3:38 AM, bearophile wrote:
> Yes sorry,

No problemo, we all get a bit hot under the collar sometimes. It's because we care about what we're doing.

On 8/1/2014 7:08 AM, Daniel Gibson wrote:
> I'm not a native speaker..

I couldn't tell - your english is excellent.

(I'm always careful not to read too much subtlety into word choice by non-native speakers. For a classic example, if a native speaker says "fine" it means he strongly disagrees with you. A non-native speaker likely means he thinks you have a great idea!)


> .. but even if I were: words used for constructs/function-names/... in
> programming often don't 100% match their "real" meaning (as used in human
> communication)[1] - why should it be different for assert(), especially when not
> implemented/used like that in many popular programming languages?

Every discipline has its own jargon. For example, what would "sick" mean to a motorhead?

We also had quite a struggle coming up with the name "immutable". Every term we tried seemed inadequate, until we noticed that we were always explaining "XXX means the data is immutable", and realized that "immutable" was what we were after.

Am 01.08.2014 20:50, schrieb Walter Bright:
> On 8/1/2014 7:08 AM, Daniel Gibson wrote:
>> I'm not a native speaker..
>
> I couldn't tell - your english is excellent.
>

Thank you :)

>> .. but even if I were: words used for constructs/function-names/... in
>> programming often don't 100% match their "real" meaning (as used in human
>> communication)[1] - why should it be different for assert(),
>> especially when not
>> implemented/used like that in many popular programming languages?
>
> Every discipline has its own jargon.

Sure, and in programming jargon assert() until now was a runtime check that could be deactivated - even though the "spoken language" word "assert" might imply more.

> For example, what would "sick" mean
> to a motorhead?

You mean "motorhead" like in someone who likes cars or like in the the heavy metal band? :-P
(Non-native speakers probably associate motorhead with the band and often don't know the original meaning)


>
> We also had quite a struggle coming up with the name "immutable". Every
> term we tried seemed inadequate, until we noticed that we were always
> explaining "XXX means the data is immutable", and realized that
> "immutable" was what we were after.
>

Yeah, coming up with terms is hard (I sometimes spend a long time thinking about the right name just for a function!), but if a term already has a meaning in your current context, redefining it should probably be avoided.

Cheers,
Daniel

On Fri, Aug 01, 2014 at 11:50:29AM -0700, Walter Bright via Digitalmars-d wrote:
> On 8/1/2014 7:08 AM, Daniel Gibson wrote:
> >I'm not a native speaker..
> 
> I couldn't tell - your english is excellent.
> 
> (I'm always careful not to read too much subtlety into word choice by non-native speakers. For a classic example, if a native speaker says "fine" it means he strongly disagrees with you. A non-native speaker likely means he thinks you have a great idea!)

My favorite quote along this line:

	A linguistics professor was lecturing to his class one day. "In
	English," he said, "A double negative forms a positive. In some
	languages, though, such as Russian, a double negative is still a
	negative. However, there is no language wherein a double
	positive can form a negative." A voice from the back of the room
	piped up, "Yeah, yeah."

Also, it depends on which regional dialect you speak. On the east side of the Pond, a native speaker saying "fine" means he agrees with you. West of the Pond, it *can* mean disagreement, but it can also mean concession -- it all depends on the intonation. Which, of course, is absent in online textual communications.


> >.. but even if I were: words used for constructs/function-names/... in programming often don't 100% match their "real" meaning (as used in human communication)[1] - why should it be different for assert(), especially when not implemented/used like that in many popular programming languages?
> 
> Every discipline has its own jargon. For example, what would "sick" mean to a motorhead?

Also keep in mind that not everyone knows what a "motorhead" is. Google and Wikipedia (*including* the WP disambiguation page) points to various music bands, but no actual definition for the word!


> We also had quite a struggle coming up with the name "immutable". Every term we tried seemed inadequate, until we noticed that we were always explaining "XXX means the data is immutable", and realized that "immutable" was what we were after.

If only the same amount of care was exercised when the syntax of is-expressions was designed! Oh wait, was it ever *designed*?! ;-)


T

-- 
One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"

On 8/1/2014 12:06 PM, Daniel Gibson wrote:
>> For example, what would "sick" mean
>> to a motorhead?
>
> You mean "motorhead" like in someone who likes cars or like in the the heavy
> metal band? :-P
> (Non-native speakers probably associate motorhead with the band and often don't
> know the original meaning)

"motorhead" as in someone who is happy with his head under the hood of a car working on the engine. (The band name is a reference to using amphetamine.)

"sick" in this case would be a term of high praise for someone's custom hot rod.

On 8/1/2014 12:09 PM, H. S. Teoh via Digitalmars-d wrote:
> 	A linguistics professor was lecturing to his class one day. "In
> 	English," he said, "A double negative forms a positive. In some
> 	languages, though, such as Russian, a double negative is still a
> 	negative. However, there is no language wherein a double
> 	positive can form a negative." A voice from the back of the room
> 	piped up, "Yeah, yeah."

English is quite the merry language with this. (Reversing the meaning of "merry", ho-ho!)

It's also why D doesn't support ! in version, and why I'm a strong advocate of not having negated features.

Of course, D has "no-throw" and "im-mutable". Arggh.

On Fri, Aug 01, 2014 at 01:48:17PM -0700, Walter Bright via Digitalmars-d wrote:
> On 8/1/2014 12:06 PM, Daniel Gibson wrote:
> >>For example, what would "sick" mean to a motorhead?
> >
> >You mean "motorhead" like in someone who likes cars or like in the the heavy metal band? :-P (Non-native speakers probably associate motorhead with the band and often don't know the original meaning)
> 
> "motorhead" as in someone who is happy with his head under the hood of a car working on the engine. (The band name is a reference to using amphetamine.)
> 
> "sick" in this case would be a term of high praise for someone's custom hot rod.

And a "hot rod" in this context means a customized vehicle modified to have high performance, speed, etc., not a stick that has high temperature.  :-D


T

-- 
Век живи - век учись. А дураком помрёшь.