Le 13/03/2014 05:23, Manu a écrit :
On 13 March 2014 11:13, Walter Bright <[email protected] <mailto:[email protected]>> 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.
