[epochs] Proposal for an epoch-based organization of Boost libraries

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
Hi,

Prompted by general feelings about Boost perceived lack of modernization
and internal "bloat",
and after an explicit survey on what users dislike about Boost [1], I
decided to try and write a more
or less fleshed out proposal for an epoch-based organization of Boost
libraries. I've extensively
tested and refined the proposal during discussions on Reddit and the
Boost Slack channel,
and I feel this is now ready for presentation at the mailing list:

https://github.com/joaquintides/boost_epoch/blob/master/README.md

I hope the proposal can start a productive conversation. Looking forward
to your feedback.

Best,

Joaquín M López Muñoz

[1]: https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/


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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
On 2020-05-23 12:56, Joaquin M López Muñoz via Boost wrote:

> Hi,
>
> Prompted by general feelings about Boost perceived lack of modernization
> and internal "bloat",
> and after an explicit survey on what users dislike about Boost [1], I
> decided to try and write a more
> or less fleshed out proposal for an epoch-based organization of Boost
> libraries. I've extensively
> tested and refined the proposal during discussions on Reddit and the
> Boost Slack channel,
> and I feel this is now ready for presentation at the mailing list:
>
> https://github.com/joaquintides/boost_epoch/blob/master/README.md
>
> I hope the proposal can start a productive conversation. Looking forward
> to your feedback.

 From the article:

 > if you were writing a new candidate Boost library with C++11 as its
baseline, would you strive to use std components rather than their Boost
counterparts, no matter how good the latter are? I would say you would.

I would not. As a user (either in-Boost or external) I would choose the
library that is technically better. Boost.Regex is actually a very good
example of such, as it is considerably faster than at least some popular
std::regex implementations. There are other examples where Boost
equivalents are technically better in one regard or another than the
standard counterparts.

I do not think discouraging use of (better) Boost libraries just because
there is a counterpart in the standard library is a good idea. Using the
best available tool should be a welcome choice on Boost developers side.

Next, I disagree with the idea that a library could be "not allowed to
progress". Why block further improvements and extensions? Take
Boost.Atomic or Boost.FileSystem, for example. These libraries are not
equivalent to the standard counterparts, and offer extensions that are
useful in practice and cannot be efficiently implemented "on top" of the
standard components. What would be the point of a Boost.Atomic v2 if it
had to reimplement Boost.Atomic? We are spreading our time thin as it is
already.

The above examples are not an exception. I think, almost every library
that was adopted by the standard is not equivalent to the standard
component. Some of them have continued to evolve since adoption, and
results of this evolution may be adopted by the standard in the future.
I see no point in creating new versions of such libraries on each
iteration of such adoption.

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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
 > general feelings about Boost perceived lack> of modernization
> ... proposal for an epoch-based organization> of Boost libraries
I would welcome this. It does, however, sound likea reather large undertaking.
In a smaller but similar situation, I was once motivatedin my own research to identify various time epochsin C++.
Probably similar to others, I identified for my purposes:
1) Pre-C++11 (basically C++03)2) C++11 but no more.3) C++ newest
Intuitively, I think number 2 is a great first stepin moving and migrating toward moden C++.Most compilers are conformant with modernC++11 now, even embedded systems compilers.

Kind regards, Chris
    Am Samstag, 23. Mai 2020, 11:57:26 MESZ hat Joaquin M López Muñoz via Boost <[hidden email]> Folgendes geschrieben:  
 
 Hi,

Prompted by general feelings about Boost perceived lack of modernization
and internal "bloat",
and after an explicit survey on what users dislike about Boost [1], I
decided to try and write a more
or less fleshed out proposal for an epoch-based organization of Boost
libraries. I've extensively
tested and refined the proposal during discussions on Reddit and the
Boost Slack channel,
and I feel this is now ready for presentation at the mailing list:

https://github.com/joaquintides/boost_epoch/blob/master/README.md

I hope the proposal can start a productive conversation. Looking forward
to your feedback.

Best,

Joaquín M López Muñoz

[1]: https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/


_______________________________________________
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: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, 23 May 2020 at 06:25, Andrey Semashev via Boost <
[hidden email]> wrote:

> On 2020-05-23 12:56, Joaquin M López Muñoz via Boost wrote:
> > Hi,
> >
> > Prompted by general feelings about Boost perceived lack of modernization
> > and internal "bloat",
> > and after an explicit survey on what users dislike about Boost [1], I
> > decided to try and write a more
> > or less fleshed out proposal for an epoch-based organization of Boost
> > libraries. I've extensively
> > tested and refined the proposal during discussions on Reddit and the
> > Boost Slack channel,
> > and I feel this is now ready for presentation at the mailing list:
> >
> > https://github.com/joaquintides/boost_epoch/blob/master/README.md
> >
> > I hope the proposal can start a productive conversation. Looking forward
> > to your feedback.
>
>  From the article:
>
>  > if you were writing a new candidate Boost library with C++11 as its
> baseline, would you strive to use std components rather than their Boost
> counterparts, no matter how good the latter are? I would say you would.
>
> I would not. As a user (either in-Boost or external) I would choose the
> library that is technically better. Boost.Regex is actually a very good
> example of such, as it is considerably faster than at least some popular
> std::regex implementations. There are other examples where Boost
> equivalents are technically better in one regard or another than the
> standard counterparts.
>

The Microsoft STL is now open source (I'm sure you've all heard about it),
So in the case of Microsoft, it suffices to create a PR and upstream the
better boost library. I believe (to know) for boost::regex this has already
happened or is going to happen. Boost should adopt <charconv> from
Microsoft.

degski
--
@systemdeg
"We value your privacy, click here!" Sod off! - degski
"Anyone who believes that exponential growth can go on forever in a finite
world is either a madman or an economist" - Kenneth E. Boulding
"Growth for the sake of growth is the ideology of the cancer cell" - Edward
P. Abbey

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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, 23 May 2020 at 06:25, Andrey Semashev via Boost <
[hidden email]> wrote:

> Next, I disagree with the idea that a library could be "not allowed to
> progress". Why block further improvements and extensions? Take
> Boost.Atomic or Boost.FileSystem, for example. These libraries are not
> equivalent to the standard counterparts, and offer extensions that are
> useful in practice and cannot be efficiently implemented "on top" of the
> standard components. What would be the point of a Boost.Atomic v2 if it
> had to reimplement Boost.Atomic? We are spreading our time thin as it is
> already.
>

The progression could be signified by another 'insertion mode' : increases
begin(*X*) and executes end(*X*) = begin (*X*) +1.

The epoch proposal is nice, thumbs up.

degski
--
@systemdeg
"We value your privacy, click here!" Sod off! - degski
"Anyone who believes that exponential growth can go on forever in a finite
world is either a madman or an economist" - Kenneth E. Boulding
"Growth for the sake of growth is the ideology of the cancer cell" - Edward
P. Abbey

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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2020-05-23 18:56, degski via Boost wrote:

> On Sat, 23 May 2020 at 06:25, Andrey Semashev via Boost <
> [hidden email]> wrote:
>
>> On 2020-05-23 12:56, Joaquin M López Muñoz via Boost wrote:
>>> Hi,
>>>
>>> Prompted by general feelings about Boost perceived lack of modernization
>>> and internal "bloat",
>>> and after an explicit survey on what users dislike about Boost [1], I
>>> decided to try and write a more
>>> or less fleshed out proposal for an epoch-based organization of Boost
>>> libraries. I've extensively
>>> tested and refined the proposal during discussions on Reddit and the
>>> Boost Slack channel,
>>> and I feel this is now ready for presentation at the mailing list:
>>>
>>> https://github.com/joaquintides/boost_epoch/blob/master/README.md
>>>
>>> I hope the proposal can start a productive conversation. Looking forward
>>> to your feedback.
>>
>>   From the article:
>>
>>   > if you were writing a new candidate Boost library with C++11 as its
>> baseline, would you strive to use std components rather than their Boost
>> counterparts, no matter how good the latter are? I would say you would.
>>
>> I would not. As a user (either in-Boost or external) I would choose the
>> library that is technically better. Boost.Regex is actually a very good
>> example of such, as it is considerably faster than at least some popular
>> std::regex implementations. There are other examples where Boost
>> equivalents are technically better in one regard or another than the
>> standard counterparts.
>
> The Microsoft STL is now open source (I'm sure you've all heard about it),
> So in the case of Microsoft, it suffices to create a PR and upstream the
> better boost library. I believe (to know) for boost::regex this has already
> happened or is going to happen. Boost should adopt <charconv> from
> Microsoft.

What if I don't use MSVC?

Also, I'm not sure compiler vendors would be willing to accept
non-standard extensions. Certainly, not all vendors would. Part of the
reason why Boost exists is that such extensions have a place to be and
could be used regardless of your compiler.

That said, I absolutely welcome improvements in standard libraries.

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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2020-05-23 19:15, degski via Boost wrote:

