Re: [boost] New libraries implementing C++11 features in C++03

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-11-25 06:13:32

On Fri, Nov 25, 2011 at 9:58 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]> wrote:
>
> IMO, a library like any other software development tool, should assist
> us in the software development /process/.

What is a library but code? It's not a *tool* as it's not something
you use to achieve a goal, it's a *building block* an *ingredient* to
the solution.

Do you need examples to make it clear?

The compiler is a tool -- so is your editor, your computer, your web
browser, your operating system, etc.

A library is an ingredient -- so is every other piece of code you write.

To make it even clearer, look at a blender and whatever you can put in
a blender -- the blender is the tool and the stuff you put in are the
ingredients to whatever you want to make. The tool should assist you
in the process of making software -- the ingredients are just
ingredients.

Now, if you don't know how to use the tools properly (or if you're
cooking, don't know how to cook), it doesn't matter what your
ingredients are because if you're doing it wrong then whatever comes
out of it doesn't count. If you did not achieve the desired result,
it's no fault of the tool or the ingredients.

How does the ingredient assist you in the process of making food aside
from its mere presence? See how illogical that question is?

> Having a code that compiles
> and later that runs with no known bugs are just two stages of such a
> process. Another earlier stage is to have code that does not compile.
> This stage is still part of the software development process, and I'd
> expect libraries and other tools (editors, compiler errors, etc) to
> assist us in making the code compile.

What does the library have anything to do with the compiler?! Again,
the compiler makes the error messages and you are writing incorrect
code. I do not see how it's the fault of the library if the library's
provably not at fault (i.e. doesn't have bugs).

> Therefore, I reject the argument
> "which makes that advantage null and void because IT'S NOT AN
> ADVANTAGE BECAUSE YOUR CODE DOESN'T COMPILE", on the contrary the
> advantage remains as a better tool that help you making the code to
> compile with no error and therefore serves one step of the overall
> software development process.
>

You can reject anything you want to reject but if you can't put
forward a logical argument to support your proposition, then I'm
afraid it's going to be hard to convince anybody.

> HTH,

I hoped so too, unfortunately it kinda doesn't.

Cheers

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