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)
