On Sunday, 17 July 2016 at 02:59:42 UTC, Nobody wrote:
> Perl 6.

Inequality operator :)

On Monday, 18 July 2016 at 09:45:39 UTC, Chris wrote:
> On Sunday, 17 July 2016 at 02:17:52 UTC, Andrew Godfrey wrote:
>> 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.
>
> The question is what is D3 supposed to be? I'm neither for nor against D3, it pops up every once in a while when people are not happy with a feature. My questions are:
>
> 1. Is there any clear vision of what D3 should look like?
>
> 2. What exactly will it fix?
>
> 3. Is there a prototype (in progress) to actually prove it will fix those things?
>
> 4. If there is (real) proof[1], would it justify a break with D2 and risk D's death?
>
> I think this topic is too serious to be just throwing in (partly academic) ideas that might or might not work in the real world. It's too serious to use D as a playground and later say "Ah well, it didn't work. [shrug]". D has left the playground and can no longer afford to just play around with ideas randomly. One has to be realistic.
>
> I'd also like to add that if we had a "clean and compact" D3, it would become more complex over time and people would want D4 to solve this, then D5 and so forth. I haven't seen any software yet that hasn't become more complex over time.
>
> Last but not least, it would help to make a list of the things D2 got right to put the whole D3 issue into proportion.
>
> [1] I.e. let's not refer to other languages in an eclectic manner. I'm asking for a proof that D works as D3 and is superior to D2.

We risk scaring away potential community members, and alienating existing ones, by the way we say "no" to proposals for breaking changes. We could improve how we say "no", by having a place to point people to. Potential topics:

1) As you say, a vision for D3. Maybe just a summary of the things that are now agreed upon, e.g. autodecoding (though even there, I think the details of where to move to, are still contentious. E.g. I personally dislike the convention of "char" meaning a 1-byte data type but I think some others like it).

2) The case against incremental breaking changes. (I see this argument somewhat, though it applies less to "dfixable" breaking changes).

3) Why we feel that breaking changes risk killing D outright. (I just don't see it. I wonder if we're confusing "dfixable" breaking changes, with other more disruptive kinds (such as Tango=>Phobos).)

On Monday, 18 July 2016 at 13:48:16 UTC, Andrew Godfrey wrote:
>
> 1) As you say, a vision for D3. Maybe just a summary of the things that are now agreed upon, e.g. autodecoding (though even there, I think the details of where to move to, are still contentious. E.g. I personally dislike the convention of "char" meaning a 1-byte data type but I think some others like it).
>
> 2) The case against incremental breaking changes. (I see this argument somewhat, though it applies less to "dfixable" breaking changes).
>
> 3) Why we feel that breaking changes risk killing D outright. (I just don't see it. I wonder if we're confusing "dfixable" breaking changes, with other more disruptive kinds (such as Tango=>Phobos).)

I wasn't around for the D1 to D2 change, but I was around for Python 2 to Python 3, which was inconvenient.

My sense is that a lot of the things mentioned here are "woulda-coulda-shoulda", like having defaults be @safe instead of @system. Would have been nice to have from the beginning, but just seems way too disruptive to change it now.

However, I don't have any particular issue with incremental breaking changes that are dfixable. But I think that saving them all up to do a huge D3 is potentially more disruptive than doing a small D3, completely dfixable, then a small D4, etc. Even a D3 that just changed autodecoding (which I don't think is dixable, but who knows) would be good as it would be just a small limited breaking change.

On Thursday, 14 July 2016 at 20:01:54 UTC, Walter Bright wrote:
> On 7/14/2016 11:49 AM, Steven Schveighoffer wrote:
>> In C++, the compiler has to reload x, because it may have changed.
>
> That's right. I learned that the hard way, when the original optimizer would assume that x hadn't changed. It broke a surprising amount of code.
>
> It also means that the utility of const in C++ is extremely limited.

Walter, I hope you were just in a rush. Because I think you meant to say, "the utility of const in C++ for *optimizing code* is extremely limited". If you really think that the optimizer is the primary audience for language features, then ... well that would surprise me given D's design, which generally seems quite mindful of "humans are the primary audience".

Though at times I do feel people use "auto" when they should state the type they expect (because then the compiler could help detect changes which break intent, that might otherwise compile just fine).

2016-07-18 15:48 GMT+02:00 Andrew Godfrey via Digitalmars-d < digitalmars-d@puremagic.com>:

>
> We risk scaring away potential community members, and alienating existing
> ones, by the way we say "no" to proposals for breaking changes. We could
> improve how we say "no", by having a place to point people to. Potential
> topics:
> [...]
>

I've never seen a definitive "No" to breaking changes.
We do breaking changes all the time. Did everyone already forget what the
latest release (2.071.0) was about ? Revamping the import system, one of
the core component of the language.
But it took a lot of time, and experience, to do it. It did deprecate
patterns people were using for a long time before (e.g. inheriting
imports), but its a (almost) consistent and principled implementation.

Way too often I see suggestions for a change with one (or more) of the
following mistakes:
- Want to bring a specific construct in the language rather than achieve a
goal
- Only consider the pros of such a proposal and completely skip any cons
analysis
- Focus on one single change without considering how it could affect the
whole language

But I've never seen someone willing to put the effort in a proposal to
improve the language be turned away.
In fact, our review process for language change was recently updated as
well to make it more accessible and save everyone's time. If it's not a
commitment for continuous improvement of the language, I don't know what it
is.

On 7/18/2016 6:48 AM, Andrew Godfrey wrote:
> We risk scaring away potential community members, and alienating existing ones,
> by the way we say "no" to proposals for breaking changes. We could improve how
> we say "no", by having a place to point people to. Potential topics:

