[boost] Re: FSM Review

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-12 15:57:10

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

> On Sat, 12 Mar 2005 12:39:14 -0500, David Abrahams wrote
>> > 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.
>
> Sure, but even the old 'bad design' was a useful advance.
>
>> > 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.  
>
> No question that (re)design is hard. One of the ways that authors get
> uncomfortable is others apply the library in various projects and run across
> report various limitations.  

Haven't a few people been reporting that they won't even begin to
apply this one because of particular limitations?  Anyone who needs
higher performance won't even get started.

> Users suggest and submit enhancement ideas -- sometimes fully coded.

Nobody ever submitted me anything that could be thought of as a
progressive step towards the two major redesigns I've done
(Boost.Python and Boost.Iterators).  The redesigns took a great deal
of imagination, the sort of thinking that someone who's just trying to
get his own work done can't really afford to do.

> And, of course, this can happen even if the library is rejected --
> it's just that the user audience will be smaller.  And that assumes
> that Andreas would decide to continue working on it...

Yes.

>> > 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 haven't read every last word, of the reviews, but what I did read
> seemed like a mostly healthy interchange of possible ideas and
> limitations with various approaches.

I don't understand why you're saying that.  I made no judgement about
the health of the conversation.

> No matter the final implementation the fsm concepts and background
> will stay the same.  And perhaps the any new interface becomes
> different interface.  I'm unsure if the various approaches can be
> unified...
>  
>> 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.
>
> Understood. There are basically 3 options from this juncture --
> accept the library unconditionally, reject, accept with limitations.
> I think what I was hoping is that some sort of consensus could
> emerge which would allow a path to acceptance with conditions that
> would satisfy the folks that want to reject and would also work for
> Andreas.  Ultimately it will be up to Pavel's judgement...
>
>> Did I miss something?  We reviewed a fixed-point decimal library??
>
> Yes, in 2003. Mr Seymour choose to walk away after the library was rejected. 
> The history is here:
>
> http://www.boost.org/more/formal_review_schedule.html

I remember now, thanks.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com