Re: [Boost-users] Wave: how to recover after errors?

From: Max Motovilov (max_at_[hidden])
Date: 2005-12-12 00:35:02

> payoff of permissiveness is short-term and insignificant compared to the
> long-term cost.  Maybe we just disagree about how significant that
long-term
> cost actually is.

We probably disagree about the short-term costs, not the long-term ones. The
long term costs are an incremental and mounting burden, short-term costs are
a barrier to entry. E.g. if the new compiler (VC7.1 for the sake of the
argument) does not compile the existing code base, the management keeps
everybody stuck with the old one (VC6 in this example) and bye-bye Boost, or
most of it anyway. Yes, in principle it would have been better to resolve a
few minor things such as incorrect scope of 'for' variables, or whatnot, but
it's anyone's guess how it will turn out in every particular case.

> that comes with it.  I don't know if its still the same situation now, but
a
> number of years ago, VB had an awfully large user base.  If C++ had become
more
> VB-like, it may have come out higher in number of users than it has now.

Well, as we both know, the beauty of C++ is that it can be as VB-like as you
want. Didn't take me all that long to get all of VB's syntactic simplicity
of access to COM and dispatch interfaces (special thanks for PP and
enable_if go here...) -- too bad I can't put that library into open source
right now... The biggest problem is that users often just don't know what
functionality and convenience are available in C++ for the price of asking
and C++ is still thought of as a strange monstrosity fit for a select few,
and, if it cannot be avoided altogether, it is best "managed" [pun intended]
by using design and coding practices dating back ten years or worse.

I wonder if the best thing that could possibly happen to C++ at the moment
would be a 4th edition of Bjarne's book, based on Boost in the same degree
as 3rd was based on the standard library. I know there are good recent books
that explore certain corners of modern C++ thinking, but they somehow don't
seem to resonate. What little I've seen of college-level C++ curriculum
looked quite atrocious. And in terms of continued education, there's just
not one _single_ book that I could recommend to junior guys and tell them
"write like THAT". In my mind, "like THAT" being -- learn to use and
actively search for available library code and don't be scared if IT uses
advanced paradigms -- YOU don't have to.

But then again, even a new Bjarne's book might not cut through all the hype
the industry is always awash in :(

> vendors making C++ more VB-like anyway.)  The point is that popularity is
not
> the only measure of success.  In fact, popularity is often an indication
of
> lower quality (e.g. MFC and pop music).

Unfortunately, while popularity may be a poor indicator of quality, it is a
very strong indicator of relevance. Almost to the point of being one and the
same thing ;)

> I've done it for the part of Boost that I consider my responsibility.  (As
> usual, my problem is documentation--very important--which I hate writing
and
> apparently suck at anyway.)

I don't think Boost-PP in particular suffers from deficient documentation.
Again, what it needs is a massive how-to, which is best delivered in form of
a [chapter of a] book. On the other hand, Boost-PP is more of a toolmaker's
tool than an end-user's tool anyway... but it is an absolute must have for
the toolmaker!

> My first observation based on that experience is
> that the pp-lib is stagnant.  There isn't much I can do to improve it
(even with
> massive workarounds) without much better implementations as the common
starting
> point.

I think for starters it would be nice to get it better adopted by other
parts of Boost (not a dig at you by any means, but at those who can't be
bothered to use it). There's just no excuse for a library to introduce an
arbitrary, unconfigurable limit on the number of supported arguments in a
user's function, or length of a [variable by design] list of template
parameters etc. The only piece of Boost I have to replace with my own
version in every new release is boost/tuple/detail/tuple_basic,hpp which is
STILL limited to 10 elements and which I had rewritten using Boost-PP back
in 2003... by the way if anyone DOES want it in Boost after all I'd be glad
to re-submit ;)

Sorry, this thread went way off-topic. Mea culpa.

...Max...