Final by default?

[Andrei Alexandrescu]

On 3/13/14, 2:49 AM, Don wrote:
> On Thursday, 13 March 2014 at 05:15:58 UTC, Sean Kelly wrote:
>> I find this a bit baffling.  Given the investment this customer must
>> have in D, I can't imagine them switching to a new language over
>> something like this.  I hate to say it, but this sounds like the
>> instances you hear of when people call up customer service just to
>> have someone to yell at.  Not that the code breakage is okay, but I do
>> feel like this may be somewhat of an exaggeration.
>
> And std.json is among the worst code I've ever seen. I'm a bit shocked
> that anyone would be using it in production code.

We're using it.

>> Regarding user retention... I've spent the past N months beginning the
>> process of selling D at work.  The language and library are at a point
>> of maturity where I think it might have a chance when evaluated simply
>> on the merits of the language itself.  However, what has me really
>> hesitant to put my shoulder behind D and really push isn't that
>> changes occur sometimes.  Even big changes.  It's how they're handled.
>> Issues come up in the newsgroup and are discussed back and forth for
>> ages.  Seriously considered.  And then maybe a decision is apparently
>> reached (as with this virtual by default thing) and so I expect that
>> action will be taken.  And then nothing happens.  And other times big
>> changes occur with seemingly little warning.  Personally, I don't
>> really require perfect compatibility between released, but I do want
>> to see things moving decisively in a clearly communicated direction. I
>> want to know where we're going and how we're going to get there, and
>> if that means that I have to hold on moving to a new compiler release
>> for a while while I sort out changes that's fine.  But I want to be
>> able to prepare for it.  As things stand, I'm worried that if I got a
>> team to move to D we'd have stuff breaking unexpectedly and I'd end up
>> feeling like an ass for recommending it.  I guess that's probably what
>> prompted the "almost lost a major client" issue you mentioned above.
>> This JSON parser change was more the proverbial straw than a major
>> issue in itself.
>
> I agree completely.
>
> Some things that really should be fixed, don't get fixed because of a
> paranoid fear of breaking code. And this tends to happen with the issues
> that can give nice warning messages and are easy to fix...
>
> Yet there are still enough bugs that your code breaks every release anyway.
> We need to lose the fantasy that there is legacy code which still compiles.
> Anything more than a year or so old is broken already.

Backward compatibility is more like a spectrum than a threshold. Not 
having it now is not an argument to cease pursuing it.


Andrei