"Xavier Bigand"  wrote in message news:lfslr2$1tu6$1@digitalmars.com...

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

Because...

> I know it's a lot additional work for the D community but it will offer more choices.

This is why.  Nobody has volunteered to do it.  It will happen when somebody who wants it actually does it. 

Le 13/03/2014 05:23, Manu a écrit :
> On 13 March 2014 11:13, Walter Bright <newshound2@digitalmars.com
> <mailto:newshound2@digitalmars.com>> wrote:
>
>     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.
>
>
> It's not minor, and it's not achievable by other means though.
> It's also not a very large breaking change. In relative terms, it's
> already quantified - expected to be much smaller than override was; this
> only affects bases, override affected all branches and leaves.
>
> 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.
>
> One of the key advantages to D over other languages in my mind is
> precisely it's fluidity. The idea that this is a weakness doesn't
> resonate with me in any way (assuming that it's managed in a
> sensible/predictable/well-communicated manner).
> I *like* fixing my code when a breaking change fixes something that was
> unsatisfactory, and it seems that most others present feel this way too.
> I've used C++ for a long time, I know very well how much I hate carrying
> language baggage to the end of my years.
>

I am completely agree without you, it's the biggest issue of c++ to be so slow to evolve it's like a diplodocus. I though D was born to fix this issue. Why c++ includes wasn't replaced by imports during last 20 years? It's cool bigger companies can distribute compilation but all small companies just can't and have to wait so much time to have a binary.
I don't want to see anymore bad decisions living so much times, it's normal to make errors but a critical mistake to doesn't fix it.
All is about the rythm when you force D developers to update their old code. Some constructors like Nintendo or Apple let you few month to migrate your code, else submissions will be refused.

> That said, obviously there's a big difference between random breakage
> and controlled deprecation.
> The 2 need to stop being conflated. I don't think they are the same
> thing, and can't reasonably be compared.
> I've never heard anybody object to the latter if it's called for. The
> std.json example you raise is a clear example of the former.

On 3/13/14, 9:23 AM, Daniel Murphy wrote:
> "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.

That is correct. If I did things over again, I'd probably favor defaulting to final. However, it is my belief that this particular design choice does not make nearly as dramatic a difference as some people seem to believe.

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

I have seen those messages as well. I have argued at length why I feel differently about this, including how I see the numbers working in this forum. As far as I can tell you are not convinced, so repeating those arguments would not help.

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

I don't know how to answer this. Again, I can only assume that whatever justification I reiterate it's unlikely to help any.

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

I know a guy who knows exactly where it is. He's a liar :o). This is clearly a rhetorical question, but in this case I believe the change is not worth it.


Andrei

On 3/13/14, 9:28 AM, Daniel Murphy wrote:
> "Xavier Bigand"  wrote in message news:lfslr2$1tu6$1@digitalmars.com...
>> I know it's a lot additional work for the D community but it will
>> offer more choices.
>
> This is why.  Nobody has volunteered to do it.  It will happen when
> somebody who wants it actually does it.

Word. I can't emphasize this enough.

Andrei

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.
>
> We're past the point where we can break everyone's code. It's going to cost us far, far more than we'll gain. (And you all know that if we could do massive do-overs, I'd get rid of put's auto-decode.)
>
> Instead, one can write:
>
>    class C { final: ... }
>
> as a pattern, and everything in the class will be final. That leaves the "but what if I want a single virtual function?" There needs to be a way to locally turn off 'final'. Adding 'virtual' is one way to do that, but:
>
> 1. there are other attributes we might wish to turn off, like 'pure' and 'nothrow'.
>
> 2. it seems excessive to dedicate a keyword just for that.
>
> So, there's the solution that has been proposed before:
>
>    !final
>    !pure
>    !nothrow
>    etc.

I am still not convinced about final-by-default. However, discussions here have proven that in many cases people would benefit from it.

So, how about we make a next major release branch, 2.1, appoint some 2.1 maintainers (Manu for an example, as he is one of the major forces behind this movement). These individuals will filter and merge changes in the 2.0 branch into the 2.1.

This will nicely allow companies to have a transition period from 2.0.x to 2.1.x at the time of convenience.

Kind regards

