Boost, not LEWG

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <[hidden email]> wrote:
> Why are people equating forums with SO?

That was my unfortunate mistake. I only used the comparison to
highlight how the immediacy of visiting a website is different from
having to register for a mailing list.

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
> On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <[hidden email]> wrote:
>> Why are people equating forums with SO?
>
> That was my unfortunate mistake. I only used the comparison to
> highlight how the immediacy of visiting a website is different from
> having to register for a mailing list.

You still have to register on StackOverflow.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
On Tue, 30 Jun 2020 at 11:03, Andrey Semashev via Boost <
[hidden email]> wrote:

> On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
> > On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <[hidden email]>
> wrote:
> >> Why are people equating forums with SO?
> >
> > That was my unfortunate mistake. I only used the comparison to
> > highlight how the immediacy of visiting a website is different from
> > having to register for a mailing list.
>
> You still have to register on StackOverflow.
>
>
Only to post, upvote and comment, etc. You don't have to register if you
want to visit and browse the questions and answers. If Boost moved to a
forum it'd be analogous.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
On 2020-06-30 18:30, Peter Barker via Boost wrote:

> On Tue, 30 Jun 2020 at 11:03, Andrey Semashev via Boost <
> [hidden email]> wrote:
>
>> On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
>>> On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <[hidden email]>
>> wrote:
>>>> Why are people equating forums with SO?
>>>
>>> That was my unfortunate mistake. I only used the comparison to
>>> highlight how the immediacy of visiting a website is different from
>>> having to register for a mailing list.
>>
>> You still have to register on StackOverflow.
>>
> Only to post, upvote and comment, etc. You don't have to register if you
> want to visit and browse the questions and answers. If Boost moved to a
> forum it'd be analogous.

You can browse mail list archive without registration.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
On Tue, 30 Jun 2020 at 17:12, Andrey Semashev via Boost <
[hidden email]> wrote:

> On 2020-06-30 18:30, Peter Barker via Boost wrote:
> > On Tue, 30 Jun 2020 at 11:03, Andrey Semashev via Boost <
> > [hidden email]> wrote:
> >
> >> On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
> >>> On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <[hidden email]
> >
> >> wrote:
> >>>> Why are people equating forums with SO?
> >>>
> >>> That was my unfortunate mistake. I only used the comparison to
> >>> highlight how the immediacy of visiting a website is different from
> >>> having to register for a mailing list.
> >>
> >> You still have to register on StackOverflow.
> >>
> > Only to post, upvote and comment, etc. You don't have to register if you
> > want to visit and browse the questions and answers. If Boost moved to a
> > forum it'd be analogous.
>
> You can browse mail list archive without registration.
>

I was just correcting your statement about needing to register on
StackOverflow.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
On 2020-06-30 19:32, Peter Barker via Boost wrote:

> On Tue, 30 Jun 2020 at 17:12, Andrey Semashev via Boost <
> [hidden email]> wrote:
>
>> On 2020-06-30 18:30, Peter Barker via Boost wrote:
>>> On Tue, 30 Jun 2020 at 11:03, Andrey Semashev via Boost <
>>> [hidden email]> wrote:
>>>
>>>> On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
>>>>> On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <[hidden email]
>>>
>>>> wrote:
>>>>>> Why are people equating forums with SO?
>>>>>
>>>>> That was my unfortunate mistake. I only used the comparison to
>>>>> highlight how the immediacy of visiting a website is different from
>>>>> having to register for a mailing list.
>>>>
>>>> You still have to register on StackOverflow.
>>>>
>>> Only to post, upvote and comment, etc. You don't have to register if you
>>> want to visit and browse the questions and answers. If Boost moved to a
>>> forum it'd be analogous.
>>
>> You can browse mail list archive without registration.
>
> I was just correcting your statement about needing to register on
> StackOverflow.

And I was pointing out that there is no difference between StackOverflow
and mailing list in terms of immediacy of access.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
So I'm going to chime in here, in aggregate. I will try to focus on
answering the question of "What is Boost Good For?" from the
perspective of a user, and as a user having participated in reviews.
It's a large brain dump, so there's probably typos and other bad
things.

[[ Boost and the Ecosystem ]]
In my opinion, Boost is not dead (no great software library is), but
it has waned in usefulness substantially. You don't even have to take
my word for it, Boost authors already did some basic sleuthing about
it:

https://www.reddit.com/r/cpp/comments/gfr46l/why_you_trust_in_boost/
https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/

You'll note that the "don't use boost" had many more comments and
upvotes, whereas the "trust in boost" had many less comments and
upvotes. Reading both confirms some of my own biases, which is that
Boost, as an ecosystem, does not offer a lot of bang for its buck
because it exists in a space where it competes with the Standard
Library, and does not complement it.

This creates an interesting problem. I could use Boost.Container's
vector, but what benefit does it offer me over std::vector, except
that it has more predictable performance characteristics in
now-10-year-old STLs? (It's not better than the current STL; I
measured.) I could use Boost's type traits, or I could require C++11,
work around GCC4.8 being a nightmare, and no longer have that source
dependency. I could use things from Boost.Core, but I could also just
move to C++11/14 and obsolete many of its usages. And so on, and so
forth.

Opting into the boost ecosystem is expensive, insofar that it's a
really bad trade for interop. I can't talk to external libraries with
Boost's vector, or its unordered map, optional (even if the Standard's
is strictly worse in every way), variant, etc.. Interoperability
matters, which means boost usage in "middleware" libraries -- at least
on its edges and boundaries -- drops off a cliff. Boost is not "the
glue that holds a really shitty C++ universe together" (C++03 and
before), it becomes "the thing that costs me maintenance hours and I
have to spend extra time supporting in my abstractions" (C++11 and
above).

Another point: note that Meeting C++'s survey about regular expression
showed that an OBSCENE number of people used std::regex, despite it
being the literal worst part of every std:: implementation (aside from
wstring_convert), with the reason "because it is there". You need to
make an EXTREMELY compelling sell to get more people to pick up your
library, and if the majority of your libraries are "compete with the
standard", you will lose even if the performance of the Standard is
actual dog poo. Speaking of performance...

[[ Boost and Performance ]]

Further hurting Boost's proposition in the ecosystem is its
performance characteristics and its inability to capitalize on
decades-old ideas. My computer is still shot so I cannot yield the
benchmarks and everything, but finding out that I could read 2 Boost
Author's std papers on allocations and other tricks (Howard Hinnant,
Ion Gaztanaga) and find that neither of the tangible performance gains
they described were implemented in Boost's Allocators or Containers
means I had absolutely no compelling reason to pick Boost over the
Standard for the thing I was rolling (in this case, my own std::vector
or other containers).

Boost -- for its basic abstractions -- do not provide compelling
improvements over the status quo for fundamental things for me to care
enough about Boost alternatives to core things to begin with. (This
changes with things like Peter Dimov's boost::variant2, which offer
tradeoffs I as an application developer are deeply interested in for
many domains, and thus pays off).

This speaks to the ways Boost is used now: for very specific use cases
not covered by the standard, and very specific performance metrics the
standard never will meet.


[[ Boost and Tradeoffs ]]

Unless I pick a very specific library (StaticString, SML, variant2,
Log, String Algorithms, ASIO, Beast, etc.) that offers me a very
tangible gain in "yes, absolutely, this accelerates my development and
has acceptable performance characteristics", Boost's general core is
not worth it. It's monolithic nature makes it hard to opt into many of
its smaller libraries "just because". Distribution is often an extreme
pain in the ass. Build system gripes are ripe in the reddit threads,
and there's been at least 3 (!!) official,
they-recorded-this-for-1+-hours-and-practiced-this-for-many-more-hours
talks about getting Boost to different build systems and modularizing
boost. If that isn't enough of an indication that Boost's method of
distribution maybe needs to be looked at more closely, I honestly
don't know how to explain the need better!

Before, that monolith was great: the Standard was, quite frankly, hot
steaming garbage so Boost's core made all that go away and provided
stability amongst the insanity of many compilers. That is not the case
anymore, and accepting the costs of the monolith in exchange for only
a handful of libraries is often a far worse trade, especially if that
library does not come with distinct gains. This is why people keep
asking for "Boost, but based on a higher standard"; this is not just
because "unga bunga cruft bad", it's because they want to see /more/
useful libraries that pushed the boundaries of C++ farther out than
ever before, just like Boost did in the 2000's.


