Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!

Subject: Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-03-18 01:19:17

> Of course WG21 could have simply accepted the library after it went
> through years of development and reviews, rather than trying to "fix"
> it. This is precisely why WG21 should not be involved in innovation and
> design, because then acceptance becomes a matter of opinion and
> politics, rather than a simple acknowledgement of an interface that is
> already successful.

Like Boost, they declare changes which must be made before acceptance.
For some features e.g. Coroutines, it ends up being an awful lot of
discussion but ultimately very few actual changes other than naming. For
others e.g. Filesystem, probably Networking, it becomes how long is a
piece of string. Back when Gor started down the standards route for
Coroutines, I remember warning him over a burger on a park bench in
Aspen just how long a piece of string he could end up upon. He ended up
proving me wrong, I am glad to say, just seven years approx start to
finish. But it looked at the time to be a decade plus effort to reach
consensus for his proposal.

For any reasonably disruptive change, you've got to sign on to investing
a decade plus of your life to reach standards fruition. Given that we
all get maybe thirty to forty years of professional career, that's a
very big claim on your productive years.

>> I'd echo Eric's sentiments on this completely. I don't have it in me to
>> ever get a fundamentals library into Boost again. Besides, I'd likely
>> end up getting divorced and my children no longer speaking to me. It's
>> not worth it, personally speaking.
> 
> You leave out the other possibility, to leave the library out of the
> standard, where most libraries, including good libraries, belong.

The same argument would then apply to Boost by this logic. I'm not sure
that I agree with that.

The usual counterargument to standardising ever more libraries generally
involves a decent centralised package ecosystem for C++, and sure, I get
that that would avoid much over-eager standardisation. However Python
has world class centralised package management (albeit with a few
forks), yet in many people's opinion continues to aggregate too much
inferior functionality into its standard library given the extremely
high quality of substitutes in its package repos. In particular, some
people feel that an inferior library gets into Python's standard
library, when a much superior alternative does not. And that's because
the inferior library had a champion, and the superior library did not.

Ultimately it comes down to committee perception of champions. If
someone is willing to champion a library into the standard, in C++ and
Python it generally tends to happen eventually given enough application
of will by the champion. The people behind the core standard essentially
assume that those motivated enough to champion a proposal for as many
years/decades as needed deserve to eventually win, irrespective of the
fundamental utility of the standard library proposal.

Contrast that with C, where the default answer to proposals for new
library features is "no, unless you can *prove* its utter necessity for
the survival of the language/ecosystem".

The former attitude invites large committees, and scalability problems
with sheer numbers. The latter attitude dissuades people such that WG14
attendance is approx 20-30 people nowadays, down from 60+ plus a decade ago.

The correct attitude is somewhere in between these two approaches. But
it's very hard to aim down the middle. I've sat in WG21 watching a
library proposal which I personally felt didn't add enough value to be
worth the committee time to pass it. But equally, it's not a bad
proposal, I personally like the proposer, and nobody else in the room
objects because they're all probably thinking the same as me. So it goes
through, and displaces time which would have have been more productively
spent elsewhere.

Personally speaking, I would prefer to have problems of scalability due
to growth and numbers rather than problems of lack of enthusiasm. So I
vote for what WG21 is doing, rather than what WG14 is doing. Ultimately
ISO SC22 (Programming languages) is 99.9% volunteer-led, so you've got
to do whatever keeps bringing in the volunteers. If that means
over-standardisation in order to keep them coming, I think that's not a
terrible tradeoff given the alternative: people just stop caring to
bother at all.

Niall