Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2010-03-23 18:15:55
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.
> > 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 it takes more than a day to examine a libraries source code and
> > have some idea what its doing, its very dangerous to use. This issue
> > will cause many to avoid complex templated macro-style boost
> > libraries.
> 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".
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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk