Subject: Re: [boost] RFC: Community maintained libraries
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-12-07 14:35:56
On 6 Dec 2013 at 16:29, Nevin Liber wrote:
> We would
> > almost certainly unite to see off the challenger, and that's a huge
> > barrier to entry.
> Would we? I can't imagine something like that being successful unless the
> Boost development community was so divided that a significant fraction move
> over to the forked project while the others stick with Boost, and that
> community division would be the problem we need to deal with.
I would liken it to how C++ reacted to the D language. D has tons of
great ideas, some very well executed and some not. It bought in a
reasonable sympathy from many C++ programmers, and if C++ simply
ignored D then D would have continued to grow, perhaps eventually
becoming a viable substitute.
C++ did not ignore D however, and there has been a clear reaction to
D in recent C++ evolution. That is killing off D as a viable
substitute. I'm saying the same pattern would likely happen to Boost
if faced with a realistic potential substitute i.e. unite and see off
the challenge. You might note how recent additions to Boost replicate
features in other C++ libraries such as POGO etc.
> > This all may seem quite abstract, but there have been more than one
> > Boost competitors over the years which sought to "do Boost better"
> > whether implicitly or explicitly (with some alternatives coming from
> > multinational corporations).
> *shrug* Unless you are mentioning actual examples, it is still just
> abstract and only in your opinion.
I never claimed anything I said wasn't just my opinion.
Examples won't be a perfect fit, so people will complain they aren't
a perfect fit and therefore I'm hand waving which someone already did
... etc ...
> What exactly is a Boost competitor? Someone else who wants to contribute
> libraries to the C++ community or the C++ standard? Good for them!
> > Some have had a reasonable success, but
> > none to my knowledge has ever really come close to displacing Boost.
> Seriously? Who out there wants to put Boost out of business? Without
> specifics, this is just FUD.
Who said anything about anyone wanting to put Boost out of business?
It's usually about doing things *differently* according to some
ideological or philosophical beliefs, not about killing whole
projects off. People fork because they believe that "their way" is
better for some given problem set.
And why FUD? This list likes to accuse dissenting voices of FUD
almost automatically. To FUD implies having a motive. What do you
think my motive is here? What do I gain by writing any of this,
except sacrificing time better spent elsewhere?
> > In that sense what has worked has worked very well - till now. We
> > can't easily say yet if the present maintainer-led system will scale
> > out.
> No one can say what the future holds. More FUD.
> > I personally think - and I'll put on my hat as a Complex Systems
> > researcher now - that the tipping point where it stops working well
> > is not long far out, especially now modularisation has been
> > implemented which will speed up the complexification of the Boost
> > ecosystem substantially.
> What does "not long far out" mean? A year? Ten years? Before C++
> collapses under its own weight (another oft-said prediction)? Heat death
> of the sun? Again, without specifics, this is just FUD and a non-problem.
If it's approved for presentation, I think you'll just *love* my C++
Now 2014 presentation and associated ten page academic paper. It's
exclusively about future non-problems and FUD in C++.
-- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk