On Saturday, 16 July 2016 at 06:40:31 UTC, Walter Bright wrote:

> But in C++, everything is @system. I'm not sure how people successfully create enormous programs with it.

I work on Microsoft Word. I'm not sure how much I can share about internal verification tools, but I can say: We do have SAL annotation: https://msdn.microsoft.com/en-us/library/ms235402.aspx

As solutions go, SAL is dissatisfyingly incomplete, and not an easy mini-language to learn (I still haven't managed it, I look up what I need on the occasions that I need it). But it does impress at times with what it can catch. It goes a bit beyond memory safety, too, so I would guess that there are bug patterns it can catch that D currently won't.

One class of bug I find interesting here is uninitialized variables. I'm not sure if Visual Studio helps here (we have an internal tool, I know some 3rd party tools do this too). But it's interesting that these tools can (often, not always) spot code paths where a variable doesn't get initialized. D's approach to this helps strongly to avoid using uninitialized memory, but in so doing, it discards the information these tools are using to spot such bugs. (So, the kind of bug D lets slip through here would tend to be one where variable foo's value is foo.init but it should have been initialized to some other value).

On Saturday, 16 July 2016 at 07:14:03 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 14 July 2016 at 23:38:17 UTC, Walter Bright wrote:
>> On 7/14/2016 6:26 AM, Chris wrote:
>>> Now, now. Where's your sense of humor?
>>
>> The thing is, he's just here to troll us. His posts all follow the same pattern of relentlessly finding nothing good whatsoever in D, and we're all idiots.
>
> Whoah, that's sensitive. Never called anyone an idiot, but D zealots seem to have a very low threshold for calling everyone else with a little bit of experience idiots if they see room for change in the language. The excesses of broken argumentation in this newsgroup is keeping change from coming to the language.
>
> It is apparent by now that you and Andrei quite often produce smog screens to cover your trails of broken argument chains, which only serve to defend status quo and not really lead to the language to a competitive position. And no, you are not right just because you declare it, and no if you loose an argument it is not because someone changed the topic.
>
> The sad part about D is that it could've become a major player, but is very unlikely to become one without outside help and less hostile attitude towards rather basic CS. But outside help is not really wanted. Because apparently D can become a major player by 2020 without a cleanup according to you and Andrei.
>
> It is highly unlikely for D to become a major player without language cleanup and opening more up to outside input.

I didn't see anyone call you an idiot either. You and Walter have both gone too far, probably because you're annoyed at each other's words and attitude:

Walter called Prolog "singularly useless". You have been referring to changes that would amount to a new major version of D as "a cleanup". From the forums, my sense is that there IS a groundswell of opinion, that D2 has some major mistakes in it that can't be rectified without doing a D3, and there's a strong reaction to that idea based on experience with D1 -> D2. Perhaps what is needed is a separate area for discussion about ideas that would require a major version change. The thing about that is that it can't be done incrementally; it's the rare kind of thing that would need to be planned long in advance, and would have to amount to a huge improvement to justify even considering it.

On 7/16/2016 6:09 AM, Andrew Godfrey wrote:
> Walter called Prolog "singularly useless". You have been referring to changes
> that would amount to a new major version of D as "a cleanup". From the forums,
> my sense is that there IS a groundswell of opinion, that D2 has some major
> mistakes in it that can't be rectified without doing a D3, and there's a strong
> reaction to that idea based on experience with D1 -> D2. Perhaps what is needed
> is a separate area for discussion about ideas that would require a major version
> change. The thing about that is that it can't be done incrementally; it's the
> rare kind of thing that would need to be planned long in advance, and would have
> to amount to a huge improvement to justify even considering it.

I agree that D2 has made some fundamental mistakes. But it also got a great deal right.

I haven't banned Ola from the forums, he has done nothing to deserve that. He's welcome to post here, and others are welcome to engage him.

On 7/16/2016 5:32 AM, Andrew Godfrey wrote:
> On Saturday, 16 July 2016 at 06:40:31 UTC, Walter Bright wrote:
>
>> But in C++, everything is @system. I'm not sure how people successfully create
>> enormous programs with it.
>
> I work on Microsoft Word. I'm not sure how much I can share about internal
> verification tools, but I can say: We do have SAL annotation:
> https://msdn.microsoft.com/en-us/library/ms235402.aspx

Thanks for taking the time to post about your experience with it. Comparing D with SAL is a worthwhile exercise.


> As solutions go, SAL is dissatisfyingly incomplete, and not an easy
> mini-language to learn (I still haven't managed it, I look up what I need on the
> occasions that I need it). But it does impress at times with what it can catch.
> It goes a bit beyond memory safety, too, so I would guess that there are bug
> patterns it can catch that D currently won't.

I've seen SAL before, but have not studied it. My impression is it is much more complex than necessary. For example,

  https://msdn.microsoft.com/en-us/library/hh916383.aspx

describes annotations to memcpy(). I believe these are better handled by use of dynamic arrays and transitive const. But there's no doubt that careful use of SAL will reduce bugs.


> One class of bug I find interesting here is uninitialized variables. I'm not
> sure if Visual Studio helps here (we have an internal tool, I know some 3rd
> party tools do this too). But it's interesting that these tools can (often, not
> always) spot code paths where a variable doesn't get initialized. D's approach
> to this helps strongly to avoid using uninitialized memory, but in so doing, it
> discards the information these tools are using to spot such bugs. (So, the kind
> of bug D lets slip through here would tend to be one where variable foo's value
> is foo.init but it should have been initialized to some other value).

Uninitialized variables, along with their cousin adding a field to a struct and forgetting to initialize it in one of its constructors, have caused me endless problems and cost me untold hours. It was a major motivator to solve this problem in D, and I am pleased that my problems with it have been essentially eliminated.

You write that SAL still leaves undetected cases of uninitialized variables. I think I'd rather live with the limitation you mentioned in the D way rather than risk uninitialized variables. Having a predictable wrong value in a variable is debuggable, having an unpredictable wrong value is often not debuggable, which is why they consume so much time.

On Saturday, 16 July 2016 at 21:52:02 UTC, Walter Bright wrote:
> On 7/16/2016 5:32 AM, Andrew Godfrey wrote:
>> [...]
>
> Thanks for taking the time to post about your experience with it. Comparing D with SAL is a worthwhile exercise.
>
>
>> [...]
>
> I've seen SAL before, but have not studied it. My impression is it is much more complex than necessary. For example,
>
>   https://msdn.microsoft.com/en-us/library/hh916383.aspx
>
> describes annotations to memcpy(). I believe these are better handled by use of dynamic arrays and transitive const. But there's no doubt that careful use of SAL will reduce bugs.
>
>
>> [...]
>
> Uninitialized variables, along with their cousin adding a field to a struct and forgetting to initialize it in one of its constructors, have caused me endless problems and cost me untold hours. It was a major motivator to solve this problem in D, and I am pleased that my problems with it have been essentially eliminated.
>
> You write that SAL still leaves undetected cases of uninitialized variables. I think I'd rather live with the limitation you mentioned in the D way rather than risk uninitialized variables. Having a predictable wrong value in a variable is debuggable, having an unpredictable wrong value is often not debuggable, which is why they consume so much time.

I'm not trying to argue against D's design here. I'm thinking:

1) Static analysis tools still have relevance even in D code.

2) I wonder if an "uninitialized" feature would be worthwhile. That is, a value you can initialize a variable to, equal to 'init', but that static analyzers know you don't mean to ever use.

On Sunday, 17 July 2016 at 02:03:52 UTC, Andrew Godfrey wrote:
> 2) I wonder if an "uninitialized" feature would be worthwhile. That is, a value you can initialize a variable to, equal to 'init', but that static analyzers know you don't mean to ever use.

Don't we already have this in the form of int uninitialized_value = void; ?

On 7/16/2016 7:03 PM, Andrew Godfrey wrote:
> I'm thinking:
>
> 1) Static analysis tools still have relevance even in D code.

I agree, but their utility is greatly reduced, meaning the payback for the effort makes for a small benefit/cost ratio.


> 2) I wonder if an "uninitialized" feature would be worthwhile. That is, a value
> you can initialize a variable to, equal to 'init', but that static analyzers
> know you don't mean to ever use.

There is the `= void;` initialization. A static analyzer could flag any attempts to use a void initialized variable/field that is live.

On Saturday, 16 July 2016 at 21:35:41 UTC, Walter Bright wrote:
> On 7/16/2016 6:09 AM, Andrew Godfrey wrote:
>> Walter called Prolog "singularly useless". You have been referring to changes
>> that would amount to a new major version of D as "a cleanup". From the forums,
>> my sense is that there IS a groundswell of opinion, that D2 has some major
>> mistakes in it that can't be rectified without doing a D3, and there's a strong
>> reaction to that idea based on experience with D1 -> D2. Perhaps what is needed
>> is a separate area for discussion about ideas that would require a major version
>> change. The thing about that is that it can't be done incrementally; it's the
>> rare kind of thing that would need to be planned long in advance, and would have
>> to amount to a huge improvement to justify even considering it.
>
> I agree that D2 has made some fundamental mistakes. But it also got a great deal right.
>
> I haven't banned Ola from the forums, he has done nothing to deserve that. He's welcome to post here, and others are welcome to engage him.

I'm more interested in engaging on "in how many years will the D leadership be interested in engaging on the topic of D3?" I feel this is a significant omission from the vision doc, and that omission inflames a lot of the recurring animosity I see on the forums. Even an answer of "never" would be a significant improvement over "we refuse to engage on that". And I doubt you're really thinking "never".

I do think that ideas from academia will mostly cause a lot of unwanted noise in such a discussion - because academia, in my experience, is more focused on "software construction" than on "software evolution", and D takes an approach that is built on practical experience with evolution. But academia also has occasional nuggets of extreme value.

On Saturday, 9 July 2016 at 00:14:34 UTC, Walter Bright wrote:
> On 7/8/2016 2:58 PM, Ola Fosheim Grøstad wrote:
>> On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote:
>>> On 7/7/2016 5:56 PM, deadalnix wrote:
>>>> While this very true, it is clear that most D's complexity doesn't come from
>>>> there. D's complexity come for the most part from things being completely
>>>> unprincipled and lack of vision.
>>>
>>> All useful computer languages are unprincipled and complex due to a number of
>>> factors:
>>
>> I think this is a very dangerous assumption. And also not true.
>
> Feel free to post a counterexample. All you need is one!
>

Perl 6.

On Sunday, 17 July 2016 at 02:07:19 UTC, pineapple wrote:
> On Sunday, 17 July 2016 at 02:03:52 UTC, Andrew Godfrey wrote:
>> 2) I wonder if an "uninitialized" feature would be worthwhile. That is, a value you can initialize a variable to, equal to 'init', but that static analyzers know you don't mean to ever use.
>
> Don't we already have this in the form of int uninitialized_value = void; ?

No it's not the same - void initialization leaves the variable uninitialized. I'm saying, something that still initialized, but marks that initial value as not to be used. Anyway... given the existence of void initialization (which I'd forgotten about), what I suggested would be very confusing to add.