Subject: Re: [boost] Rebooting Boost: Call for Lightning Talks @ CppCon
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-05-23 04:18:33
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
>> 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.
If you have a library with a decent size, there'll be no difference. If
you ever get there...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk