[boost] Re: FSM Review

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-12 12:39:14

"Jeff Garland" <jeff_at_[hidden]> writes:

> Combining a couple replies...
>
>> "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:
>> 
>> > On the other hand ....
>> >
>> > 1. Boost is about Excellency
>
> Agree.
>  
>> > 2. Nothing prevent usage of the library. It's accessible. And in
>> > this particular case I noticed several support request in users ML
>
> While I agree that this is technically true, in the commercial world the
> politics matter -- and being an 'add-in' boost library makes it difficult to
> handle.  I also believe it limits seriously the audience that will look at the
> library because my perception is that most boost users don't mess with the
> sandbox or CVS -- they use the releases and that's it.
>
>> > 3. As well as rejection may lead to discouraging further efforts, so
>> > could acceptance do. Could you expect any major issues to be
>> > resolved once library is delivered?
>
> Yes, I expect major changes over time.  Many libraries in boost have evolved
> significantly over time as users adopt and run into issues that cannot be
> fully anticipated in reviews.  Iterator adaptors comes to mind as a library
> that, in theory, it's current state could have been fully analyzed
> up front. 

Well, it's not perfect yet, by any means.

> But, in fact, it took usage and a major refactoring, including interface
> changes, to get to the current design.  

Yes, and that was an *enormous* effort involving many months and three
people.  Major redesigns are very hard, and usually they seem to
require the original library author to become extremely uncomfortable
with the limitations and/or problems of the original design.  At least
that's been true in my case.  Andreas seems very comfortable with his
design choices ;-)

> Filesystem is another evolving library
> -- it solves real problems for many current users, but it doesn't do
> everything people want.  

Yeah, but what we're talking about here probably involves more than
just evolutionary development.  The performance limitations of this
design are built into the structure of the library, IIUC.  And IIUC
the author has given no indication he intends to address that issue
other than by explaining that there's no way to do so while
maintaining the other design goals.  Please correct me if I'm wrong,
anyone.

I want to be clear that I don't have a vendetta against this library
or its author.  I do think it's important to be realistic about what's
likely to happen to it if it's accepted.

>> David Abrahams wrote
>> The serialization library is a beautiful example of how a rejection
>> ended up being very positive for the library and for Boost.  Whether
>> or not that experience can be replicated is another question.  It was
>> certainly not easy for Robert.
>
> Yes, serialization worked out and it's the only example of a rejected library
> getting accepted that I know. In most other cases, rejection meant that the
> author walked away.  In a couple cases, walking away was expected because the
> conclusion of the review was that there wasn't a clear need for the library
> (FC++ for example).  In other cases, though, the author just wasn't prepared
> to spend the time to try and make people happy (Fixed-Point Decimal).

Did I miss something?  We reviewed a fixed-point decimal library??
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com