bool (was DConf 2019 AGM Livestream)

[Jonathan M Davis]

On Tuesday, May 14, 2019 7:15:43 PM MDT Andrei Alexandrescu via Digitalmars-
d-announce wrote:
> On 5/14/19 2:00 AM, Mike Franklin wrote:
> > On Wednesday, 15 May 2019 at 00:23:44 UTC, Andrei Alexandrescu wrote:
> >> There are many clowny things in D, of which bool is at best somewhere
> >> beyond the radar. I suggest investing time * expertise in the larger
> >> ones.
> >
> > Once again, I disagree with what you think is important.  `bool` is a
> > fundamental type on which many things in D depend.
>
> I'd be hard pressed to find my style cramped by D's bool.

There are well-known issues where the current behavior causes bugs, and
personally, I'd prefer that the DIP have been accepted, but I have to agree
that it isn't a big problem. It's basically just one of those small warts in
the language that it would be nice to have fixed, and a number of the people
who come to D looking for a better language seem to want it to be absolutely
perfect and want every minor issue fixed. Unfortunately, while that would be
nice, it really isn't practical. Every language has warts, and if something
like this were the worst issue that D had, then we'd be _very_ well off.

> > If it doesn't work
> > right, neither will the features that depend on it.
> > But, that's your
> > decision, and there's little to nothing we can do about it, so I guess
> > we just accept the fact that D is clowny and deal with it; it's what so
> > many of us, so often do.
>
> (At any rate, going forward it's not me who needs convincing.) In my
> humble opinion, any language would have minor quirks, and a landmark of
> good engineering is attacking the right problems. That we even discuss
> just how bad bool is while we have no done deals for safety, reference
> counting, shared, package distribution/versioning, pay-as-you-go
> runtime, collections, ..., is a fascinating puzzle.

I think that in this case, it's a combination of it being a form of
bikeshedding (since the DIP is on an issue that's easy to understand and
have an opinion on) and that a DIP was written up for it and rejected. So,
some of the folks who disagree with the decison want to debate it and
somehow get a different decision.

In general though, I think that the problem with tackling harder problems
like ref-counting or shared or whatever is simply that it takes a lot more
time and effort, and most people either don't have that kind of time or
don't want to spend it on a hard problem (assuming that they even have
enough expertise to do so in the first place). It's easy to point out and
debate a small problem like how bool is treated like an integral type when
many of us don't think that that it should ever be treated as an integral
type, but it's much harder and more time-consuming to tackle the larger
problems. So, unfortunately, the harder problems are too frequently left by
the wayside. And as I'm sure you can attest to, even those of us who might
consider tackling the harder problems have enough on our plates already that
even if an issue is on our TODO list, it can easily be drowned out by other
issues.

Regardless, as a group, we do need to find ways to better tackle some of our
larger, more pressing problems. The small stuff does matter, and it's easier
to tackle, but if we're consistently trying to solve the small problems
without tackling the larger ones, then we have a serious problem.

- Jonathan M Davis