On Thursday, 23 May 2013 at 01:24:34 UTC, Walter Bright wrote:
> 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 even remember last time when it was the case.

On Wednesday, 22 May 2013 at 23:52:25 UTC, Jonathan M Davis wrote:
> What it comes down to is that breaking changes must provide a sufficiently high
> ROI, or they're unacceptable.

And what was the reason to take this as an axiom? What makes you think core D developers can decide for all other D users what is sufficiently high ROI and what is not? For _everyone_. And how do you define "sufficiently high"?

That is exactly what I call "intention-based stability". Your intentions are good and goal is noble but lack of strict rules make it essentially useless. Problem is, "stability" is not some abstract merit that can be measured. It is a certain expectation with pragmatical use cases.

One good way to make compiler/language stable is to ask "Why do people need it stable? What problems does it solve? How our guarantees help?". And most common answer for first question I have encountered so far : "Because people hate to spend time in the middle of project to fix unexpected issues from already working code base". Note that this has nothing to do with features, or ROI, or correctness, or whatever. It is all about expectation of a change. And despite all efforts, D falls miserably here. See current beta mailing list for several examples of what should have never happened in real stable development process.

On 5/23/2013 2:01 AM, Dicebot wrote:
> See current beta mailing list for several
> examples of what should have never happened in real stable development process.

The reason it is a beta is so we can identify problems and deal with them before a release.

On Thursday, 23 May 2013 at 09:26:31 UTC, Walter Bright wrote:
> On 5/23/2013 2:01 AM, Dicebot wrote:
>> See current beta mailing list for several
>> examples of what should have never happened in real stable development process.
>
> The reason it is a beta is so we can identify problems and deal with them before a release.

In perfect world beta exists to identify problems _unknown_ before. Almost all issues I have seen mentioned so far was known by developers (those were bug fixes after all) but considered acceptable to put into compiler anyway. And that is a problem.

On Thursday, 23 May 2013 at 09:29:22 UTC, Dicebot wrote:
> On Thursday, 23 May 2013 at 09:26:31 UTC, Walter Bright wrote:
>> On 5/23/2013 2:01 AM, Dicebot wrote:
>>> See current beta mailing list for several
>>> examples of what should have never happened in real stable development process.
>>
>> The reason it is a beta is so we can identify problems and deal with them before a release.
>
> In perfect world beta exists to identify problems _unknown_ before. Almost all issues I have seen mentioned so far was known by developers (those were bug fixes after all) but considered acceptable to put into compiler anyway. And that is a problem.

I don't think it's possible for a language to both evolve and keep being stable. At least not with the current release process, with a single branch.

There should at least be 2 branches - stable (as in binary stable - 0% code breakage), and experimental/beta/you name it, which breaks code when reasonable.
Then, after some amount of time, this experimental branch becomes the new stable branch (while the previous is still available for download).

I think the "Development and Release Process" wiki page proposes exactly that.
http://wiki.dlang.org/Release_Process

On Thursday, 23 May 2013 at 09:39:18 UTC, Mr. Anonymous wrote:
> I think the "Development and Release Process" wiki page proposes exactly that.
> http://wiki.dlang.org/Release_Process

Yeah, it is how it is usually done and it was proposed numerous times in various forms. But unless those who actually do release will adopt it and truly believe it is the way to go - it is just a text.

On 5/23/13 3:07 AM, Jacob Carlborg wrote:
> 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.

I agree with you :o).

Andrei

On 5/23/13 5:01 AM, Dicebot wrote:
> On Wednesday, 22 May 2013 at 23:52:25 UTC, Jonathan M Davis wrote:
>> What it comes down to is that breaking changes must provide a
>> sufficiently high
>> ROI, or they're unacceptable.
>
> And what was the reason to take this as an axiom? What makes you think
> core D developers can decide for all other D users what is sufficiently
> high ROI and what is not? For _everyone_. And how do you define
> "sufficiently high"?

You are right. As Bjarne famously said, "no one knows what most programmers do". We can at best make guesses or use proxies to infer what is best for our community. Conversely, a small vocal minority of the community would have difficulty claiming to be the most representative sample.

It's an imperfect system, and we do our best with what we know, whom we work with, and what we believe. We all have the same goal. To be frank - relax. There's no reason to get overly combative over this.

> That is exactly what I call "intention-based stability". Your intentions
> are good and goal is noble but lack of strict rules make it essentially
> useless. Problem is, "stability" is not some abstract merit that can be
> measured. It is a certain expectation with pragmatical use cases.

Yes but we get back to the binary notion that you seem to endorse: every breakage is as bad, and any breakage creates a precedent for any other breakage. I disagree with this.

> One good way to make compiler/language stable is to ask "Why do people
> need it stable? What problems does it solve? How our guarantees help?".
> And most common answer for first question I have encountered so far :
> "Because people hate to spend time in the middle of project to fix
> unexpected issues from already working code base". Note that this has
> nothing to do with features, or ROI, or correctness, or whatever. It is
> all about expectation of a change. And despite all efforts, D falls
> miserably here. See current beta mailing list for several examples of
> what should have never happened in real stable development process.

This view would ignore all progress we've made in improving stability.


Andrei

On Tuesday, 21 May 2013 at 15:29:49 UTC, Andrei Alexandrescu wrote:
> On 5/21/13 5:44 AM, Timothee Cour wrote:
>> Abstract:
>> This DIP seeks to improve dmd and rdmd's command line flags, to make it
>> more self-consistent and consistent with other tools (including other D
>> compilers), more expandable, avoid existing corner cases, and better
>> interact with other tools such as rdmd. It also proposes new flags and
>> proposes a simple deprecation path to follow.
>>
>> Link:
>> http://wiki.dlang.org/DIP41
>
> I think this DIP should be rejected. Even if implemented to perfection it would do nothing to make D better.
>
> Overhauling command line syntax would only help if the situation was unbearable or if people couldn't do what they wanted to do. As things go I find the situation marginally clunkier than it could be, but command line syntax can never be beautiful or perfect.
>
>
> Andrei

Andrei, there is a perfect, diplomatic solution to this - you make a survey of D community, and if the majority votes "YES" for a breaking change, then after that when someone complains, you just give that person a link to the survey result, with a comment "you asked for it!".

On Thursday, 23 May 2013 at 13:08:25 UTC, Andrei Alexandrescu wrote:
> It's an imperfect system, and we do our best with what we know, whom we work with, and what we believe. We all have the same goal. To be frank - relax. There's no reason to get overly combative over this.

I am really glad to hear that you at least accept it is imperfect system. Beg my sincere pardon if my comments sound hostile, it is very hard to keep the right balance between being polite and actually breaking the comfort zone.

You don't answer the question though - why adopting widely used release processes to address this is not an option for D? Do you see any hidden issues there?

> Yes but we get back to the binary notion that you seem to endorse: every breakage is as bad, and any breakage creates a precedent for any other breakage. I disagree with this.

As I have already said, I have never said that "any breakage creates a
> precedent for any other breakage". It is more like "any breakage marks release as breaking".

> This view would ignore all progress we've made in improving stability.

Because for me personally there have been no improvements in _release_ stability. Overall compiler quality has increased tremendously, but process stays roughly the same. I am sorry to say this.