[boost] Re: FSM Review

From: David B. Held (dheld_at_[hidden])
Date: 2005-03-14 19:13:19

Jody Hagins wrote:

> On Sat, 12 Mar 2005 13:42:19 +0100
> "Andreas Huber" <ahd6974-spamgroupstrap_at_[hidden]> wrote:
> [...]
> Thus, it seems that Andreas is not planning to make significant
> performance changes, and he has doubts as to the possibility that such
> changes are even possible.  However, he has agreed to make a solid
> attempt to address the issues after acceptance (with the help of any
> volunteers), if such acceptance is granted.  Maybe we should ease up a
> bit on the details of performance until such time as the library is
> either accepted or rejected.  Then, we can resume such discussions as
> appropriate to the situation and goals of the library.

One thing that bothers me about the performance discussion is that
some parties seem to imply that there exists a single best point in
the design space, and that the proposed library has not found it.
Given all the different constraints and values that can differ from
application context to application context and user to user, I hardly
see how such a stance is justifiable.  Without having followed the
discussion too closely or reviewed the library in any depth, I would
have to say that my impression is that Andreas has put together a
reasonably solid library with decent rationale for his design
decisions.  And isn't that Boost is interested in?  Quality libraries
that put correctness first and performance second?  I don't believe
Andreas has at any point claimed that his library is the fastest
possible implementation of FSMs in existence, so why should it be
held up to that goal?

If the library meets the stated design goals, and if those goals are
useful to a significant number of people, then the library has real
utility, no?  I believe that in discussions of other libraries, it
has been pointed out that Boost does not exclude the possibility of
overlapping libraries when there is a reason to do so.  If someone
else would like to propose a fast FSM library that has different
design goals, possibly including performance as a primary goal, then
I don't see why such a library could not co-exist with the one that
Andreas has built.  I don't see why such a library *should* not
co-exist.  What I like about C++ is choice.  I like the fact that I
can work with big fat structures like std::map<> or fast simple
structures like builtin arrays.  I like the fact that nobody decides
for me ahead of time what design decisions I must make in selecting
prebuilt components.

I use iostreams when I can, and cstdio when I must.  In fact, I did
exactly that in some recent utilities that had to work on fairly
large files.  Is it bad that C++ has both I/O libraries?  Not at all.
I can write iostream code much faster than cstdio code, and more
correctly with less referral to documentation.  But the simple fact
is, cstdio is faster, hands down.  When I need the extra speed, I
have that option.  When I don't, I will cruise in the luxury of
iostreams.  I like to use std::string, warts and all.  It's easy.
It's convenient.  It's even better than Java's String. ;)  But
sometimes I have to get down to char* and dirty pointer arithmetic,
and that's ok.

Maybe Andreas has produced the iostreams of the FSM world.  I
consider that A Good Thing.  Maybe someone else knowledgeable
about and concerned with performance will write the cstdio version.
That would also be A Good Thing.  But the idea that for this domain,
there is a unique best solution has not thus far been defended,
and I strongly suspect that such a position is, in fact,
indefensible.  This library already has users before becoming a
Boost library.  That implies that people already find it useful.
It will be a sad day when Boost rejects a good library because
another library in a different part of the design space is
theoretically faster.

Dave