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

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-11-24 09:56:36

On Fri, Nov 25, 2011 at 1:27 AM, Gregory Crosswhite
<gcrosswhite_at_[hidden]> wrote:
>
> 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.
>

Or you may be misunderstanding the context of the discussion I 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.
>

It's not about Phoenix. Realize the thread is started about whether
libraries that try to approximate functionality from C++11 in C++03
should be included in Boost. Phoenix only came up as an example.

Now people have brought up the issue of the error messages that come
up when you use Phoenix *incorrectly*. The solution to the problem
there is to use it correctly and to do that learn to read the compiler
diagnostics and error messages.

As far as Phoenix vs Local I view that discussion as myopic. That's
not the point I wanted to tackle which over and over again gets
brought up. Read my messages again and then tell me where I distinctly
said Local shouldn't be included because Phoenix is there. If you're
complaining about what other people have said in a different
discussion then I can't comment about that -- and I don't even think
that's also relevant in this discussion I keep wanting to have that is
being muddied up by feelings and personal convictions.

To bring it back to what I really want to understand is: Why does
Local need to be in Boost? Can it not stand alone as something else
outside of Boost? So what if people vote against the inclusion of
Local into Boost because they feel it's an unnecessary library?

> (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.)
>

But it is inferior to Phoenix on a point-by-point basis. It's also
inferior to C++11 lambda's. Why is there any doubt in this?

I don't get why broken code (whether code using Phoenix or Local)
should be the basis for whether a library is superior to another as
far as end-user experiences is concerned. It's broken code, it doesn't
even compile!

What *should* be the basis is the merit of the library. I have already
put forth my points as to why I think libraries like and including
Local ought to be approached in a different manner -- and that it
probably shouldn't be in Boost. I don't see you addressing any of
those points but rather dwell on the Phoenix discussion which isn't
the one I originally wanted to have when I first responded to the
thread anyway.

>>
>>> 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. Â :-)
>

Okay. :)

>>
>>> 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! Â :-)
>

Happy day. :)

>> 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.
>

Wait, why does the comparison have to be over Phoenix? Why can't the
comparison be against normal class/namespace scope functions?

As I've already pointed out in another message, I see absolutely 0
advantage to using local functions -- whether first-class in C++1x or
using some library -- compared to C++11 lambdas or Phoenix lambda's
defined in-lined. There's also 0 advantage to using local functions
compared to namespace/class scope functions. It's a solution looking
for a problem and unfortunately I don't see the problem with not
having local functions in C++ (as I've already pointed out as well).

>> 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.
>

If you look at it objectively, using macros when you can type it out
on your own is unnecessary obfuscation, and with the features that are
already in C++11 and the libraries already in Boost now and don't
forget normal functions at class/namespace scope, it's backward to
think that you would get away with using macros to do what you can do
with normal C++ facilities. It's 2011, we shouldn't be using C++98.

>> 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.
>

Hey I'm not complaining that people are bashing libraries. What I'm
complaining about is why people aren't complaining (meta isn't it?)
that their compilers suck at displaying better error messages for
broken code.

Again, *THE LIBRARY DOESN'T SPEW ERROR MESSAGES, COMPILERS DO THAT FOR
BROKEN CODE*.

So again, how does broken code using any library become a basis for
whether the library is a good library for inclusion in Boost? It just
seems silly to me.

Cheers

-- 
Dean Michael Berris
http://goo.gl/CKCJX