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

On 3/13/14, 4:14 AM, Suliman wrote:
> A lot of people here are talking about C. They are saying that C almost
> do not have changes that had break compatibility and it's good. But
> people are forgot, that D is much more complex language then C is.

C++.

Andrei

"Brian Rogoff"  wrote in message news:hvdmgktbuhmemwqmbeqn@forum.dlang.org...

> It might be worthwhile to consider a compiler switch which would require forced virtual/final annotations on all methods as per
>
> https://d.puremagic.com/issues/show_bug.cgi?id=11616#c4
>
> While code compiled with such a switch would be a bit more verbose, it would ensure that programmers were careful with virtual. It was a good transition plan, and the idea has value even if the final by default is delayed or abandoned.

A compiler switch is not the place for this, but it would make a fine lint rule. 

On 3/13/14, 6:15 AM, Daniel Murphy wrote:
> There is nothing wrong with reporting directly to Walter, the problem is
> when Walter/Andrei then make decisions based on this information
> privately. Walter has been wrong about these things in the past, and
> without knowing who the third party is it's impossible to get
> clarification.

Just for the record that was given as an example, not a motivator.

After much deliberation, we believe we are right in our decision to not make final the default.


Andrei

On Thursday, 13 March 2014 at 15:31:25 UTC, Daniel Murphy wrote:
> A compiler switch is not the place for this, but it would make a fine lint rule.

It can also be done in D today using UDAs and compile time reflection, including project-wide if you want to use RTInfo.

On Thursday, 13 March 2014 at 04:24:01 UTC, Manu wrote:
> You and Andrei are the only resistance in this thread so far. Why don't you
> ask 'temperamental client' what their opinion is? Give them a heads up,
> perhaps they'll be more reasonable than you anticipate?
> Both myself and Don have stated on behalf of industrial clients that we
> embrace breaking changes that move the language forward, or correct clearly
> identifiable mistakes.

As the CTO of SR Labs, with a huge D2 codebase in production products, I agree with Manu, and I'm stating that we will be happy to spend some time updating deprecated features if the goal is a better language.

- Paolo Invernizzi

On 3/13/14, 7:48 AM, Joseph Rushton Wakeling wrote:
> On Thursday, 13 March 2014 at 04:58:05 UTC, Andrei Alexandrescu wrote:
>> I hear you. Time to put this in a nice but firm manner: your arguments
>> were understood but did not convince.
>
> The problem is that this remark could be made in both directions.  I
> understand some of the motivation for this decision, but the way it's
> been announced and rationalized is very problematic.
>
> That naturally leads to questions about whether it's the right decision
> or not, and to be honest, I don't think the follow-ups from you and
> Walter have adequately addressed those concerns.

At a level it's clear it's not a matter of right or wrong but instead a judgment call, right? Successful languages go with either default.

> Problem 1 -- the announcement as made gives the impression that a known,
> planned, desirable breaking change with a well-defined deprecation path
> is to be cancelled because of a client's response to an unplanned and
> unannounced breakage.  You need to make the case for why
> well-signposted, well-executed deprecation paths are a problem that sits
> on the same level as the kind of unexpected breakage this client
> encountered.

The breakage was given as an example. We would have decided the same without that happening.

> Problem 2 -- perhaps there's a broader context that you can't discuss
> with us because of commercial confidentiality, but the impression given
> is that this decision has been taken substantially in reaction to one
> bad client response.  This gives the impression of a knee-jerk reaction
> made under stress rather than a balanced decision-making process.  More
> so because it's not clear if the client would have the same problem with
> a well-executed deprecation process.

More than sure a well-executed deprecation process helps although it's not perfect. We're not encumbered by exhausting confidentiality requirements etc.

> Problem 3 -- I don't think this decision has adequately acknowledged the
> original rationale for favouring final-by-default.  Walter has discussed
> the speed concern, but that was not the killer argument -- the one which
> swung the day was the fact that final-by-default makes it easier to
> avoid making breaking changes in future -- see e.g.:
> http://forum.dlang.org/thread/pzysdctqxjadoraeexaa@forum.dlang.org?page=10#post-mailman.246.1386164839.3242.digitalmars-d:40puremagic.com
>
> http://www.artima.com/intv/nonvirtualP.html
>
> So, if avoiding breaking change in future is a strong goal, allowing the
> transition to final-by-default is a clear contribution to that goal.

There's some underlying assumption here that if we "really" understood the arguments we'd be convinced. Speaking for myself, I can say I understand the arguments very well. I don't know how to acknowledge them better than I've already done.

> Finally, I'd say that to my mind, these kinds of announcements-by-fiat
> that come out of the blue and without warning, while not as bad as
> unexpected code breakage, are still pretty bad for the D user
> community.  We need to be able to have trust in the firm decisions and
> understandings reached here in community discussions, that either they
> will be adhered to or that there will be prior notice and discussion
> before any counter-decision is finalized.  This is as much part of
> stability and reliability as the code in the compiler and the libraries.

Thanks for being candid about this. I have difficulty, however, picturing how to do a decision point better. At some point a decision will be made. It's a judgment call, that in some reasonable people's opinion, is wrong, and in some other reasonable people's opinion, is right. For such, we're well past arguments' time - no amount of arguing would convince. I don't see how to give better warning about essentially a Boolean decision point that precludes pursuing the converse design path.


Andrei

>> 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.

Exactly, it's a spectrum. But at any given time, the whole language and library are not at a single point on the spectrum. Some things are frozen, others in practice are not. And the problem is that D has historically acted as if everything was the same, which just doesn't work.

I think three levels of forwards compatibility are useful to consider:

1. Frozen. Things that you can absolutely rely on, we will NEVER change it under any circumstances. Any bugs in the design will never be fixed.

2. Stable. We will attempt to minimize changes, but we don't guarantee your code will never break. (It may break in order to prevent breakage of things in case 1, for example). We can guarantee a deprecation path in most cases.

3. We will avoid gratuitous changes, but it will almost certainly change in the future.

And what we want to do, is gradually move as many things as we can from category (2) into category (1), and from (3) into (2).

I'd like to see us giving a lot more guarantees, rather than trying to keep promises we never actually made.

Le 13/03/2014 02:13, Walter Bright a écrit :
> On 3/12/2014 5:40 PM, Vladimir Panteleev wrote:
>> Doesn't this sort of seal the language's fate in the long run, though?
>> Eventually, new programming languages will appear which will learn
>> from D's
>> mistakes, and no new projects will be written in D.
>>
>> Wasn't it here that I heard that a language which doesn't evolve is a
>> dead
>> language?
>>
>>  From looking at the atmosphere in this newsgroup, at least to me it
>> appears
>> obvious that there are, in fact, D users who would be glad to have
>> their D code
>> broken if it means that it will end up being written in a better
>> programming
>> language. (I'm one of them, for the record; I regularly break my own
>> code anyway
>> when refactoring my library.) Although I'm not advocating forking off
>> a D3 here
>> and now, the list of things we wish we could fix is only going to grow.
>
> There are costs and benefits:
>
> Benefits:
>
> 1. attracting new people with better features
>
> Costs:
>
> 2. losing existing users by breaking their code, losing new people
> because of a reputation for instability
>
> There aren't clearcut answers. It's a judgement call. The
> final-by-default has very large breakage costs, and its improvement is
> minor and achievable by other means.


IMO the major issue with changes is that they are propagated on new versions of dmd with other fixes. Why compiler fixes aren't back-ported on some old dmd versions? This will let opportunity to get fixes without breaking changes when a D users is to close of making a release.
I know it's a lot additional work for the D community but it will offer more choices.

On other idea is to create a major revision of D each year (maybe close after dconf) and present the previous one as the stable. The stable will receive all fixes and non-breaking changes.
This rhythm of one version per year will decrease in the time due to a lower necessity to make breaking changes.
Doing things like that will allow companies to migrate to the next stable D version progressively (with version checks).
We did something similar at my job with Qt, because we start with the version 4.8 and necessitas (unofficial android support). At the same time we had worked on 5.0 alpha integration (I did some bugs reports to help his development)

"Andrei Alexandrescu"  wrote in message news:lfsja8$1rom$1@digitalmars.com...

> After much deliberation, we believe we are right in our decision to not make final the default.

If I've absorbed the information correctly, you think the change is good but the breakage would be too large.

This thread has had people from several 'industry' D users stating that they do not have a problem with well planned breaking changes, and I'm not sure why you feel differently about this.

Why are you so sure this change is too much breakage to be acceptable?

Where exactly is the line between 'worth it' and 'too big'?