Re: [boost] Case study: Boost.Local versus Boost.Phoenix

Subject: Re: [boost] Case study: Boost.Local versus Boost.Phoenix
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-02-04 03:06:05

Joel de Guzman <joel <at> boost-consulting.com> writes:
> On 2/4/2011 10:36 AM, Gregory Crosswhite wrote:
> > In conclusion, I have found that Boost.Phoenix is simply too painful to use 
> > in practice for most cases where I have been using Boost.Local.  Although it 
> > could potentially allow for very elegant code in many cases, it is so hard 
> > to figure out what you are doing wrong that it seems to be more trouble than 
> > it is worth.  I am actually a little sad at having arrived at this 
> > conclusion, because the library looked incredibly cool and I was very
> > excited about trying it out, and now I am just walking away from the whole 
> > experience feeling incredibly frustrated.  Furthermore, even if I were an 
> > expert in it I have trouble seeing how in most of the places in my code it 
> > would result in code that was either more clear or easier to write.  The 
> > Boost.Local code has extra noise at the beginning, but when the main body of 
> > the nested function contains lots of calls it is far more expressive to
> > write the C++ code directly than to use lots of pheonix::bind functions to 
> > accomplish the same thing.
> >
> > This doesn't mean that I think that Boost.Phoenix is a bad library.  Reading 
> > through the documentation I am absolutely amazed at how it can be used to 
> > create very expressive functions;  the authors have clearly worked very hard 
> > on it and should be proud of their work.  However, it simply cannot be 
> > treated as invaliding the need for something like Boost.Local, because for 
> > one to accomplish many of the same tasks in Boost.Phoenix as one can
> > accomplish in Boost.Local one has to deal with a whole lot of extra mental 
> > effort and frustration, and the result at the end is often less expressive 
> > and clear (and potentially less maintainable) as it would have been if one 
> > had used Boost.Local since the body is no longer expressed in standard C++.

I think what you have shown is a prime example of the clash of two programming 
paradigms. It became very clear that the examples you've shown just didn't fit 
in well in the Phoenix programming model. However, Phoenix provides an interface
for that as well, phoenix::function ... see Joel's comment.

Additionally, I have to agree with you that the error message you experienced 
lead to a lot frustration. They probably dominated the overall impression you 
got of the library. These (overly verbose) error messages can be seen as a bug 
of the library!
There are techniques to improve them, however none of these are implemented yet.
Ironically, while developing the library, I needed the full exposure of the 
error messages to debug all the template code ;)

> You've just scratched the surface, and IMO, learned about the library in
> a way that I would not advice. To be honest, I never liked bind -- not a
> bit. If I did it my way, I'd write small modular phoenix functions
> just like you would in C++ or any FP language, but are fully curryable
> and lazy. It's very similar to what Local provides, albeit in C++ syntax
> instead of macros. By doing so, you avoid overly complex phoenix expressions
> and work closer to C++ but at the same time get all the benefits of FP.
> 
> As I hinted, it is also possible to provide Local like macros to make
> the code even more concise. Right now, admittedly, phoenix function is
> more verbose, but it does a lot more and is more flexible.

George, thank you for the effort you put into trying out Phoenix! If it doesn't 
lead to too much trouble I would like to have a (selfcontained) testcase I can 
work on to analyze the problems you had and improve either the documentation or 
fix some bugs you might have run into. I think your experience shows that there 
is a need for a Troubleshooting section in the docs.

Thanks,

Thomas