Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-06-22 15:41:18

Daniel James wrote:
> On 22 June 2012 18:30, Robert Ramey <ramey_at_[hidden]> wrote:
>> Stewart, Robert wrote:
>>
>>> The more dependencies you
>>> introduce, the more fragile your code becomes, but there's a great
>>> deal of benefit to reuse, too. The only issue in this case is that
>>> one can reasonably expect a top-level header to avoid dependencies
>>> on libraries.
>>
>> Personally I wouldn't say it's the only issue. But I'm glad we can
>> agree that it's its a BIG issue.
>
> There are a lot of headers violating your rule.

assuming that's true, it's a bad idea there as well.

> What problems has it caused?

lol - this discussion for one.

But your comments are sincere and really deserve a more serious answer
so I'll try to supply one.

TL;DR

Someone comes up with some idea for a program/application/library
or whatever.  This idea is meant to solve some problem that this
person has in mind. At this point - any subsequent point, this idea
will move in two directions

a) It will become more specific and narrowed in scope and evolve
into a very clear concept what can easily be grasped as to what it's
function is.  We have great examples of this in boost - shared_ptr
static_assert.  Deeper understanding

How to recognize a)
1) You use it or incorporate into your app in a very short time
because it's easy to understand what it does and how to use it.
2) you use it and you forget you used it because it caused no
surprises.
3) It works for years without a hassle
4) it saves total work - rather than expanding it.
5) if anything breaks - its easy to find the cause and the
person who should fix it.

b) It can evolve into a more amorpheous and all encompassing idea
that looks more like a "bag of features" rather than a coherent concept
which one can understand immediately and systematically
unwrap to understand at a more detailed level.  We have some
software in boost which exmplefies this.

How to recognise b)
1) It might look simple to use, but turns out to consume a lot of time
when you try to use it. (I love it when a salesman demonstrates how simple
something is to use and I take it home - and damned if I'm not mystified
by it!)
2) It's has surprising behavior
3) It breaks when you don't expect it
4) if you complain - it's "your fault" because you didn't understand how
to use it, didn't read the docs, didn't look the code or whatever.
5) It adds total work rather than diminishing it.
6) it becomes hard to determine who is responsable for problems
when they occur.

Of course these are idealized descriptions no library/application will
fall 100% in either camp.  This description applies to a lot more
stuff than just software - see the book "The design of everyday
things".

Even if the idea is seems clearly defined, as time goes on there is
a huge amount of pressure to add "just one feature" because
someone would find it useful. The result is that the original idea morphs
from a clearly defined purpose to some sort of .... well hard to describe.
The project start's to suffer from the symptoms in b) above.

Projects in the "b)" category tend to grow and die of a combination
of obesity, weakness, lack of direction.  Basically they tend ot become
victims of their own success.

I realize this is "just one feature which a lot of people would find useful"
but who speaks for the people who don't find it useful? I do.  You're
thinkng this is a one time special case.  But it's not.  I fight a constant
running battle to keep the serialzation library from evolving into something
that is unmaintainble, overly bloated, harder to understand and use, etc.
I can't tell you how many times I've had to disappoint someone who
feels they need this "one more tihng".

So now maybe you can understand how I can object to having this
"great feature" injected into the library without my knowing about it.

I'm not intending to be the "savanorla" of boost, C++, or software
developement practices. I just happened to be the person at the scene
of this particular accident.

Robert Ramey