It is the year 2020: why should I use / learn D?

[Jonathan M Davis]

On Thursday, November 15, 2018 4:44:00 PM MST H. S. Teoh via Digitalmars-d 
wrote:
> On Thu, Nov 15, 2018 at 10:29:56PM +0000, Stanislav Blinov via 
Digitalmars-d wrote:
> > On Thursday, 15 November 2018 at 19:54:06 UTC, H. S. Teoh wrote:
> > > On Thu, Nov 15, 2018 at 11:17:43AM -0800, Ali Çehreli via
> > > Digitalmars-d
> > >
> > > wrote:
> > > > "We don't want C++ become like COBOL." My answer is, C++ is
> > > > heading exactly the same place not through natural death but
> > > > through those improvements.
> > >
> > > [...]
> > >
> > > And that's the problem with C++: because of the insistence on
> > > backward compatibility, the only way forward is to engineer
> > > extremely delicate and elaborate solutions to work around
> > > fundamental language design flaws...
> >
> > Funny you should say that, as that same problem already holds D back
> > quite a lot. The Argument No.1 against pretty much any change in
> > recent years is "it will break too much code".
>
> Yes, this obsession with not breaking existing code is a thorn in D's
> side.  D is not quite at the point of C++, where *nothing* legacy can
> change (like getting rid of that evil preprocessor); we still have a
> process for deprecating old stuff.  A slow process, perhaps slower than
> many would like, but it has been happening over the years, and has
> cleaned up some of the uglier parts of the language / standard library.
>
> Still, it's sad to see that bad decisions like autodecoding probably
> won't ever be fixed, because it "breaks too much code".

C++ doesn't really have a process for deprecating old features or code. They
sort of do, but not really. We do have that ability and use it, which helps,
but we still have the basic tension between code continuing to work and
being able to move the language and standard library forward. No one likes
coming back to their code and finding that it doesn't work anymore. They
want it to work as-is forever. And yet everyone also wants new features. And
they want the old cruft gone. Balancing all of that is difficult. I'm not
saying that we're necessarily doing a fantastic job of that, but there isn't
an easy answer, and no matter what answer you pick, some portion of the user
base is going to be annoyed with you. We can't both be completely stable and
completly flexible. A balance of some kind must be struck. It remains to be
seen whether we're managing to strike a good balance or whether we'll do so
in the future.

As for features like auto-decoding, the core problem is how much they have
their tendrils in everything. When it's a straightforward process to
deprecate something, then it's a pretty simple question of whether we think
the change is worth the breakage that it causes, but when it affects as much
as auto-decoding does, it becomes very difficult to even figure out _how_ to
do it. Honestly, I think that that's the biggest thing that's prevented
removing auto-decoding thus far. It's not that someone proposed a plan to
Walter and Andrei and they rejected it, because it was going to break too
much code. No one has even proposed a plan that was feasible - at least not
if you care about having any kind of transition process as opposed to
immediately breaking tons of code (potentially in silent ways in some
cases). AFAIK, pretty much the only plan that we have right now that would
would would amount to creating D3 - or at least would basically mean
throwing out the version of Phobos that we have, which isn't much different.
Either way, it would mean completely forking the existing code base and
community, and we really don't want to do that. We want a plan that involves
removing auto-decoding in D2 in place.

The first step in that whole mess, which really has not been done anywhere
near the level that it needs to be done, is to ensure that Phobos in general
doesn't care whether a range of characters is of char, wchar, dchar, or
graphemes. Many of the specializations for strings do still need to be there
to avoid auto-decoding (at least as long as auto-decoding is there), but a
lot of the code assumes that ranges of characters are ranges of dchar, and
it _all_ needs to work with ranges of char, wchar, dchar, and graphemes.
Once it's reasonably character-type agnostic (and what that means exactly is
going to vary depending on what the function does), then we can sit back and
see how much in the way of auto-decoding tendrils are left. At minimum, at
that point, code like byCodeUnit is then going to work as well as it can,
even if we can't actually remove auto-decoding. Until that's done,
byCodeUnit and its ilk are going to keep running into problems in various
places when you try to use them with Phobos. As it stands, when using them
with Phobos, they work sometimes, and other times, they don't. So, that work
is necessary regardless of what happens with auto-decoding. But once that
work is done, it may very well be that we can finally find a way to get rid
of auto-decoding. I don't know. I still question it given how it's tied into
arrays and UFCS, making it so that we can't properly use the module system
to deal with conflicts, but at least at that point, we'll have done the work
that needs to be done that surrounds the problem, and it's work that needs
to be done whether we get rid of auto-decoding or not.

*sigh* Honestly, auto-decoding is almost a perfect storm of issues for us
being able to actually get rid of it. So, while I agree with you that we'd
ideally fix the problem, it's _not_ an easy one to fix, and really the only
"easy" way to fix it is to pretty much literally say "D3" and hard break all
code. I think that the reality of the matter is that there are issues in
every language that you can't fix without either creating a new language or
creating a new version of the language that's not backwards compatible with
the old one (which then forks the language and community). So, while we'd
very much like to fix everything, there are going to be some things we
simply can't fix if we're not willing to create D3, and talking about D3
creates a whole other can of worms, which I don't think we're even vaguely
ready for yet. Maybe auto-decoding will turn out to be fixable, maybe it
won't, but I think that it's going to be inevitable that _some_ things will
be unfixable. I love D, but it's never going be perfect. No programming
language will be, much as I would love to use one. We should do the best
that we can to approach perfection, but we're going to miss in some places,
and as it stands, we definitely missed when it comes to auto-decoding.

- Jonathan M Davis