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

[Jonathan M Davis]

On Friday, November 16, 2018 3:41:10 PM MST H. S. Teoh via Digitalmars-d 
wrote:
> On Thu, Nov 15, 2018 at 07:49:32PM -0700, Jonathan M Davis via
> Digitalmars-d wrote: [...]
>
> > Honestly, over time, I've become increasingly convinced that the more
> > radical ideas would be incredibly undesirable (e.g. making const or
> > immutable the default).
>
> Actually, immutable by default would encourage better coding style, as
> well as potentially provide a small performance benefit by allowing the
> optimizer to take advantage of more things that don't need to be mutable
> (can elide certain loads even in the face of aliasing, can infer more
> loop invariants, etc.).

immutable by default would encourage a functional programming style
everywhere. I dispute that that's necessarily better. There are certainly
times that that's better, but it's often hell. What we have now allows us to
program functionally when we want to without forcing it, whereas having
immutable by default would lean heavily towards forcing it. It also would
not play well with D being a systems language or with D interacting with C
or C++. Honestly, having D3 be const or immutable by default is the sort of
choice that would make me seriously consider quitting D.

> > In any case, I think that _most_ of the things that should go in
> > something like D3 can be done in D2 so long as Walter and Andrei can
> > be convinced. For instance, we totally _could_ fix the nonsense about
> > treating bool as an integer type in D2. There's nothing about that
> > that requires D3.
>
> Yes, but cutting the legacy tie with C integer promotion rules would
> require D3.

It would, but given the insistence on C code being valid D code with the
same semantics or not being valid D code, I don't see that ever changing,
and that basic rule is critical for being able to easily port C code to D
without subtle bugs. So, while we can make some tweaks to the promotion
rules, I very much doubt that any version of D will ever be fully divorced
from C in that regard.

> > Unfortunately, of course, Walter and Andrei weren't convinced by the
> > DIP that would effectively have fixed that by removing the implicit
> > conversions from integer literals to bool, so that's not happening in
> > D2 unless something drastic changes, and as such, I see no reason to
> > expect that it would happen in D3.
>
> I was very disappointed at the rejection, in fact.  I suppose you have a
> point that if we were to start over from a blank slate like D3, it will
> probably still stay that way.  But if I had any say in how D3 would be
> done, I would definitely say treat bool as a non-numerical type, and
> require a cast if for whatever reason you decide to treat it as such.
> It makes intent so much clearer, and IMO leads to better code (just like
> when pointers stop implicitly converting to bool -- I was initially
> annoyed, but in retrospect appreciated the much improved readability of:
>
>   if ((p = func()) !is null) ...
>
> over the terse but cryptic:
>
>   if ((p = func())) ...
>
>
> [...]
>

Technically, implicit conversions have nothing to do with if statements
anyway. Weird as that may be, that's an implicit, explicit conversion in
that the compiler implicitly inserts a cast. So, even types which don't have
implicit conversion still work with if statements as long as they have an
explicit conversion to bool. In general though, I do agree that being more
explicit with conditionals is better.

In any case, the point I was trying to make was that if Walter and Andrei
can't be convinced of something like removing the implicit conversion of
integer literals to bool for D2, I find it highly unlikely that they'll be
convinced of it for D3. It might be that they'll be more open to a change
for D3 if the reason that they don't want to make the change in D2 is a
concern about code breakage, but aside from that, convincing them to change
something for D2 and D3 is probably going to be pretty much the same. In
plenty of cases, concerns about code breakage have nothing to do with it.

In general, it's just plain hard to convince Walter and Andrei that a
particular feature or language change is a good idea. Whether you're talking
about D2 or D3 doesn't really change that. D3 just removes many of the code
breakage concerns from the equation. Either way, any DIP is has an uphill
battle, and I think that most DIPs that provide real value could make it
into D2 and don't require D3. The trick - as always - is convincing Walter
and Andrei. So, I don't see how talk of D3 fixes anything really. The kind
of stuff that you're unhappy about seems to mostly be stuff that Walter
doesn't agree with anyway, so it's not stuff that he'd fix in D3, and a lot
of it, he could fix in D2. Ultimately, it comes down to convincing Walter
and Andrei. It may eventually come to creating a D3 and fixing some issues
that we couldn't fix in D2, but without first convincing Walter and Andrei
of various issues, such a version bump would be pointless, and if we
convince them first, most of the issues can be resolved even without such a
version bump.

> > In a large program, it can very much be worth going to the extra
> > effort of making your program work with a lot of extra attributes, but
> > they often just get in the way, and forcing them on all programs by
> > default would easily risk making D miserable to work in by default.
>
> Attribute inference is the way to go.  *Nobody* wants to waste time
> manually annotating everything.  Boilerplate is evil.  In D2 Walter
> couldn't pull off across-the-board attribute inference, mainly because
> of backward compatibility, among other issues.  In D3 we could
> potentially build this in by default from the beginning, and it would
> save so many headaches.
>
> > LOL. Walter's comment at dconf this year that he wished D had const as
> > the default definitely makes me that much more leery of D3 ever
> > arriving, since I increasingly avoid const in D.
>
> So you're essentially going back to D1? ;-)

In terms of const? You read my article on it, so you should know where I
stand on it. I don't think that either C++ or D got it right, but I also
don't know what const would look like if it were done right. Either way, I
sure don't want it to be the default. It's way to restrictive. If it were
the default, I'd be forced to mark code with mutable (or whatever the
keyword would be) everywhere. The same if immutable were the default. It
would not be fun.