[[ Boost and The People's Needs ]]

As I stated before, people's needs have shifted. C++ is not The
Badlands anymore, and even MSVC is coming out to play nice. Boost is
having a problem addressing the needs people have, today, which are
sometimes extremely niche. This is why I am partly disappointed by the
result of the Text Review.

As I stated in my review, Text in C++ sucks. Boost does not do better
than the Standard, save for some string algorithms and some basic
Locale "improvements". This was a chance, even if not perfect, to
provide a library that really made Boost stand out as "has something
the Standard can only dream of". boost::text's "text" container -- as
the kids would say -- slapped. Grapheme cluster iterators, utf8
storage, insertion and removal based on what most people perceive as
characters handled transparently for me?? That's the wet dream of text
management. Coupled with a Stepanov reimagining of Standard Unicode
algorithms that were just a straight translation of the pointer-based,
weird ICU interfaces, absolutely. Yes, not having allocators was
terrible and not having the ability to choose underlying encoding
sucked, but it got *most* people a good chunk of the way. There was
room for going backwards and filling out the problems in v2.

Not having the library -- and encouraging the text layer not to come
back as part of the next resubmission of the library -- is a huge blow
to "this really addresses one of the serious contemporary C++
problems". Maybe Zach will resubmit that layer, but we missed out on
the sweet spot of addressing a need that neither Standard C++ nor most
shops handle nicely. I do hope the library comes back!

This also speaks to LEWG. In all frankness, if Boost's purpose is to
be invalidated by the Standard every 3 or 6 years, why waste the time
submitting to Boost when Boost is just "standard, but outside and
sometimes before the standard"? If your goal becomes "Lots of C++11
that fill the gaps", well then duh nobody's going to submit new stuff
to Boost because you've made it explicitly clear your job is being a
polyfill for old libraries, not providing new, cutting edge libraries
like 20-years-ago Boost was.


[[ In Conclusion ]]

Boost is successful. Not was: is. But its original space has been
consumed by the standard, and if we want to enjoy a "Boost
Renaissance", we need to address people's needs and meet them where
they are, rather than keep trying to pull them into a way of Boost
that is, quite frankly, no longer necessary in many ways. Higher
standards. Libraries that provide good tradeoffs. Libraries that
address the needs that are going out in front of people today, not the
needs 10 or 15 years ago.

Boost may need to actually reach out to people and very much handhold
them through the process of library submission, review, and
improvement to convince a few key cases that Boost is still extremely
relevant to modern needs. Maybe that will bring in even more folk;
encourage them to submit here, once they see that Boost libraries are
once more the place to go to solve real problems, with a tangible
feedback loop. Right now it's hard to gauge the effect of a Boost
library, since Boost is doing very little to distinguish itself from
the Standard (again, why go through Boost if you can do GitHub + LEWGI
+ LEWG + LWG instead?). Boost should be the cutting edge again. This
does not mean the quality has to go down: but there should be active
encouragement of exploration of new topics OR addressing people's
needs. Boost.Text, Boost.Unicode, maybe even Boost.Audio, and more...


[[ Mailing Lists and Tools In General ]]
Mailing lists are fine for power users. And yes, I really mean power users!

This could be my young buck inexperience showing, but there is a real
problem with having to manage a lot of these things yourself. While
people can configure amazing awesome mail clients capable of great
feats, most of us don't have anything like that. Some small examples:
- I had no idea what "top posting" was until someone informed me that
(by default) g-mail's reply feature was automatically top posting.
There is, of course, no way to change this in the options, but it is
still against Boost etiquette to do so. So now I need to manually
relocate the start of my post, and I have to do this every time I
start an e-mail.
- Tracking threads is hilarious in an e-mail client. This single post
has ended up in 3-4 different threads, sometimes because some people's
mailing client clears out response IDs and other times because it was
a deliberate fork. I have no idea, and now I have to track the 4
threads to this, often without any context of where this thing came
from even if I scroll up *this* thread in particular.
- Formatting. Boost's mailing list is nice enough to accept my HTML
e-mails, but I have no assurance my e-mails are <b>NOT</b> showing up
<i>strangely</i> for everyone now with weird things (so I have to
default to plain text and, essentially, make up some form of /markup/
in my head or use what I've observed about the mailing list).
Consistent formatting (e.g., "everyone uses markdown and that's what
renders") brokers a common ground between mailing list users for code
formatting, emphasis, and general text decorum / presentation.

Basically, mailing lists are wild-wild wests of formatting and
quality. A platform that got rid of that etiquette and just let me
conform to an established format (GitHub Issues, etc.) greatly lowers
the barrier to being able to speak up.

On Tue, Jun 30, 2020 at 12:41 PM Andrey Semashev via Boost
<[hidden email]> wrote:

>
> On 2020-06-30 19:32, Peter Barker via Boost wrote:
> > On Tue, 30 Jun 2020 at 17:12, Andrey Semashev via Boost <
> > [hidden email]> wrote:
> >
> >> On 2020-06-30 18:30, Peter Barker via Boost wrote:
> >>> On Tue, 30 Jun 2020 at 11:03, Andrey Semashev via Boost <
> >>> [hidden email]> wrote:
> >>>
> >>>> On 2020-06-30 12:42, Vinnie Falco via Boost wrote:
> >>>>> On Tue, Jun 30, 2020 at 12:39 AM Mike via Boost <[hidden email]
> >>>
> >>>> wrote:
> >>>>>> Why are people equating forums with SO?
> >>>>>
> >>>>> That was my unfortunate mistake. I only used the comparison to
> >>>>> highlight how the immediacy of visiting a website is different from
> >>>>> having to register for a mailing list.
> >>>>
> >>>> You still have to register on StackOverflow.
> >>>>
> >>> Only to post, upvote and comment, etc. You don't have to register if you
> >>> want to visit and browse the questions and answers. If Boost moved to a
> >>> forum it'd be analogous.
> >>
> >> You can browse mail list archive without registration.
> >
> > I was just correcting your statement about needing to register on
> > StackOverflow.
>
> And I was pointing out that there is no difference between StackOverflow
> and mailing list in terms of immediacy of access.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost, not LEWG

Boost - Dev mailing list
On 01/07/2020 05:44, JeanHeyd Meneide via Boost wrote:
> So I'm going to chime in here, in aggregate. I will try to focus on
> answering the question of "What is Boost Good For?" from the
> perspective of a user, and as a user having participated in reviews.
> It's a large brain dump, so there's probably typos and other bad
> things.

Firstly, this is a great reply. Erudite, useful, positive,
actions-based. Anybody who hasn't read all of it ought to.

What is especially noticeable is the focus on the end user experience
rather than constant giving out about other people and orgs not doing
things right in some Boost people's opinion.

> Not having the library -- and encouraging the text layer not to come
> back as part of the next resubmission of the library -- is a huge blow
> to "this really addresses one of the serious contemporary C++
> problems". Maybe Zach will resubmit that layer, but we missed out on
> the sweet spot of addressing a need that neither Standard C++ nor most
> shops handle nicely. I do hope the library comes back!

I could not agree more with this point! Whilst yes, Unicode is the pain
point in the ecosystem, and yes, more standards targeted libraries ought
to go through Boost before LEWG, and yes, the most efficient use of
Zach's limited spare time is to concentrate on what is (relatively
speaking) easiest, it is actually replacing **std::string** which is the
golden calf needing slaughtering here.

I wouldn't wish achieving that on my worst enemy. It would be awful. But
it would also come with outsize improvements across the ecosystem in all
sorts of non-obvious ways. Like Outcome had. Improving strings and text
in C++ would be incredibly hard, but if successful, incredibly beneficial.

> Boost may need to actually reach out to people and very much handhold
> them through the process of library submission, review, and
> improvement to convince a few key cases that Boost is still extremely
> relevant to modern needs. Maybe that will bring in even more folk;
> encourage them to submit here, once they see that Boost libraries are
> once more the place to go to solve real problems, with a tangible
> feedback loop. Right now it's hard to gauge the effect of a Boost
> library, since Boost is doing very little to distinguish itself from
> the Standard (again, why go through Boost if you can do GitHub + LEWGI
> + LEWG + LWG instead?). Boost should be the cutting edge again. This
> does not mean the quality has to go down: but there should be active
> encouragement of exploration of new topics OR addressing people's
> needs. Boost.Text, Boost.Unicode, maybe even Boost.Audio, and more...

I don't personally think that would work. The cost benefit to getting
into Boost just isn't there. I did it once. I'll never do it again.

What I do think would work is if Boost v2 becomes a peer anointed
collection of Boost-endorsed third party libraries bundled into a
distribution i.e. getting into Boost means that your library ships with
every Linux and Windows distro thenceforth, a common distribution channel.

This means that "getting into Boost" shifts from the author doing the
driving into the Boost community choosing a set of rules by which
popular C++ libraries are selected for candidacy (e.g. >= 5 years
maintained, permissive licence, STL naming conventions, widely portable
etc), and then persuading the author to undertake any changes which a
peer review decides upon.

That effectively turns Boost into a highly selective package manager. I
find that just fine.

(Note that current Boost v1 ought to remain as-is, package-manager Boost
would be a separate v2)

> Basically, mailing lists are wild-wild wests of formatting and
> quality. A platform that got rid of that etiquette and just let me
> conform to an established format (GitHub Issues, etc.) greatly lowers
> the barrier to being able to speak up.

I find the mailing list stuff greatly overdone. "Young people" have no
problem with mailing lists if there is a motivation to join. Back when I
was applying myself at Boost, we had a constant incoming stream of new
blood, because I was going out there and setting up a pipeline to bring
young people into Boost. Some even tried their hand at getting a library
into Boost. Only one succeeded, but all of them figured out mailing
lists just fine, and they joining up here caused other young people to
also sign up. But since I moved on, that pipeline has dried up, so
mailing list traffic has dropped, vitality has ebbed etc etc.

Participation and relevance doesn't "just happen". It occurs when an
investment in making it happen occurs over many years. WG21 grows every
year because there is a bunch of people investing in making it grow
every year. Boost has not grown every year recently because the people
who were investing in its growth a few years ago have moved on, so right
now there is a lull. I'd like to hope that instead of complaining about
others over which Boost folk have no control and indeed just look bitter
by the constant complaining, some here might consider stepping up and
investing effort outside the ivory tower, create vitality, restore
relevance, by *engaging* with the ecosystem and its current needs
instead of complaining about it.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123