Re: [boost] [Boost.Local] Review

Subject: Re: [boost] [Boost.Local] Review
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-11-24 21:28:38

On Fri, Nov 25, 2011 at 6:08 AM, Daniel James <dnljms_at_[hidden]> wrote:
> On 24 November 2011 11:58, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
>> On Thu, Nov 24, 2011 at 10:46 PM, Daniel James <dnljms_at_[hidden]> wrote:
>>> On 24 November 2011 10:47, Joel de Guzman <joel_at_[hidden]> wrote:
>>>>
>>>> It saddens me to see TMP-phobia creeping into Boost, of all places! :(
>>>
>>> To use something effectively requires understanding the disadvantages.
>>
>> I always thought it was that to use something effectively requires
>> understanding the problem and whether that thing you have can be part
>> of a solution. Disadvantages only come into play when you're covering
>> the downside. If the tool is the right tool for the job and you know
>> how to use it, would understanding the disadvantages stop you from
>> using the tool?
>
> No, I'm not saying "don't use it". I'm saying that understanding and
> acknowledging the disadvantages lets you make better use of the tool.

Why do the disadvantages make you use the tool better? Shouldn't the
advantages do that instead?

> When someone says that it's difficult to use, the response seems to be
> to argue with them and tell them they're wrong. That's not solving the
> problem, it's making it worse.
>

When someone says it's difficult to use, it doesn't say anything
useful. Difficult is relative -- difficult compared to what? Because
it's a very relative thing (like whether something is ugly or
beautiful) discussing anything that pertains to 'difficulty'.

What are the problems can be solved? Those that are demonstrably
quantifiable. If the problem is there's 100KB of error messages
generated by compiler A using library X, should it be a matter of the
library being broken automatically or should it be that the compiler
is broken? I'd wager if the compiler didn't barf 100KB of error
messages for a seemingly "innocent" mistake done by the human in the
equation, then maybe that human wouldn't be complaining regardless of
whether library X was used or not.

I just want to be clear here: there are two tools involved, one is the
library and the other is the compiler. Fixing the correct broken tool
should be the solution. Any discussion on fixing the wrong "not
broken" tool is moot.

>>> You can't wish them away with a silly label. If people find something
>>> difficult to use, then it is difficult to use.
>>
>> ... for those people. That doesn't necessarily mean it matters whether
>> they find it difficult to use if it's effective when it works and used
>> correctly. Does that remind you of a programming language we all use?
>
> Much of boost deals with reducing C++'s usability problems. For one
> example, look at how shared_ptr deals with deleting objects that were
> allocated in a shared library.
>

No, much of Boost deals with improving C++'s usability _when the code
compiles_. When the user's code doesn't compile then all bets are off,
no library can manage what the compiler spits out in case there's an
error in the code.

Cheers

-- 
Dean Michael Berris
http://goo.gl/CKCJX