Rebooting Boost: Call for Lightning Talks @ CppCon
At C++ Now a number of informal meetings showed there to be frustrations with the current ecosystem around the Boost C++ Libraries (to paraphrase a founder of Boost, "Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*". Recent and recurrent boost-dev discussions have raised the lack of cmake based tooling; lack of ABI management and the consequent ODR violation when mixing Boost versions in the same process; the anti-social behaviour of Boost towards library end users, new ideas, new blood and the wider C++ community; and the chronic lack of maintenance of up to half the Boost libraries. One question which needs to be answered is whether a clean reboot of Boost from the first principles of proving high quality C++ libraries well suited for use with the latest C++ standard is viable. This new collection of C++ libraries would be started completely from scratch (even if some existing libraries were ported into the new organisation), so ANYTHING is possible. All we need is a critical mass of library developers willing to collaborate on developing a shared infrastructure mutually beneficial to all participants, whether library developer or library end user. To that end of discovering if this critical mass is there, five minute lightning talk topics are requested for CppCon this September on this topic: "What design pattern, practice or idiom should a standards aspiring collection of C++ 14/17 libraries share?" Please keep each talk topic focused on a single design pattern, practice or idiom (see suggested talk format below). Each speaker may submit up to THREE talk topics (not all may be accepted if there are a lack of slots, so please rank them in order of preference). Please send your talk topics to me privately by email, only if sufficient numbers present to fill a session will your name and your talk topic be shared with the CppCon Programme Committee. We'll try to arrange a short panel session at the end so attendees can ask questions of the speakers. After the lightning talk we'll arrange a restaurant so all the speakers and any interested attendees can dine together, followed by a night in a Bellevue bar. If after the dust has settled it is felt there is a critical mass sufficient to reboot a brand shiny new edition of Boost, we'll start development! I should *stress* that it is up to the CppCon Programme Committee whether these lightning talks are approved or not. I'll just copy and paste your proposed talk to the CppCon PC as-is. If insufficient lightning talk topics are received by me to fill a 60 minute session, I'll withdraw this talk proposal from CppCon. Suggested talk format ================ Five minutes is not much time, so here is a suggested lightning talk outline: 1. A current widely practiced library design pattern (show example). 2. The problems it generates for library users or maintainers. 3. Your proposed alternative design pattern (show example). 4. The problems the alternative design pattern fixes. 5. Any mockup, prototype or even live demo (!) of the alternative design pattern in action. Suggested talk themes might be documentation, packaging, distribution, testing, tooling, quality assessment, barriers to entry, governance, strategy, important gaps in the standard libraries, automation and deprecation/removal policies. Here is an example of such a lightning talk: 1. Current design pattern: Library v1.00: namespace boost { namespace lib { void foo(size_t, char); } } User code: boost::lib::foo(100, 'n'); 2. Problem: Library v1.01: namespace boost { namespace lib { void foo(char, size_t); } } User code: boost::lib::foo(100, 'n'); // oh oh! 3. Alternative: Library v1.00: namespace boost { namespace lib { inline namespace v100 { void foo(size_t, char); } } } #define BOOST_LIB_NAMESPACE_V100 boost::lib::v100 Library v1.01: namespace boost { namespace lib { inline namespace v101 { void foo(char, size_t); } } } #define BOOST_LIB_NAMESPACE_V101 boost::lib::v101 User code: // Mount v100 of Boost.Lib into "lib" namespace lib=BOOST_LIB_NAMESPACE_V100; lib::foo(100, 'n'); // ABI stable! No ODR violation possible! 4. Problems fixed: a) Mixing incompatible versions of individual Boost libraries in the same process (or even translation unit) is now safe. b) Libraries can now depend on other libraries without worrying about breaking code which depends on them which uses a different version of the same dependency. This greatly helps reduce change ripple effects. c) Forward compatibility or alternative implementation shims are now very easy to implement e.g. library users can externally configure either Boost.Filesystem or std::experimental::filesystem for your library to use, your code simply refers to _some_ Filesystem TS implementation e.g. namespace filesystem = FILESYSTEM_TS_IMPLEMENTATION; filesystem::path mypath; -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Le 22/05/2016 à 13:18, Niall Douglas a écrit :
At C++ Now a number of informal meetings showed there to be frustrations with the current ecosystem around the Boost C++ Libraries (to paraphrase a founder of Boost, "Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*". I agree completely. Recent and recurrent boost-dev discussions have raised the lack of cmake based tooling; I agree also that we should provide a way to build Boost with CMake. lack of ABI management Agreed, but I don't know how to check this. and the consequent ODR violation when mixing Boost versions in the same process; I'm not sure this should be something we want to provide. Does the standard libraries have this goal? the anti-social behaviour of Boost towards library end users, Could you elaborate? new ideas, new blood and the wider C++ community; and the chronic lack of maintenance of up to half the Boost libraries.
One question which needs to be answered is whether a clean reboot of Boost from the first principles of proving high quality C++ libraries well suited for use with the latest C++ standard is viable. This new collection of C++ libraries would be started completely from scratch (even if some existing libraries were ported into the new organisation), so ANYTHING is possible. All we need is a critical mass of library developers willing to collaborate on developing a shared infrastructure mutually beneficial to all participants, whether library developer or library end user. Count with me, at least for defining the goals ;-)
To that end of discovering if this critical mass is there, five minute lightning talk topics are requested for CppCon this September on this topic: I'm almost sure I couldn't be there this year :( "What design pattern, practice or idiom should a standards aspiring collection of C++ 14/17 libraries share?" I don't see how this is related to Rebooting Boost. Could you elaborate? Should the talks address whatever issue concerns Boost and how Rebooting Boost would solve them?
Best, Vicente
On 22 May 2016 at 14:37, Vicente J. Botet Escriba wrote:
"What design pattern, practice or idiom should a standards aspiring collection of C++ 14/17 libraries share?" I don't see how this is related to Rebooting Boost. Could you elaborate?
The idea is that the fast paced delivery of reboot ideas provide food for thought and discussion for when the real work begins at the restaurant and the bar and during the days of the conference thereafter. I can already foretell one of the most contentious discussions will be on naming the new collection - someone already suggested "Lift" by private email. Original Boost started with beer. So should a reboot of Boost. If this reboot is decided to happen, anyone willing to contribute is welcome if they bring a positive attitude and a can-do mentality. If the group decide to allow everyone to commit to everyone else's git repos (probably likely), then it's a "just do it" kind of fun and mutually engaging atmosphere. Like it was in the beginning back when Boost was fun.
Should the talks address whatever issue concerns Boost and how Rebooting Boost would solve them?
Nope. Boost 1.x is no longer material nor relevant. It's legacy, and not important to this reboot except as a source of good ideas and possibly some of its more recent libraries. For example, why would anyone want to bother metaprogramming by hand again if Hana is guaranteed to be available in the reboot? The reboot is a clean slate, a tabula rasa. Anything can happen, whomever proposes and implements something gets to design it. If it proves not up to task, it gets reimplemented. Like a startup. Like Boost was at the beginning. Questions such as whether one wants to maintain just enough compatibility with Boost so libraries could coexist in both collections are up to those who join the development of the reboot. I personally would want this as I'd like my libraries to exist in both collections, but I would be merely one voice amongst many equals, and if I get voted down I don't mind. All that matters is that the code eventually arrives at standards quality, and the communal supporting infrastructure greatly reduces barriers to entry over present Boost for both developers and end users. How that is achieved and what forms it takes is up to the developers implementing the reboot. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 05/23/2016 10:12 AM, Niall Douglas wrote:
... Boost 1.x is no longer material nor relevant. It's legacy, and not important to this reboot except as a source of good ideas and possibly some of its more recent libraries. For example, why would anyone want to bother metaprogramming by hand again if Hana is guaranteed to be available in the reboot? ... Niall
It is fascinating how you keep and plan on predating on and feeding off "no longer material" Boost 1.x and its developers' list while dishing out disparaging comments about the project itself and people participating in it. Truly disgusting.
Am 23.05.2016 um 02:12 schrieb Niall Douglas:
On 22 May 2016 at 14:37, Vicente J. Botet Escriba wrote:
"What design pattern, practice or idiom should a standards aspiring collection of C++ 14/17 libraries share?" I don't see how this is related to Rebooting Boost. Could you elaborate?
The idea is that the fast paced delivery of reboot ideas provide food for thought and discussion for when the real work begins at the restaurant and the bar and during the days of the conference thereafter. I can already foretell one of the most contentious discussions will be on naming the new collection - someone already suggested "Lift" by private email.
Hm, I thought of 'reboost'. But when 'lift' crashs and burns, it will at least not look like boost didn't get there reboot off the ground - being Ghostbusters so to speak.
Original Boost started with beer. So should a reboot of Boost.
If this reboot is decided to happen, anyone willing to contribute is welcome if they bring a positive attitude and a can-do mentality. If the group decide to allow everyone to commit to everyone else's git repos (probably likely), then it's a "just do it" kind of fun and mutually engaging atmosphere. Like it was in the beginning back when Boost was fun.
What the? That is the most unprofessional thing you can do and it will get you nothing but weird code and infighting. Good luck with that... Why isn't boost fun anymore? You keep asserting those statements but you NEVER back them up. I'm having fun, so why isn't boost fun? Because people do not worship you and accept your opinion as divine revelation? Seems to me, the problem is, that you can't get your way...
Should the talks address whatever issue concerns Boost and how Rebooting Boost would solve them?
Nope. Boost 1.x is no longer material nor relevant. It's legacy, and not important to this reboot except as a source of good ideas and possibly some of its more recent libraries. For example, why would anyone want to bother metaprogramming by hand again if Hana is guaranteed to be available in the reboot?
How is boost not relevant? Can you backup any of those statements? Two TS are based on boost libaries, so it can't be completely inadequate. Also: I get that you want to cherry-pick libraries you dislike, but how on earth would you avoid that the same thing happens to lift a few years down the road (in the inprobable cause of you finding enough support). If you have a solution for that (i.e. some sort of module system), why don't you just go and implement it before starting 'lift'? You might even find a solution which the boost community likes.
The reboot is a clean slate, a tabula rasa. Anything can happen, whomever proposes and implements something gets to design it. If it proves not up to task, it gets reimplemented. Like a startup. Like Boost was at the beginning.
So why call it a reboot? Why not a new library collection which happens to fork a set of boost libraries? I don't get why you don't just go out there and start your own, without relating it to boost. You're always here on this mailing list trying to split the community and win people over for your ideas. The latter would be fine, if you wouldn't act out, when no one likes your ideas. Well, that could be, because all others are stupid, or it could be because your ideas are not good. Just sayin´.
Questions such as whether one wants to maintain just enough compatibility with Boost so libraries could coexist in both collections are up to those who join the development of the reboot. I personally would want this as I'd like my libraries to exist in both collections, but I would be merely one voice amongst many equals, and if I get voted down I don't mind.
As if you would not mind getting voted down. Yeah, right. You probably only open 20 threads on the mailing list calling everyone anti-social, anti-young people, anti-innovation and anti-dentite.
All that matters is that the code eventually arrives at standards quality, and the communal supporting infrastructure greatly reduces barriers to entry over present Boost for both developers and end users. How that is achieved and what forms it takes is up to the developers implementing the reboot.
Niall
If you have a library with a decent size, there'll be no difference. If you ever get there...
Le 22/05/2016 à 13:18, Niall Douglas a écrit :
Here is an example of such a lightning talk:
1. Current design pattern:
Library v1.00: namespace boost { namespace lib { void foo(size_t, char); } }
User code: boost::lib::foo(100, 'n');
2. Problem:
Library v1.01: namespace boost { namespace lib { void foo(char, size_t); } }
User code: boost::lib::foo(100, 'n'); // oh oh!
3. Alternative:
Library v1.00: namespace boost { namespace lib { inline namespace v100 { void foo(size_t, char); } } } #define BOOST_LIB_NAMESPACE_V100 boost::lib::v100
Library v1.01: namespace boost { namespace lib { inline namespace v101 { void foo(char, size_t); } } } #define BOOST_LIB_NAMESPACE_V101 boost::lib::v101
User code: // Mount v100 of Boost.Lib into "lib" namespace lib=BOOST_LIB_NAMESPACE_V100; lib::foo(100, 'n'); // ABI stable! No ODR violation possible!
I believed that minor version should be ABI compatible. I don't see the need to use namespaces for minor versions. When do you need to version them? Why do you need macros here? What is wrong with namespace lib=boost::lib::v100; ?
4. Problems fixed:
a) Mixing incompatible versions of individual Boost libraries in the same process (or even translation unit) is now safe.
As far as all applications are using a specific version. I don't think this is a good goal. How different versions interact? Wouldn't this increase the current interoperability problem between boost and the standard library, but now between several boost versions?
b) Libraries can now depend on other libraries without worrying about breaking code which depends on them which uses a different version of the same dependency. This greatly helps reduce change ripple effects.
Agreed.
c) Forward compatibility or alternative implementation shims are now very easy to implement e.g. library users can externally configure either Boost.Filesystem or std::experimental::filesystem for your library to use, your code simply refers to _some_ Filesystem TS implementation e.g.
namespace filesystem = FILESYSTEM_TS_IMPLEMENTATION; filesystem::path mypath;
Hmm, if Boost.Filesystem is a conforming implementation of the TS Filesystem, it should provide a a <filesystem> file included in the std::experimental::filesystem namespace and then the user wouldn't need to do anything at the source level, but at the configuration level. I would add a section of what problem could be introduced ;-) Should the versions duplicate the whole code? If not, how this duplication is avoided? How the user can partially specialize a class? inside the versioned or not versioned namespace? If we want to allow several version on a process, it should be the versioned one. What is the advantage of inlining the version namespaces if the user cannot use it directly? Best, Vicente
Niall Douglas wrote:
At C++ Now a number of informal meetings showed there to be frustrations with the current ecosystem
Why "Boost"? i.e. Why not just start a fresh new collection of libraries? You can easily impose whatever requirements you want regarding build systems, assumption of all C++11 features available, documentation formats. Any interested library authors (existing Boost library authors, or otherwise), will contribute if they like your ideas, or just not get involved if they don't care enough about your ideas. It just seems like the route you're pursuing is going to frustrate you further if it gets no traction. Glen -- View this message in context: http://boost.2283326.n4.nabble.com/Rebooting-Boost-Call-for-Lightning-Talks-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Sun, May 22, 2016 at 6:18 AM, Niall Douglas
to paraphrase a founder of Boost, "Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*".
You should always strive to provide proper citations when quoting people. It usually provides needed context to discussions. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 05/22/2016 07:18 AM, Niall Douglas wrote:
At C++ Now a number of informal meetings showed there to be frustrations with the current ecosystem around the Boost C++ Libraries (to paraphrase a founder of Boost, "Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*".
... <snip> ... I have been a (minor, but long running) contributor to Boost for quite a while, and while I don't have the time to comment individually on all the various discussions happening on different ways to evolve Boost, I do want to make one general comment. I agree that Boost should serve the entire C++ community. In fact, I would like to see all capable members of the C++ community find ways to serve the community. However, my experience in the last nearly 20 years of service to that community is that almost no two people agree on what is and is not a service to the community. I have, in that time, found no value in arguing with people that my idea of service is better than theirs. As such, I root for all attempts at service to succeed. To find at least some segment of the community for which that service honestly improves the language and the quality of code being produced in the language. So, if you want to serve by trying something new and different - I wish you well. If you want to serve by doing something tried and true, I again have nothing but respect for your desire to serve, and hope for you to succeed. If you want to try to work within existing projects to try and tweek them toward some direction you find more likely to succeed, once again you have my support for your desire to make a difference. I will make my own choices of what to lead or follow, based on my own (admitedly limited) understanding of the needs of the community, and of my own skills and interests. I expect all others to do the same. I will only object if I feel people are somehow being forced to work against their desires and understanding. I see no reason for strained tempers and acrimony in any part of this. John Phillips Boost Review Wizard PS - Though I have held a position in Boost for many years, this statement should be seen only as my own. No "official" representation of any part of Boost, or of Ron Garcia (the other Review Wizard) should be read into this statement. I signed with my position only to make it clear that I have put some time and personal stake into Boost, and I am not talking from no experience of the community.
On 22 May 2016 at 23:05, John Phillips wrote:
I agree that Boost should serve the entire C++ community. In fact, I would like to see all capable members of the C++ community find ways to serve the community. However, my experience in the last nearly 20 years of service to that community is that almost no two people agree on what is and is not a service to the community. I have, in that time, found no value in arguing with people that my idea of service is better than theirs.
As such, I root for all attempts at service to succeed. To find at least some segment of the community for which that service honestly improves the language and the quality of code being produced in the language.
So, if you want to serve by trying something new and different - I wish you well. If you want to serve by doing something tried and true, I again have nothing but respect for your desire to serve, and hope for you to succeed. If you want to try to work within existing projects to try and tweek them toward some direction you find more likely to succeed, once again you have my support for your desire to make a difference.
I will make my own choices of what to lead or follow, based on my own (admitedly limited) understanding of the needs of the community, and of my own skills and interests. I expect all others to do the same. I will only object if I feel people are somehow being forced to work against their desires and understanding.
I see no reason for strained tempers and acrimony in any part of this.
Hear hear John. And thanks for speaking up in what has become quite an ill tempered response. I would like to emphasise that a Boost reboot is only as divisive and exclusionary as the Boost community chooses it to be. I personally speaking intend to continue to participate in Boost for many years to come, and I would imagine many joining the development of a reboot would also continue to serve here. Being nasty, negative and toxic to real change is what got us here in the first place, and it would be my strongest hope that the development mailing list or forum of any reboot would be a far more pleasant, encouraging and positive place to be and serve than what this place has become in recent years. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On May 23, 2016 6:10:33 AM EDT, Niall Douglas
On 22 May 2016 at 23:05, John Phillips wrote:
I agree that Boost should serve the entire C++ community. In fact, I would like to see all capable members of the C++ community find ways to serve the community. [snip] As such, I root for all attempts at service to succeed. [snip] I see no reason for strained tempers and acrimony in any part of this.
Hear hear John. And thanks for speaking up in what has become quite an ill tempered response.
Niall, I'm really disappointed. You were called out on calling us old, anti-social, etc. while asking, on this list, for interest in a reboot of Boost. Then you have the audacity to respond to John's message implying that you've not been the ill-tempered, acrimonious one in recent discussions, but that it's been everyone else. Please reexamine your interactions on this list.
I would like to emphasise that a Boost reboot is only as divisive and exclusionary as the Boost community chooses it to be.
I don't think anyone responded to your suggestion of a reboot, as presented in this thread, as a particular problem. There were some naysayers of course.
Being nasty, negative and toxic to real change is what got us here in the first place, and it would be my strongest hope that the development mailing list or forum of any reboot would be a far more pleasant, encouraging and positive place to be and serve than what this place has become in recent years.
We strive to have such an environment now, though you choose to think it otherwise. ___ Rob (Sent from my portable computation engine)
participants (8)
-
Glen Fernandes -
John Phillips -
Klemens Morgenstern -
Niall Douglas -
Rene Rivera -
Rob Stewart -
Vicente J. Botet Escriba -
Vladimir Batov