On Wednesday, 22 May 2013 at 21:15:24 UTC, Andrei Alexandrescu wrote:
> My understanding of your reasoning is:
>
> 1. Stability is something binary, if you break some code no matter how much code and on what grounds - if you break it stability is zero. If you don't break any code at all, then stability is one. There is no intermediate state between zero and one.
>
> 2. By definition (1), D is not stable.
>
> 3. Therefore since it's not stable, let's accept whatever changes because they won't make anyone's life worse.
>
> Is my interpretation correct? If so, do you understand reasonable people may disagree with the reasoning above?

1 and 2 are correct. But 3 is actually "Since it is not stable, stop pretend it is in its current state".

Stability is something much more than just an intention. It is a formal promise and well-defined process. I don't want feature change anarchy, I want _true_ stability. It just happens that true stability often accepts inevitability of change and strictly defines what changes can be done and, most importantly, how it can be done.

Of course people (and D developers) can disagree. But what about at least defining (on dlang.org) _your_ view on stability and what guarantees that does provide for users? Isn't this a reasonable request? Because currently it is more like buzz word.

I recall Andrei's talk about what to do if you want a million users. Do as you would do if you had a million users.

Certain changes make sense to have if D is to have a million users. Some of them, unfortunately, would be a pointless hassle to existing users. It's a difficulty that unlikely to get solved through arguing.

One possible approach would be as with python 2 vs python 3. Have a "different" D branch that pays far less attention to current users, and far more to the millions ahead. And build conversion tools alongside, to help current users convert when (and IF) the new branch succeeds in being significantly better.

Dmitry

On Wed, May 22, 2013 at 5:15 PM, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

> On 5/22/13 3:04 PM, Dicebot wrote:
>
>> On Wednesday, 22 May 2013 at 14:37:10 UTC, John Colvin wrote:
>>
>>> On Wednesday, 22 May 2013 at 14:09:57 UTC, Dicebot wrote:
>>>
>>>> no one cares about reasons for code breakage. For those who care about breakage, it is a boolean flag - either breaks, or not.
>>>>
>>>
>>> This may well be the case, but you're missing the point:
>>>
>>> Breakage is always bad, so we avoid it *unless* the change adds some
>>> significant value to the language.
>>> Fixing a bug (almost) always adds significant value.
>>> Changing command line syntax, in my opinion (and, it would appear,
>>> Walter and Andrei's) does not add significant value.
>>>
>>> Although each individual person who suffers breakage may not care why it happened, this does not in any way constitute an argument for allowing less important changes to break stuff.
>>>
>>
>> You seem to misunderstand what angers me and Jacob here. It is not the fact that this specific DIP is rejected (I don't really care), it is the fact that D developers keep repeating "D goes stable" mantra when it actually does not. Pretending to prioritize stability and breaking code even with bug fixes is technically lying. Bad for reputation, bad for marketing. And good luck using "They have a different understanding of stability" line in a dialog with enterprise type manager.
>>
>> If stability is really a priority - please start doing something real about it. At least start with defining what "stability" means and what guarantees D team can give for users. Publish it at dlang.org and it is at least a start.
>>
>> Or stop rejecting stuff using "stability" as smoke screen. This two options exclude each other.
>>
>
> I don't understand what you're sustaining. We all want D to become more stable. It's not a smoke screen or a pretext to reject improvements.
>
> My understanding of your reasoning is:
>
> 1. Stability is something binary, if you break some code no matter how much code and on what grounds - if you break it stability is zero. If you don't break any code at all, then stability is one. There is no intermediate state between zero and one.
>
> 2. By definition (1), D is not stable.
>
> 3. Therefore since it's not stable, let's accept whatever changes because they won't make anyone's life worse.
>
> Is my interpretation correct? If so, do you understand reasonable people may disagree with the reasoning above?
>
>
> Andrei
>

On Wednesday, 22 May 2013 at 14:09:57 UTC, Dicebot wrote:
> This is _exactly_ the mindset I am trying to fight with. I have had an unpleasant experience of working in typical enterprise environment for few years and there is quite a strong attitude about this - no one cares about reasons for code breakage. For those who care about breakage, it is a boolean flag - either breaks, or not.

I think this is a mindset that needs to die. Consider why someone would choose to use D.

D provides an improved experience over the language being used. How did D achieve this? It was by being one big breaking change. Everyone using D is reaping benefits from D choosing that it will not compile all C code.

So while people claim they don't want breaking change, what they really mean is "I only want breaking change when I decide I to take it." And each person/situation will have different desire on what they wish to have broken. What we want is to select changes that people will want, make it easy to make/expect the changes, and enough time they will make the choice on their own.

D is stabilizing and is stable enough for many. We want to make progress in that direction, we don't want to just halt development like was done at D1. We have been making it less painful to upgrade and that effort should continue and doesn't need to be through a "no breaking changes" mandate.

On Thursday, May 23, 2013 01:35:13 Jesse Phillips wrote:
> D is stabilizing and is stable enough for many. We want to make progress in that direction, we don't want to just halt development like was done at D1. We have been making it less painful to upgrade and that effort should continue and doesn't need to be through a "no breaking changes" mandate.

What it comes down to is that breaking changes must provide a sufficiently high ROI, or they're unacceptable. The classic example of this from Walter is renaming stuff. The ROI on that is generally very small, so he's pretty much always completely against it even if he agreed that the proposed name was better. An example of where the ROI was very was in making it so that implicit fallthrough on switches was illegal. That's not just aesthetic. It catches real bugs.

The trick then is figuring out with any proposed change whether the ROI is high enough to make the change worth it. And Walter and Andrei (particularly Walter) lean heavily towards thinking that the ROI on breaking changes must be very high before they're acceptable. So, anyone arguing for a breaking change has a very high bar to meet. Maybe that bar is too high sometimes, but if it's too low, then we'll never reach the point where you can reasonably expect your code to continue to compile with every new release of dmd (or at least for a long time).

So, it's not the case that breaking changes are absolutely unacceptable, but it _is_ the case that anyone wanting a breaking change has to present a very strong case. And I don't think that that's necessarily a bad thing. In fact, as the language and its implementation matures, it's pretty much a necessity.

- Jonathan M Davis

On Wednesday, 22 May 2013 at 18:46:55 UTC, Jacob Carlborg wrote:
> I have not so much problem with the breaking in it self. It's rather that there are several people here pretending D is stable.

I think that on the surface, saying something is "stable" makes it sound like that is always good. So it's a public relations win if you can say your product is stable. But the truth is that if what is "stable" is a really bad design decision or a flat out bug, then that kind of "stability" is bad. But since so many people think stability is always good (it certainly *sounds* good), I can understand why there is a reluctance to admit that there is a lack of stability.

If only there were a way to communicate, "Yes, there is a lack of stability, but it's for darn good reasons!" Until that way is found, there must always be a tension between doing the "right thing", and convincing people it's more "stable" than it really is.

On 5/22/2013 5:07 PM, Zach the Mystic wrote:
> If only there were a way to communicate, "Yes, there is a lack of stability, but
> it's for darn good reasons!" Until that way is found, there must always be a
> tension between doing the "right thing", and convincing people it's more
> "stable" than it really is.

And then there are those "I don't think we should introduce breaking changes, and here's my list of must-have features that break things." :-)

On Thursday, 23 May 2013 at 01:24:34 UTC, Walter Bright wrote:
> On 5/22/2013 5:07 PM, Zach the Mystic wrote:
>> If only there were a way to communicate, "Yes, there is a lack of stability, but
>> it's for darn good reasons!" Until that way is found, there must always be a
>> tension between doing the "right thing", and convincing people it's more
>> "stable" than it really is.
>
> And then there are those "I don't think we should introduce breaking changes, and here's my list of must-have features that break things." :-)

