On Fri, Nov 25, 2011 at 3:13 AM, Christopher Jefferson <chris@bubblescope.net> wrote:
On 24 Nov 2011, at 14:56, Dean Michael Berris wrote:
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!
Because I have spent more than 10 minutes figuring why Phoenix code wouldn't compile, and that hasn't happened with any other C++ library. In general, when writing code programmers spend much more time with code which is either compile-time, or run-time, incorrect. If I wrote perfect code first time, then my job would be much, much easier! It is the compiler's fault, but in practice, it makes the library very, very hard to use.
Speaking from experience, 10 minutes is too much. I've used Phoenix v2 extensively and I've found that after reading the docs first before trying to do anything with it that I got it easier that way. That said I haven't tried Phoenix v3 though I've been debugging Spirit code since the 2.x days -- again reading the docs, keeping them handy, and not getting scared with compiler barfage. I'm not saying there's no learning curve -- it involves reading the documentation, trying things out, and getting the "spirit" of the library and the semantics of usage. But that's just me though and I recognize that others might not have it as good as I did when I was learning both Spirit and Phoenix.
Personally, if boost local was accepted I would expect to use it for a year or so, until I could assume people I work with all had decent C++11 compilers, and then drop it for lambdas. I'm never going to start using boost::phoenix in code I share with other people.
Is that a good enough reason to accept it into boost? I'm not completely sure.
Exactly my point of contention too. Cheers -- Dean Michael Berris http://goo.gl/CKCJX