Le 13/03/2014 05:13, Mike a écrit :
> On Thursday, 13 March 2014 at 00:40:34 UTC, Vladimir Panteleev wrote:
>>>
>>> The saying goes, "you can't make a bucket of yogurt without a
>>> spoonful of rennet". The pattern of resetting customer code into the
>>> next version must end. It's the one thing that both current and
>>> future users want: a pattern of stability and reliability.
>>
>> 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?
>>
>
> IMO, one of the reasons D exists is all the historical baggage C/C++
> chose to carry instead of evolving.
>
> I can cite a business case I had the displeasure of working on as well.
> They chose not to evolve, and instead ended up spending $11 million
> years later to rewrite their infrastructure while maintaining the
> antiquated one so they could still function.  And the latter was never
> realized.  They're probably due for another large, time consuming,
> disruptive, expensive project in the near future.
>
> Point is, it's in the best interest of both languages and businesses
> building on those languages to evolve, or they just end up paying the
> piper later (with interest).
>
> Gradual, managed change is where it's at, IMNSHO.
>
Just like I proposed creating a new major version every year will be gradual with a know rhythm and well announced.

Le 13/03/2014 05:56, Sarath Kodali a écrit :
> On Thursday, 13 March 2014 at 00:40:34 UTC, 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.
>
> It won't happen that way if we evolve D such that it won't break
> existing code. Or manages it with long deprecation cycles. In 1989, ANSI
> C had come up with new function style without breaking old function
> style. After a while the new style has become the standard and the
> compilers gave warning messages. In D, we can issue "deprecated" messages.
>
>>
>> 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.
>
> That is true if your code is under active development. What if you had a
> production code that was written 2 years back?
>
> - Sarath
>

Why D was chosen for a production development 2 years back and development stopped? It's normally not an issue if :
 a) D is well known in the company
 b) Old D version still supported

For me it's clearly an issue to use a young language in a short term development, from start you already know it will be difficult to maintain (to few knowledge in the company, security issues, bugs,...)

Le 13/03/2014 07:47, Walter Bright a écrit :
> On 3/12/2014 10:30 PM, Manu wrote:
>> Again, this is conflating random breakage with controlled deprecation.
>> A clear message with a file:line that says "virtual-by-default is
>> deprecated,
>> add 'virtual' _right here_." is not comparable to the behaviour of
>> byLine()
>> silently changing from release to release and creating some bugs, or
>> std.json
>> breaking unexpectedly with no warning.
>
> In the case I experienced, I got a clear compiler message. I knew what
> to fix. It still sucked. It was "fixing" non-buggy code that was
> intentionally written that way.
>
> I don't have as much of a problem breaking things that were already
> broken and happened to work out of luck, but that isn't the case here.

Maybe if changes are really simple a tool can help? Tools are needed for such kind of refactoring can be done automatically.

For some old games I wrote a script converter cause we completely broke the syntax (from XML to Lua) with a version of our engine, we do that because news features of engine was requested for next games updates.
It can appear like a time wasting, but it was fun to do.

On Thursday, 13 March 2014 at 17:08:05 UTC, Xavier Bigand wrote:
> Le 13/03/2014 07:47, Walter Bright a écrit :
>
> Maybe if changes are really simple a tool can help? Tools are needed for such kind of refactoring can be done automatically.
>
> For some old games I wrote a script converter cause we completely broke the syntax (from XML to Lua) with a version of our engine, we do that because news features of engine was requested for next games updates.
> It can appear like a time wasting, but it was fun to do.

It's difficult to have such a tool in D that can safely handle
all situations (mixins in particular make it particularly
difficult). Though something probably be made that can handle the
vast majority of situations after being confirmed by the user
that the changes are acceptable.

On Thursday, 13 March 2014 at 16:41:32 UTC, Andrei Alexandrescu wrote:
> On 3/13/14, 9:23 AM, Daniel Murphy wrote:
>
>> 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.
>
> I have seen those messages as well. I have argued at length why I feel differently about this, including how I see the numbers working in this forum. As far as I can tell you are not convinced, so repeating those arguments would not help.

I think that this it's a bit unfair.

Just to be clear, we have committed a lot of money and effort in the D programming language, "smelling" years ago that it could be a competitive advantage over other choices.

Told that, I'm following the forum as this is by far the best way to reinforce of undermine my past decision (and sleep well at night!)
That why I think that, IMHO, companies that adopted D "seriously" are present here, and are lurking.

Just to give a perspective, we are not so big like Sociomantic but we are making some $M, so for us the decision was not a joke.

And to be honest what it's really scaring it's not the frequency of the "planned improvement" of the language, but that a feeling turned  "a solid piece of evidence" [1] into smoke. Today is virtual, tomorrow how knows?

That's my feedback for the community, and for the two leaders.

- Paolo

[1] http://forum.dlang.org/thread/yzsqwejxqlnzryhrkfuq@forum.dlang.org?page=23#post-koo65g:241nqs:242:40digitalmars.com