That's a much nicer way of saying what I was trying to get across.  :-)
Early respondents to a lengthy survey about D usage are not necessarily a
good representation of the more casual user's needs for the language.


On Thu, Mar 1, 2018 at 1:49 PM, Jonathan M Davis via Digitalmars-d-announce
<> wrote:

> On Thursday, March 01, 2018 13:24:29 Bill Baxter via Digitalmars-d-announce
> wrote:
> > Just don't overlook the fact that people who fill out 30 minute surveys
> > right away after being told about them are a self-selected group of
> people
> > who apparently have way too much time on their hands.
> > Which also suggests they would likely also have more free time to go
> chase
> > down and fix breaks in their legacy code caused by new compilers.
> It's also the case that the folks who even see this survey are likely to be
> a fairly small percentage of the actual user base. So, while its results
> may
> be useful, they need to be viewed with that fact in mind.
> That being said, I think that it's a given that we need to make breaking
> changes at least occasionally. The question is more how big they can be and
> how we go about it. Some changes would clearly be far too large to be worth
> it, whereas others clearly pay for themselves. The harder question is the
> stuff in between.
> For instance, while we might not actually have a new operator if D were
> being redesigned from the ground up (Andrei has previously stated that it
> really should have just been a function in the standard library or
> runtime),
> that would be far too large a change with far too little benefit to be even
> vaguely worth it at this point. On the other hand, we _did_ change it so
> that switch statements don't have implicit fallthrough anymore, and that
> change was _very_ well received, because it caught bugs and it was a quick
> fix to update correct code that was then an error (it was probably also
> true
> that relatively little correct code had to be updated, but that's harder to
> measure).
> Each potential breaking change has to be weighed on its own, and the real
> question is how strongly we weight the pros vs the cons. We could choose to
> favor breaking code only when it's cleary _very_ benificial to do so, or we
> could choose to break code any time there's even a slight benefit to it. I
> think that it's pretty clear that the right choice is somewhere in between
> those two extremes, but it's not an easy question as to where it is.
> And as has been discussed before, we have folks clamoring for breaking
> changes and folks clamoring for nothing to ever break, and sometimes,
> they're exactly the same folks. :|
> - Jonathan M Davis

Reply via email to