new DIP41: dmd/rdmd command line overhaul.

[Andrei Alexandrescu]

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