Final by default?

Xavier Bigand flamaros.xavier at gmail.com
Thu Mar 13 09:35:07 PDT 2014


Le 13/03/2014 05:23, Manu a écrit :
> On 13 March 2014 11:13, Walter Bright <newshound2 at digitalmars.com
> <mailto:newshound2 at 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.




More information about the Digitalmars-d mailing list