I can't help but think that success itself poses a problem for a programming language. The smaller the user base, the better it can absorb the shock, and the more loyal it is. But once you become mainstream, now people are using your language because they *have* to - I suspect it's these people who will demand stability above all else, because they don't care where the language came from or why any of the important decisions were made. They just want to get their work done.

Therefore, seize the day! The more people use D, the harder it will be to do the right thing - engineering-wise! But D is not designed for a small user base. It is designed to last. Be like the Tao!

On 2013-05-22 15:52, Walter Bright wrote:

> The current beta 4 is pretty much it. Please run DWT for it today and
> post any regressions found.

I posted this to the beta mailing list as well:

I get the following error compiling DWT:

"static_this without 'this' cannot be shared"

This is most likely a correct change (I've already fixed the code) but there was no warnings, no depreciation message, it just suddenly stopped compiling.

Again, please stop pretending D is stable.

-- 
/Jacob Carlborg

On 2013-05-22 23:15, Andrei Alexandrescu wrote:

> I don't understand what you're sustaining. We all want D to become more
> stable. It's not a smoke screen or a pretext to reject improvements.

It's a big difference say we want D to _become_ stable and saying D _is_ stable. There are many people here using the latter. I don't agree with them.

-- 
/Jacob Carlborg

On Wednesday, 22 May 2013 at 23:35:14 UTC, Jesse Phillips wrote:
> So while people claim they don't want breaking change, what they really mean is "I only want breaking change when I decide I to take it." And each person/situation will have different desire on what they wish to have broken. What we want is to select changes that people will want, make it easy to make/expect the changes, and enough time they will make the choice on their own.

That is exactly what I want! But if we keep saying "we are stable, trying to be stable, almost there" it won't change. It requires some formal process, not only simple desire to be stable. Current attitude just hides away real issues inventing local meaning for "stability".