Re: [boost] 5 Observations - My experience with the boost libraries

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-03-24 08:27:26

Thomas Klimpel wrote:
> Stewart, Robert wrote:
> > Tom Brinkman wrote:
> > > What is the point of having the source code, when it take an
> > > experienced developer many weeks to understand what
> > > the library is doing underneath?
> >
> > Write once code is easy to create, of course, but if you can't
> > grok what's in a Boost library, then don't bother.  Treat it
> > like a black box.
>
> Ah, the famous black box. I only wish the compiler would also
> understand that he has to treat the Boost library like a
> black box when emitting warnings and error messages. For the
> debugger, I even wish it could understand the semantics of
> the stored data, so that it could show me the data in a
> usable and easily readable format.

Diagnostics from templated code is a problem.  Better use of Boost.Concept Checking would help.  Concepts in C++ were to have addressed this much more completely, but had to be deferred.

Boost is not alone in regard to debugging issues.  Templates can make type names longer and more confusing, but it doesn't change the underlying issue: C++ type composition can be complex.  That arises from the ability of the language to better abstract complicated type relationships.

> > > What is the practical value of a library that can only be
> > > maintained by the original developer(s)?
> >
> > You write to the interface and if the library
> > provides useful functionality, you're golden!
>
> Even so I doubt very much that Boost libraries fall into the
> category of code that can only be maintained by original
> developer(s), your answer shocks me. In my experience, a
> developer that is not able to write code that can be
> understood and maintained by other developers sooner or later
> gets overwhelmed by the task to maintain his own unmaintainable code.

If a library can only be maintained by one or two people in the world, this would be a problem.  However, I took Tom's question as hyperbole.  There are many developers on this list who could maintain any Boost library.  There might be some need for education to gain specialized domain knowledge in some cases, but the techniques are not beyond a good number of developers on this list.

I take Tom's question as, if the everyday C/C++ programmer can't understand the library, it's no good to those programmers.  That's ridiculous.  Those same programmers probably would struggle to understand printf()'s or pthread_mutex_lock()'s implementation, yet they manage to use those functions having only read the documentation.  If Boost documentation isn't sufficient for those programmers to use the libraries, then we need to improve the documentation.

> > > If it takes more than a day to examine a libraries source code
> > > and have some idea what its doing, its very dangerous to use.
> >
> > I don't understand why a library is "very dangerous to use" if
> > you can't understand its implementation.  That just suggests
> > that you want Boost to be dumbed down for some arbitrarily low
> > experience level.
>
> Tom wasn't talking about completely understanding the code.
> He just said "some idea what it's doing". And he hasn't
> suggested to assume some "arbitrarily low experience level".

Really?  I wonder how much time he has spent looking at the source for his platform's runtime library.  Documentation explains things so you have "some idea what" a library is doing.  You don't need to understand the implementation for that.

> But I have to admit that it took me significantly longer
> "than a day" to have "some idea" of how "qt" is working. I
> definitely agree that it is dangerous to use a library
> without having "some idea what it's doing". The question
> whether "qt" is dangerous or not is more complicated. Now
> "qt" is indeed a bit dangerous, but so is any other
> reasonable GUI toolkit. But if the choice would be use "qt"
> or have "no GUI at all", taking the "no GUI at all" option
> might indeed be significantly less dangerous.

There are many examples of libraries that are difficult to understand -- and even beyond the abilities of many programmers -- but that doesn't mean they aren't usable.

> OK, now I drifted off a bit. My point is that I really have
> to disagree with your statement "I don't understand why a
> library is "very dangerous to use" if you  can't understand
> its implementation." Denying the need for quality is not a
> good response if somebody suggests you might have quality problems.

Perhaps I've enlightened you.  At any rate, I never denied "the need for quality."  I merely said that one needn't understand a library's implementation to make good use of it.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.