Anything we do will risk scaring away people. The only answer is we have to do what is right.


> 3) Why we feel that breaking changes risk killing D outright. (I just don't see
> it. I wonder if we're confusing "dfixable" breaking changes, with other more
> disruptive kinds (such as Tango=>Phobos).)

Because if you thoroughly break a person's code, you put them in a position of rewriting it, and they may not choose to rewrite it in D3. They may choose a more stable language.

I have many older programs in different languages. It's nice if they recompile and work. It's not nice if I have to go figure out how they work again so I can get them to work again.

On 7/18/2016 9:08 AM, Andrew Godfrey wrote:
> On Thursday, 14 July 2016 at 20:01:54 UTC, Walter Bright wrote:
>> On 7/14/2016 11:49 AM, Steven Schveighoffer wrote:
>>> In C++, the compiler has to reload x, because it may have changed.
>>
>> That's right. I learned that the hard way, when the original optimizer would
>> assume that x hadn't changed. It broke a surprising amount of code.
>>
>> It also means that the utility of const in C++ is extremely limited.
>
> Walter, I hope you were just in a rush. Because I think you meant to say, "the
> utility of const in C++ for *optimizing code* is extremely limited".

No. I meant const's utility to provide checkable, reliable information about code. I'm a big believer in encapsulation, and const is a major tool for that. But C++ const just isn't very helpful.

On 7/18/2016 5:06 AM, Kagamin wrote:
> On Saturday, 16 July 2016 at 21:52:02 UTC, Walter Bright wrote:
>> 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.
>
> I suppose in case of memcpy the compiler can catch (at the caller side) the case
> when the destination buffer has insufficient size, while D can catch it only at
> runtime. It's a contract expressed with a simple grammar.

Determining array bounds is the halting problem in the general case, and SAL doesn't solve that.

On Monday, 18 July 2016 at 18:03:49 UTC, Mathias Lang wrote:
> 2016-07-18 15:48 GMT+02:00 Andrew Godfrey via Digitalmars-d < digitalmars-d@puremagic.com>:
>
>>

>
> I've never seen a definitive "No" to breaking changes.
> We do breaking changes all the time. Did everyone already forget what the
> latest release (2.071.0) was about ? Revamping the import system, one of
> the core component of the language.
> But it took a lot of time, and experience, to do it. It did deprecate
> patterns people were using for a long time before (e.g. inheriting
> imports), but its a (almost) consistent and principled implementation.

Although it can be a PITA, people accept breaking changes, if they really make sense.

> Way too often I see suggestions for a change with one (or more) of the
> following mistakes:
> - Want to bring a specific construct in the language rather than achieve a
> goal
> - Only consider the pros of such a proposal and completely skip any cons
> analysis
> - Focus on one single change without considering how it could affect the
> whole language

That's also my impression. Given that D is open source I'm surprised that nobody has grabbed it and come up with a prototype of D3 or whatever. How else could you prove your case? After all the onus of proof is on the one who proposes a change. Don't just sit and wait until Walter says "Go ahead", knowing full well that the core devs are in no position to dedicate time to D3 at the moment - that's too easy and it gets us nowhere.

> But I've never seen someone willing to put the effort in a proposal to
> improve the language be turned away.
> In fact, our review process for language change was recently updated as
> well to make it more accessible and save everyone's time. If it's not a
> commitment for continuous improvement of the language, I don't know what it
> is.

On Tuesday, 19 July 2016 at 09:49:50 UTC, Chris wrote:
> On Monday, 18 July 2016 at 18:03:49 UTC, Mathias Lang wrote:
>> 2016-07-18 15:48 GMT+02:00 Andrew Godfrey via Digitalmars-d < digitalmars-d@puremagic.com>:
>>
>>>
>
>>
>> I've never seen a definitive "No" to breaking changes.
>> We do breaking changes all the time. Did everyone already forget what the
>> latest release (2.071.0) was about ? Revamping the import system, one of
>> the core component of the language.
>> But it took a lot of time, and experience, to do it. It did deprecate
>> patterns people were using for a long time before (e.g. inheriting
>> imports), but its a (almost) consistent and principled implementation.
>
> Although it can be a PITA, people accept breaking changes, if they really make sense.
>
>> Way too often I see suggestions for a change with one (or more) of the
>> following mistakes:
>> - Want to bring a specific construct in the language rather than achieve a
>> goal
>> - Only consider the pros of such a proposal and completely skip any cons
>> analysis
>> - Focus on one single change without considering how it could affect the
>> whole language
>
> That's also my impression. Given that D is open source I'm surprised that nobody has grabbed it and come up with a prototype of D3 or whatever. How else could you prove your case? After all the onus of proof is on the one who proposes a change. Don't just sit and wait until Walter says "Go ahead", knowing full well that the core devs are in no position to dedicate time to D3 at the moment - that's too easy and it gets us nowhere.
>
>> But I've never seen someone willing to put the effort in a proposal to
>> improve the language be turned away.
>> In fact, our review process for language change was recently updated as
>> well to make it more accessible and save everyone's time. If it's not a
>> commitment for continuous improvement of the language, I don't know what it
>> is.

We all seem to be in agreement that people often make breaking-change proposals without considering the impact properly. I have seen this many times on the forums and not once (so far) has the reply been simply, "please go and read the section of our vision doc that talks about breaking changes".

I'm suggesting that is what should happen. Instead, I have seen each time a disussion thread that explores only parts of the topic of breaking changes, and does so badly. Just like earlier in this thread, where I mentined dfixable breaking changes and Walter implied that even though a would cause people to have to manually rewrite.

(This example is a specific bias I have noticed in other threads: arguing about a breaking change without evaluating whether it is dfixable).