Re: [Boost-users] [Phoenix] review reminder

Subject: Re: [Boost-users] [Phoenix] review reminder
From: Roland Bock (rbock_at_[hidden])
Date: 2008-09-29 16:04:00

Hi,

a few thoughts:

Name:
======
Personally, I think, that the naming of libraries is not just a minor 
issue. The name of a library not only helps potential users to find it. 
It also helps the library's developers and contributors to focus. With a 
name like Phoenix, the sky is the limit. Remember the time when Firefox 
aka Mozilla was called Phoenix?

The same is true for Spirit. If nobody had told me to use Spirit for 
parsing, I probably would never have come to use it. And looking at 
Spirit, I was quite astonished to find the Phoenix things in there.

To me Spirit looked like small collection of libraries inside a bigger 
collection of libraries (boost). I bet that there would have been quite 
a different development with a different, more focused name.

The name "Phoenix" does neither help to find the library nor does it 
help to decide whether to have a certain feature included or not. Want 
MPL inside Phoenix? Er, well, yes, why not? Want Graph functionality? 
Yeah, would be great to be able to draw up relationships between Phoenix 
actors. Sorry, I might be exaggerating...

Phoenix:
========
Now Phoenix is about to be taken out of Spirit which is good for both 
Spirit and Phoenix, I guess. From what I have read so far, Phoenix seems 
to have very powerful features. It deserves to live outside Spirit.

But many of Phoenix' features seem to be variants (improved, probably) 
of exisiting things like bind, lambda, ref, functional. I consider this 
a problem, because when I am going to need lambda functionality for 
example, should I turn to phoenix? Or to the lambda package?

Personally I would prefer either of the following two:

a) Phonix is split up into several smaller packages with most of them 
being merged/combined with exisiting ones.

b) Phonix is renamed into something like Boost::FunctionalProgramming 
and is merged with the exisiting packages.

With both options, when I am going to need lambda or bind in the future, 
I will know where to look for them.

The text on the first page of the documentation supports these thoughts 
IMHO:

"One can extract and use only a small subset of the full library, 
literally tearing the library into small pieces, without fear that the 
pieces won't work anymore."

My vote:
========
1) Before accepting Phoenix as boost library, its relationships
with (competing?) packages of similar nature should be resolved. Having 
everything more than once is not helpful. Personally I am in favor of 
smaller, more focused packages, so I would choose option a)

2) Before accepting it as boost library, a different name should be 
chosen. One that tells what the library is about.

Regards,

Roland

PS: As for the background information:

- Are you knowledgeable about the problem domain?
   I am not an FP expert, but I've tasted blood and want more...

- What is your evaluation of the design?
   Not being an expert, I say, I am quite fascinated :-)

- What is your evaluation of the implementation?
   Haven't looked into the code, yet

- What is your evaluation of the documentation?
   I am going to send se separate mail.

- What is your evaluation of the potential usefulness of the library?
   As I wrote above, I think it would gain from being merged with
   existing libraries either to form a greater whole or to form several
   specialized packages.

- Did you try to use the library?  With what compiler?  Did you have any
problems?
   Yes, I played with the "real life" example, tried to turn it into a
   a real "real life" example and failed utterly. Code is attached.
   Certainly shows that I am not an expert ;-)

- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
   Several hours of reading and playing around, collecting thoughts in
   this mail and the next one in parallel.
   Not nearly as much as I wanted, but I got stuck with the documentation

Robert Ramey wrote:
> I spent some time looking at this library.  I'm looking at the documentation
> in release 1.36 for phoenix in the spirit library documentation.
> 
> Here are a few observations:
> 
> I don't really know enough about functional programming in order
> to write a revew.  My perspective is of someone who is interested in
> this subject and wants to use phoenix as a vehicule to learn more about it
> and experiment with it to see to what extent it can help me with the
> programming problems that I come upon in my daily work.
> 
> I don't like the current trend in assigning "cute" names to
> libraries.  E.G. spirit, phoenix, proto, xpressive, oven, - I'm
> sure there are others.  The universe libraries is sufficiently large
> that given a problem, I'm included to scan a list of library names
> and drill down into those whose names suggest they might help
> on my current problem.  These names don't help me with that.
> I don't expect anyone to change a current name, and It's not
> a huge issue - but it is a minor annoyance.
> 
> When I perused the library documentation, I was left with
> the idea that I had a general understanding of what it does
> and that I could make use of it should I decide to.  This
> struck a very positive note for me.
> 
> However, I would much like to see a few simple
> examples of complete applications which show how the
> library can actually shorten/and/or improve the final result.
> The "First Practical Example" is too trivial and it seems
> to be the only real example.
> 
> After writing the above, I looked up the references cited
> in the documentation.  I found that I had the same complaint
> about most of them.  The John Hughes paper (1989!) did
> have some interesting examples.  Maybe implementing
> the newton-raphson method on in terms of phoenix might
> have helped me.
> 
> Robert Ramey
> 
> 
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users