> On Sat, 23 May 2020 at 06:25, Andrey Semashev via Boost <
> [hidden email]> wrote:
>
>> Next, I disagree with the idea that a library could be "not allowed to
>> progress". Why block further improvements and extensions? Take
>> Boost.Atomic or Boost.FileSystem, for example. These libraries are not
>> equivalent to the standard counterparts, and offer extensions that are
>> useful in practice and cannot be efficiently implemented "on top" of the
>> standard components. What would be the point of a Boost.Atomic v2 if it
>> had to reimplement Boost.Atomic? We are spreading our time thin as it is
>> already.
>>
>
> The progression could be signified by another 'insertion mode' : increases
> begin(*X*) and executes end(*X*) = begin (*X*) +1.

I'm not sure what you mean here.

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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
On Sat, 23 May 2020 at 11:21, Andrey Semashev via Boost <
[hidden email]> wrote:

> On 2020-05-23 19:15, degski via Boost wrote:
> > On Sat, 23 May 2020 at 06:25, Andrey Semashev via Boost <
> > [hidden email]> wrote:
> >
> >> Next, I disagree with the idea that a library could be "not allowed to
> >> progress". Why block further improvements and extensions? Take
> >> Boost.Atomic or Boost.FileSystem, for example. These libraries are not
> >> equivalent to the standard counterparts, and offer extensions that are
> >> useful in practice and cannot be efficiently implemented "on top" of the
> >> standard components. What would be the point of a Boost.Atomic v2 if it
> >> had to reimplement Boost.Atomic? We are spreading our time thin as it is
> >> already.
> >>
> >
> > The progression could be signified by another 'insertion mode' :
> increases
> > begin(*X*) and executes end(*X*) = begin (*X*) +1.
>
> I'm not sure what you mean here.
>

Like in the proposal [in this idea] the library is frozen (kicked out), but
really not, the improvements that come after the frozen epoch are included
in an annual 'update', of that years epoch. So you can (should be able to)
keep on choosing between the boost and the std version on an epoch basis.
One can express this idea by begin(*X*) and executes end(*X*) = begin (*X*)
+1, as I suspect this rule will be implemented.

That was the gist of it.

degski
--
@systemdeg
"We value your privacy, click here!" Sod off! - degski
"Anyone who believes that exponential growth can go on forever in a finite
world is either a madman or an economist" - Kenneth E. Boulding
"Growth for the sake of growth is the ideology of the cancer cell" - Edward
P. Abbey

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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 5/23/2020 5:56 AM, Joaquin M López Muñoz via Boost wrote:

> Hi,
>
> Prompted by general feelings about Boost perceived lack of modernization
> and internal "bloat",
> and after an explicit survey on what users dislike about Boost [1], I
> decided to try and write a more
> or less fleshed out proposal for an epoch-based organization of Boost
> libraries. I've extensively
> tested and refined the proposal during discussions on Reddit and the
> Boost Slack channel,
> and I feel this is now ready for presentation at the mailing list:
>
> https://github.com/joaquintides/boost_epoch/blob/master/README.md
>
> I hope the proposal can start a productive conversation. Looking forward
> to your feedback.

I wrote cxx_dual anticipating the problem that end-users might be
disappointed that Boost libraries use other Boost libraries rather than
C++11 on up equivalent libraries. So I am not at all surprised by some
of the comments about Boost.

I have always been for each library reporting what level of C++ that
library supports, even in detail if the library optionally supports some
features of later C++ standards.

I do believe people overreact to dependencies, however. All good
software design involves reusing established code when necessary.
Reinventing code simply for the sake of less dependencies has always
seemed to me a fool's game, unless there is a very good practical reason
for not using established code.

I am totally against the idea that some code which works perfectly in
C++03, as well as all other C++ standard levels, needs to be
unnecessarily updated to some later C++ standard level in order to be
acceptable to anyone.




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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, May 23, 2020 at 10:56 AM degski via Boost <[hidden email]>
wrote:

>
> The Microsoft STL is now open source (I'm sure you've all heard about it),
> So in the case of Microsoft, it suffices to create a PR and upstream the
> better boost library. I believe (to know) for boost::regex this has already
> happened or is going to happen. Boost should adopt <charconv> from
> Microsoft.
>

Given the differing licenses not sure how that's possible.


--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net

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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
El 23/05/2020 a las 22:46, Edward Diener via Boost escribió:

> On 5/23/2020 5:56 AM, Joaquin M López Muñoz via Boost wrote:
>> Hi,
>>
>> Prompted by general feelings about Boost perceived lack of
>> modernization and internal "bloat",
>> and after an explicit survey on what users dislike about Boost [1], I
>> decided to try and write a more
>> or less fleshed out proposal for an epoch-based organization of Boost
>> libraries. I've extensively
>> tested and refined the proposal during discussions on Reddit and the
>> Boost Slack channel,
>> and I feel this is now ready for presentation at the mailing list:
>>
>> https://github.com/joaquintides/boost_epoch/blob/master/README.md
>>
>> I hope the proposal can start a productive conversation. Looking
>> forward to your feedback.
>
> I wrote cxx_dual [...]
>
> I do believe people overreact to dependencies, however. All good
> software design involves
> reusing established code when necessary. Reinventing code simply for
> the sake of less
> dependencies has always seemed to me a fool's game, unless there is a
> very good practical
> reason for not using established code.
>

In this particular case, there are two establshed codes: Boost and std.
Seems like some end
users strongly favor the latter as it's not perceived as a real
dependency in the sense that
additional libs need be downloaded etc.

> I am totally against the idea that some code which works perfectly in
> C++03, as well as all
> other C++ standard levels, needs to be unnecessarily updated to some
> later C++ standard
> level in order to be acceptable to anyone.


This looks somewhat at odds with one of the stated goals of your
cxx_dual lib:

"On a more practical basis the CXXD library is for:

 1. Programmers writing code not using C++11 syntax who still want to
    target some
    C++11 libraries if the code is compiled in C++11 mode.
    [...]"

Joaquín M Lopez Muñoz


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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
El 23/05/2020 a las 13:24, Andrey Semashev via Boost escribió:

> On 2020-05-23 12:56, Joaquin M López Muñoz via Boost wrote:
>> Hi,
>>
>> Prompted by general feelings about Boost perceived lack of
>> modernization and internal "bloat",
>> and after an explicit survey on what users dislike about Boost [1], I
>> decided to try and write a more
>> or less fleshed out proposal for an epoch-based organization of Boost
>> libraries. I've extensively
>> tested and refined the proposal during discussions on Reddit and the
>> Boost Slack channel,
>> and I feel this is now ready for presentation at the mailing list:
>>
>> https://github.com/joaquintides/boost_epoch/blob/master/README.md
>>
>> I hope the proposal can start a productive conversation. Looking
>> forward to your feedback.
>
> From the article:
>
> > if you were writing a new candidate Boost library with C++11 as its
> baseline, would you
> strive to use std components rather than their Boost counterparts, no
> matter how good
> the latter are? I would say you would.
>
> I would not. As a user (either in-Boost or external) I would choose
> the library that is
> technically better. Boost.Regex is actually a very good example of
> such, as it is considerably
> faster than at least some popular std::regex implementations. There
> are other examples
> where Boost equivalents are technically better in one regard or
> another than the standard
> counterparts.
>

Boost.Regex is admittedly a controversial point (as mentionedin the
proposal) due to its
superior quality to some std implementations. But there are other
components whose usage
I find it hard to justify, such as Boost.Array and Boost.Tuple (there
may be others).

Whatever the intrinsic qualities of these foundational libraries, they
seem to totally be
losing the PR battle against std counterparts (if that was a battle to
begin with, that is):

https://github.com/joaquintides/boost_epoch/blob/master/boost_vs_std.md


> [...]
>
> Next, I disagree with the idea that a library could be "not allowed to
> progress". Why block
> further improvements and extensions?


In the section quote from, "progress" means "be given the newer epoch
badge". I'm not
referring to preventing the author from evolving their lib, which is
their unalienable right.


> Take Boost.Atomic or Boost.FileSystem, for example. These libraries
> are not equivalent to the
> standard counterparts, and offer extensions that are useful in
> practice and cannot be
> efficiently implemented "on top" of the standard components. What
> would be the point of a
> Boost.Atomic v2 if it had to reimplement Boost.Atomic? We are
> spreading our time thin as
> it is already.
>
> The above examples are not an exception. I think, almost every library
> that was adopted by
> the standard is not equivalent to the standard component. Some of them
> have continued to
> evolve since adoption, and results of this evolution may be adopted by
> the standard in the
> future. I see no point in creating new versions of such libraries on
> each iteration of such adoption.


