On Thursday, 13 March 2014 at 05:15:58 UTC, Sean Kelly wrote:
On Wednesday, 12 March 2014 at 22:50:00 UTC, Walter Bright
wrote:
The argument for final by default, as eloquently expressed by
Manu, is a good one. Even Andrei agrees with it (!).
The trouble, however, was illuminated most recently by the
std.json regression that broke existing code. The breakage
wasn't even intentional; it was a mistake. The user fix was
also simple, just a tweak here and there to user code, and the
compiler pointed out where each change needed to be made.
But we nearly lost a major client over it.
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.
Regarding this virtual by default issue. I entirely support
Manu's argument and wholeheartedly agree with it. I even think
that I'd be more likely to use D professionally if D worked
this way, for many of the same reasons Manu has expressed.
There may even be a window for doing this, but the
communication around the change would have to be perfect.
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.
As for the !virtual idea... I hate it. Please don't add yet
more ways for people to make their code confusing.
