On Fri, Nov 25, 2011 at 6:08 AM, Daniel James <dnljms@gmail.com> wrote:
On 24 November 2011 11:58, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Thu, Nov 24, 2011 at 10:46 PM, Daniel James <dnljms@gmail.com> wrote:
On 24 November 2011 10:47, Joel de Guzman <joel@boost-consulting.com> 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