The crucial point here is to what degree this extra functionality in
Boost.X is actually used by other
Boost libraries when Boost.X is a dependency. I don't have hard data
(you don't provide any either)
but I suspect this degree is very low.

On a more philosophical note, one of the goals of Boost is:

"We aim to establish 'existing practice' and provide reference
implementations so that Boost
libraries are suitable for eventual standardization."

In this regard, Boost has been extremely successful up to C++11,
moderately so ever since.
But one aspect that wasn't planned or even discussed when Boost started
22 years ago is:
what do we do after standardization. Epochs is one answer to that.
Regardless of the merits
of this proposal, I think we owe ourselves a discussion around this
central topic of coexisting
with an evolving standard that is expected (and helped) to take over
much of the user base of
components originated outside.

Joaquín M López Muñoz


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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> On May 23, 2020, at 12:56, Joaquin M López Muñoz via Boost <[hidden email]> wrote:
>
> Hi,
>
> Prompted by general feelings about Boost perceived lack of modernization and internal "bloat",

User perceptions about bloat may be related to the download size.
I was curious what in the world makes it weight 600MB and dig around a bit to get an idea.

1) 33MB of lookup tables as part of math special functions - and
numbers are trailing zero padded, such as SC_(7.1529668608000000000000000000000000000000e+10) - (why?)
These are only used for tests, not part of the library per se.

2) There appears to be some huge source files which must have been generated by another computer program of some sort, files such as
    a) epsg_traits.hpp      in geometry - 2MB
    b) make_map50.hpp  in fusion/container - 5MB
    c) switch_50.hpp        in phoenix - 5MB

3) lots of binary files png, svg, bmp, pdf etc - e.g.
math documentation weights 50MB due to many svg and png

4) 80MB of docs which is not a problem, but some library has its own doc folder with many MB (duplicated?), often the largest subfolder by far is doc and tests also often far larger than actual code

5) ok so the source tree is huge, but maybe the installation is much smaller? Not really, include tree is 150MB and libs are 500MB

I have my suspicions about the wisdom of 2a,2b,2c, but to be clear I am not criticising the authors of these wonderful libraries --- only pointing out where the perceptions of bloat might be coming from. As a constructive proposal, maybe separating boost into three downloads - source,doc,tests - would help?

On another note, it is pretty clear that "eventually" boost will remove everything which is in STL now, but the time is not now.
But the time is right for decreasing mutual dependencies within boost by replacing stuff with STL equivalents and potentially make more libraries available on standalone basis. Potentially, some people might prefer to keep releasing updates under 1.XX under traditional structure and jump to boost 2.0 for a new boost using STL whenever possible.

Best Regards,
Kostas

=========================================
Institute of Nuclear and Particle Physics
NCSR Demokritos
http://inspirehep.net/author/profile/K.G.Savvidy.1
https://github.com/kotika/random
https://mixmax.hepforge.org


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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 5/24/2020 4:20 AM, Joaquin M López Muñoz via Boost wrote:

> El 23/05/2020 a las 22:46, Edward Diener via Boost escribió:
>> On 5/23/2020 5:56 AM, Joaquin M López Muñoz via Boost wrote:
>>> Hi,
>>>
>>> Prompted by general feelings about Boost perceived lack of
>>> modernization and internal "bloat",
>>> and after an explicit survey on what users dislike about Boost [1], I
>>> decided to try and write a more
>>> or less fleshed out proposal for an epoch-based organization of Boost
>>> libraries. I've extensively
>>> tested and refined the proposal during discussions on Reddit and the
>>> Boost Slack channel,
>>> and I feel this is now ready for presentation at the mailing list:
>>>
>>> https://github.com/joaquintides/boost_epoch/blob/master/README.md
>>>
>>> I hope the proposal can start a productive conversation. Looking
>>> forward to your feedback.
>>
>> I wrote cxx_dual [...]
>>
>> I do believe people overreact to dependencies, however. All good
>> software design involves
>> reusing established code when necessary. Reinventing code simply for
>> the sake of less
>> dependencies has always seemed to me a fool's game, unless there is a
>> very good practical
>> reason for not using established code.
>>
>
> In this particular case, there are two establshed codes: Boost and std.
> Seems like some end
> users strongly favor the latter as it's not perceived as a real
> dependency in the sense that
> additional libs need be downloaded etc.
>
>> I am totally against the idea that some code which works perfectly in
>> C++03, as well as all
>> other C++ standard levels, needs to be unnecessarily updated to some
>> later C++ standard
>> level in order to be acceptable to anyone.
>
>
> This looks somewhat at odds with one of the stated goals of your
> cxx_dual lib:
>
> "On a more practical basis the CXXD library is for:
>
> 1. Programmers writing code not using C++11 syntax who still want to
>     target some
>     C++11 libraries if the code is compiled in C++11 mode.
>     [...]"

I do not see why you think the statement above is at odds with what I
previously asserted. Whatever might have been added to a Boost library
which became a C++ standard library in C+11 or beyond could hardly have
been done just to add unnecessary features. I am not against a library
being updated to use features of a later C++ standard when those updates
are predicated on improving a library in specific ways that make it
worthwhile to add such features.

The gist of your proposal which seems to me to be highly flawed is the
idea that at a certain Epoch level all dependencies of a library must
also exist at that same Epoch level or higher. How realistic is such a
goal ? If library X at Epoch level nnn successfully uses library Y at
Epoch level nnn-1, why should library Y be arbitrarily updated for no
good practical reason to use C++ features of Epoch level nnn ? I am
pretty sure you can see the absurdity of such a determination as that.


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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Joaquin M López Muñoz wrote:

> Boost.Regex is admittedly a controversial point (as mentionedin the
> proposal) due to its superior quality to some std implementations.

There's nothing controversial about it. As of 2020, it should always be
preferred over std::regex.


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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
 

 

> -----Original Message-----

> From: Boost <[hidden email]> On Behalf Of Joaquin M López Muñoz via Boost

> Sent: 23 May 2020 10:56

> To: [hidden email]

> Cc: Joaquin M López Muñoz <[hidden email]>

> Subject: [boost] [epochs] Proposal for an epoch-based organization of Boost libraries

>

> Hi,

>

> Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and

> after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less

> fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and

> refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now

> ready for presentation at the mailing list:

>

> https://github.com/joaquintides/boost_epoch/blob/master/README.md

>

> I hope the proposal can start a productive conversation. Looking forward to your feedback.

 

Your epoch ideas have merit, but some disadvantages.

 

But I fear that (like other projects like Cmake) the BIG hurdle that we struggle to get over, is *resources*.

 

And particularly, resources to update *all* existing libraries in any way.

 

Boost does have a lot of dependencies, but they are there for excellent reasons.

 

Documentation is a big part of the distribution (guilty) , but are needed by most.

 

Tests and tests data are another area that many users rarely use, but separately them would be a big task.

 

It is true that Boost has become very big, but Boost is only taking up space on builder's disks, not in end-users executables.

 

If we could do something positive, it would be to make much clearer that nearly all Boost is header-only, and has no effect on the executables.

 

The Getting Started instructions have been poor from the start, and are virtually unchanged while the Boost size has increased >10-fold.

To suggest that everyone needs to build all the libraries for all the variants taking hours has become absurd when most users are only like to need a handful like system and chrono.

 

So we could and should *sell* Boost much better.

 

In conclusion, I don't think that we have the resources to do any useful split.  

So while we may regret that some avoid Boost, we must resign ourselves to continue muddling through ☹

 

Paul

 

 

 

 

 

 


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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
El 24/05/2020 a las 14:52, Edward Diener via Boost escribió:

> On 5/24/2020 4:20 AM, Joaquin M López Muñoz via Boost wrote:
>> El 23/05/2020 a las 22:46, Edward Diener via Boost escribió:
>>
>>> I am totally against the idea that some code which works perfectly
>>> in C++03, as well as all
>>> other C++ standard levels, needs to be unnecessarily updated to some
>>> later C++ standard
>>> level in order to be acceptable to anyone.
>>
>> This looks somewhat at odds with one of the stated goals of your
>> cxx_dual lib:
>>
>> "On a more practical basis the CXXD library is for:
>>
>> 1. Programmers writing code not using C++11 syntax who still want to
>>     target some
>>     C++11 libraries if the code is compiled in C++11 mode.
>>     [...]"
>
> I do not see why you think the statement above is at odds with what I
> previously
> asserted. Whatever might have been added to a Boost library which became a
> C++ standard library in C+11 or beyond could hardly have been done
> just to add
> unnecessary features. I am not against a library being updated to use
> features of
> a later C++ standard when those updates are predicated on improving a
> library
> in specific ways that make it worthwhile to add such features.
>

I'm not sure I'm parsing your sentences right, but does that mean you're ok
with a library using cxx_dual from scracth but not ok if a Boost-reliant
lib is
later updated via cxx_dual *only* to reduce Boost dependencies in C++11?


