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
