Re: [boost] New libraries implementing C++11 features in C++03

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Gregory Crosswhite (gcrosswhite_at_[hidden])
Date: 2011-11-24 09:27:13

On Nov 24, 2011, at 11:35 PM, Dean Michael Berris wrote:

> Absolutely nobody is forcing anybody else to use whatever compiler or library to
> do whatever you need to do. We're all making choices here and if
> people choose to complain rather than bone up and do the work then I'm
> sorry but there's not much sympathy going around here for that.

Hmm, I think that you may have misunderstood the context of the discussion in which you entered.

Nobody here is criticizing Phoenix for the sake of beating on Phoenix.  What bothers many of us is the claim that Local doesn't belong in Boost because Phoenix is a superior solution.  We have responded by pointing out the usability issues that it has in practice (regardless of whether this is its own *fault* or not) in order to make the point that Local has important advantages over it and hence the presence of Phoenix in Boost does not make Local redundant.  By including both Phoenix and Local, people who want to use Phoenix can use Phoenix and people who want to use Local can use Local, and everyone will be happy.

(This is not to say that there aren't other valid arguments for why it might not be a good idea Local in Boost, just that it is wrong-headed to declare that Local is an inherently inferior solution to Phoenix *despite* any practical difference in the end-user experiences.)

> 
>> Listen, I love learning new libraries and languages.  When I first discovered Boost one of the things I loved to do was to skim through the documentation of all of the libraries to see what they had to offer me because I thought it was *exciting*.  However, its not like I have an *infinite* amount of time to become an expert user in every library that exists.  If a library requires a lot of time and trouble on my part and simply doesn't offer me enough to make up for this, then I will stop spending time learning how to use it so that I can spend that time learning things that are more useful, interesting, and fun.
>> 
> 
> I don't see how this is relevant.

It had been relevant because, given the full context of the discussion, it sounded a lot like like you were criticizing those of us who refused to adopt new libraries because of their steep learning curve.  Now that I realize you weren't saying that, I will happily admit that my paragraph is no longer (and never was) relevant.  :-)

> 
>> Maybe one day I will have a need that Phoenix fills so well that it will be worth the investment of my time to figure out how to harness its full power;  I am completely open minded to that possibility, and if that day comes I will be happy to invest the time to learn how to use it.  Unless and until that day occurs, however, it doesn't make me a "backward-thinking" person that I will instead focus my limited time on more useful pursuits (for me) than learning how to use Boost.Phoenix --- such as arguing with people on the Boost mailing list!
>> 
> 
> Who's arguing? I certainly am not.

Great, we agree on something!  :-)

> Regarding the backward-thinking comment, it refers to developing
> libraries that use antiquated (read: non-modern) C++ approaches and
> hacks to shoehorn functionality that's not in the language to do
> something novel for novelty's sake.

Local is definitely not "doing something novel for novelty's sake", it is solving a problem that many of us face in a way that has advantages over Phoenix.  It might use macros to do this, but given that there are important cases where it provides a significantly better user experience over Phoenix, citing it as an example "backwards-thinking" merely because it uses macros rather than TMP to be incredibly wrong-headed.

> I also don't think it was directed
> at you specifically so I don't know why you're taking it personally.

*shrug* Maybe I am taking it personally, maybe I'm not.  Regardless, I consider the use of the term "backwards-thinking" in this context to be wrong-headed at best and condescending at worst.

> I was asking a question and I don't see how your answers to my
> questions were supposed to enlighten me about the situation I was
> originally curious about. So I ask again:
> 
> Why are people blaming the libraries for horrible error messages when
> it's compilers that spew these error messages?

I already answered that question for you quite clearly:  we aren't.  However if your library spews error messages and another library with overlapping functionality does not, then you shouldn't complain that your library is somehow being treated unfairly (because the faults of the compilers aren't being taken into account) when many of us decide that this makes the other library sufficiently superior in many circumstances to your own that it deserves to be included in Boost.

Cheers,
Greg