> The gist of your proposal which seems to me to be highly flawed is the
> idea
> that at a certain Epoch level all dependencies of a library must also
> exist at that
> same Epoch level or higher. How realistic is such a goal ? If library
> X at Epoch level nnn
> successfully uses library Y at Epoch level nnn-1, why should library Y
> be arbitrarily updated
> [...]


I understand you meant "should library X be arbitrarily updated" here.


> [...]for no good practical reason to use C++ features of Epoch level nnn ?
>

The reason is to reduce internal Boost dependencies.


> I am pretty sure you can see the absurdity of such a determination as
> that.


I admire your confidence but not your perspicacity, as I indeed see no
absurdity here.

Take for instance Boost.Beast, which depends on boost::string_view but can
be made to depend on std::string_view instead via
BOOST_BEAST_USE_STD_STRING_VIEW.
Shall I take that you deem this ability absurd?

Joaquín M López Muñoz



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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
El 24/05/2020 a las 16:15, Peter Dimov via Boost escribió:
> Joaquin M López Muñoz wrote:
>
>> Boost.Regex is admittedly a controversial point (as mentionedin the
>> proposal) due to
>> its superior quality to some std implementations.
>
> There's nothing controversial about it.


I meant controversial as for epoch asignment within this proposal.


> As of 2020, it should always be preferred over std::regex.


I shouldn't comment on opinions outside the scope of the proposal lest
we wander off, but obviously not everybody agrees always with this
assessment, not even within Boost:

https://github.com/boostorg/fiber/blob/df4a190f5b92ba86395cf58b1040ed295caf9fc5/src/numa/linux/topology.cpp#L11

https://github.com/boostorg/hana/blob/07b42492765f7384e053c4761f4d0eda32b75834/include/boost/hana/experimental/printable.hpp#L36

That said, I'm with you Boost.Regex is a superb library.

Joaquín M López Muñoz


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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
El 24/05/2020 a las 17:04, Paul A Bristow via Boost escribió:

> Your epoch ideas have merit, but some disadvantages.
>
> But I fear that (like other projects like Cmake) the BIG hurdle that we
> struggle to get over, is *resources*.
>
> And particularly, resources to update *all* existing libraries in any way.
>
> Boost does have a lot of dependencies, but they are there for excellent reasons.
>
> Documentation is a big part of the distribution (guilty) , but are needed by most.
>
> Tests and tests data are another area that many users rarely use, but separately
> them would be a big task.
>
> It is true that Boost has become very big, but Boost is only taking up space on
> builder's disks, not in end-users executables.
>
> If we could do something positive, it would be to make much clearer that nearly
> all Boost is header-only, and has no effect on the executables.
>
> The Getting Started instructions have been poor from the start, and are
> virtually unchanged while the Boost size has increased >10-fold.
>
> To suggest that everyone needs to build all the libraries for all the variants
> taking hours has become absurd when most users are only like to need a handful
> like system and chrono.
>
> So we could and should *sell* Boost much better.


I agree with much of what you say here, in particular with your
appreciation that
Boost has a PR problem.

Most Boost libs are indeed header-only, which dispenses many users with the
need of building. But even in this case one has to drag a lot of
dependencies in.
Users are comparing Boost (fairly or not) with header-only libs without any
dependency whatsoever.


> In conclusion, I don't think that we have the resources to do any
> useful split.
>
> So while we may regret that some avoid Boost, we must resign ourselves to
> continue muddling through ☹


I'd say at least phases 0 and 1 of the proposed plan for this:

https://github.com/joaquintides/boost_epoch/#work-plan

are fairly economical in terms of needed effort. Once put in place,
it'll all
of course depend on how this actually incentivizes authors to do their
part.


Joaquín M López Muñoz




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

Re: [epochs] Proposal for an epoch-based organization of Boost libraries

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 5/24/2020 12:38 PM, Joaquin M López Muñoz via Boost wrote:

> El 24/05/2020 a las 14:52, Edward Diener via Boost escribió:
>> On 5/24/2020 4:20 AM, Joaquin M López Muñoz via Boost wrote:
>>> El 23/05/2020 a las 22:46, Edward Diener via Boost escribió:
>>>
>>>> I am totally against the idea that some code which works perfectly
>>>> in C++03, as well as all
>>>> other C++ standard levels, needs to be unnecessarily updated to some
>>>> later C++ standard
>>>> level in order to be acceptable to anyone.
>>>
>>> This looks somewhat at odds with one of the stated goals of your
>>> cxx_dual lib:
>>>
>>> "On a more practical basis the CXXD library is for:
>>>
>>> 1. Programmers writing code not using C++11 syntax who still want to
>>>     target some
>>>     C++11 libraries if the code is compiled in C++11 mode.
>>>     [...]"
>>
>> I do not see why you think the statement above is at odds with what I
>> previously
>> asserted. Whatever might have been added to a Boost library which
>> became a
>> C++ standard library in C+11 or beyond could hardly have been done
>> just to add
>> unnecessary features. I am not against a library being updated to use
>> features of
>> a later C++ standard when those updates are predicated on improving a
>> library
>> in specific ways that make it worthwhile to add such features.
>>
>
> I'm not sure I'm parsing your sentences right, but does that mean you're ok
> with a library using cxx_dual from scracth but not ok if a Boost-reliant
> lib is
> later updated via cxx_dual *only* to reduce Boost dependencies in C++11?

No.

I am ok with a library changing itself to use C++ standard libraries
instead of their Boost equivalents in any way it wants, whether using
cxx-dual, whether creating its own interfaces for both Boost and the C++
standard equivalent, or whether just switching from using Boost to the
C++ standard equivalent. But I am aware that such a change takes work,
and will displease some end-users. If the Epoch proposal is merely to
get a given Boost library to create another version of itself where it
uses C++ standard libraries instead of Boost libraries so it can be part
of a later Epoch I can see the value of your proposal, but again who
will do the work of this transformation ? But if the Epoch proposal
entails forcing a given library to use some features of a C++ standard
so that it can be part of an Epoch, I see that is a failure of conception.

If we are just talking about library dependencies, then a Boost library
which has 0 or more dependencies on only C++ standard libraries of a
given Epoch belonging to that Epoch is actually fine with me. But this
of course means that a Boost library which has no dependencies on either
Boost libraries or their C++ standard equivalent libraries of a given
Epoch belongs to all Epochs, which is the way it should be IMO. So Boost
PP, as an example, belongs to all Epochs.

>
>
>> The gist of your proposal which seems to me to be highly flawed is the
>> idea
>> that at a certain Epoch level all dependencies of a library must also
>> exist at that
>> same Epoch level or higher. How realistic is such a goal ? If library
>> X at Epoch level nnn
>> successfully uses library Y at Epoch level nnn-1, why should library Y
>> be arbitrarily updated
>> [...]
>
>
> I understand you meant "should library X be arbitrarily updated" here.

No, I meant that library Y should not be arbitrarily updated so that
library X can be considered valid for Epoch nnn. The only case I see
where library Y would need to be updated, with perhaps another version
at Epoch level nnn, would be if library Y had a dependency on a Boost
library where an equivalent C++ standard library which works at Epoch
level nnn was available.

>
>
>> [...]for no good practical reason to use C++ features of Epoch level
>> nnn ?
>>
>
> The reason is to reduce internal Boost dependencies.

Adding C++ features at a certain C++ level rarely has to do with
dependencies as opposed to the necessities of programming design. If
adding a feature at a certain C++ level was able to reduce a dependency
of a library to another library I would in general be all for it. But
just let's take a library that is designed in such a way that it does
not need any features of, let's say, C++11. Why would anybody want to
add some feature just for the sake of saying that the library is at
Epoch 11, when such a feature is unnecessary in the design of the
library. This is what I mean by "absurdity".

>
>
>> I am pretty sure you can see the absurdity of such a determination as
>> that.
>
>
> I admire your confidence but not your perspicacity, as I indeed see no
> absurdity here.
>
> Take for instance Boost.Beast, which depends on boost::string_view but can
> be made to depend on std::string_view instead via
> BOOST_BEAST_USE_STD_STRING_VIEW.
> Shall I take that you deem this ability absurd?

Not at all. But take a library which works fine at the C++03 on up
level, such as TTI, and has no dependencies on other Boost libraries
which can be dropped by adding some arbitrary feature of C++ 11 on up.
Why should not this library be used by an Epoch library at the C++11
level if its usefulness is apparent to that Epoch library. And why
disqualify that Epoch library from its level just because TTI does not
use C++11 features.

The gist of our disagreement is that I can see the usefulness of your
proposal regarding Boost dependencies versus C++ standard equivalents,
but not regarding the arbitrary distinction of whether some library uses
some C++ feature of some C++ standard level.

I would agree wholeheartedly with the idea that for any given Boost
library, X, at no matter what C++ standard level, which uses 1 or more
other Boost libraries when a C++ standard equivalent is available at
some C++ standard level, that it would be advantageous for end-users to
have another version of that library which uses the C++ standard
equivalents. But doing such work is hardly trivial.


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