> Seeing as the default answer to large-scale language changes these days
> seem to be "no, because it would break too much code", I think D3 would
> allow an opportunity to make large-scale changes that we otherwise
> wouldn't dare to in D2.

It would, but at the same time, we also have to be able to have a language
that we can be using in production and continue to use in production. Having
it change slowly over time is one thing. Having it change drastically like
that is something else entirely. At some point, it may make sense to create
a D3, but I think that we should have a much better idea of what we want to
change that we can't change now when we get to that point. We really don't
have that right now. At most, it seems like D3 is the sort of thing that
gets brought up when someone has an individual change that they want that
gets shot down. As far as I can tell, there isn't even vaguely a cohesive
group of changes that the main group of contributors agree on that they'd
like to see happen that can't happen at this point, let alone the community
at large. AFAIK, Walter and Andrei don't have a laundry list of things that
they'd like to do but can't, because it would break backwards compatibility.

If Walter and Andrei were to say tomorrow that they wanted to create D3,
they'd get bombarded with all kinds of stray ideas about how the language
should be changed. There wouldn't be anything approaching any kind of
agreement on what it should look like. Honestly, we have enough trouble
agreeing on what changes should be made to the language when we're
restricting ourselves to stuff that can be done transitionally within D2.

And honestly, when you consider that we can't even sort out stuff like
treating bool as an integer type, it just seems crazy to talk about jumping
off the deep end into D3, much as it would be nice to be able to make some
larger tweaks in some cases. I think that we that we first need to figure
out how to better fix D2 before we consider anything with D3 - and that's
without even considering any of the potential issues of forking the language
and community that comes with creating a new language version.

> One of the warts I'd like to see go the way of the dodo is the whole
> fiasco with Object.toString, Object.opEquals, etc., specifically how
> they interact with attributes in class methods.  And also the implicit
> Monitor object (when it's not needed).  Andrei had proposed ProtoObject
> as a D2 solution to this impasse, but I've yet to see any further
> progress since the initial discussion.

Yeah, but all of that stuff moves slowly, and technically, it does have to
go through the DIP process. It's a DIP that has yet to be approved, even if
it's probably a shoe-in. Also, it's at least sort of related to the copy
constructor DIP, and at least that is moving along, albeit slowly. If I
understand correctly, it's about to move into the next stage.

I think that the biggest question is really who's going to implement the
ProtoObject stuff, since Andrei isn't a compiler dev. That's the weakest
link in any case like this. Whenever someone comes up with an idea, and
they're not set up to be the one to implement it, there's always a risk of
it sitting in limbo for a while. But my guess is that at some point, Andrei
will stick one of his students on it.

The bigger concern I see is what's been the related hold-up with removing
all of that muck from Object for years and that's the AA implementation. I
know that Martin did a bunch of work on it, but I don't where any of that
stands. However, without it being replaced, there will likely be serious
issues when ProtoObject comes into the picture.

- Jonathan M Davis