[boost] Re: Re: Adding Loki to Boost (reprise)

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-04-12 09:44:27

"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
news:a9669r$1kl$1_at_main.gmane.org...
> If you define "simpler" as a synonym to "uses less ''advanced''
concepts",
> then, well, yes. But by that definition
>
>     int* v = new int[100];
>     // ...
>     int i = 0;
>     for (; i < v.size(); ++i)
>         if (v[i] == 5) break;
>
> is definitely simpler than this:
>
>     typedef std::vector<int> something;
>     // ...
>     something v;
>     something::iterator i = std::find(v.begin(), v.end(), 5);

I believe this is not a reasonable comparison. The STL does make life
simpler to the programmers, otherwise they wouldn't use it.

This whole parallel of MPL with STL is, in my opinion, unfounded.

> Reuse of these "artifacts" is the power that allows MPL to be much
more
> generic and portable; it also enables performance optimizations
applied in a
> single relatively low-level component to be propagated through the
rest of
> the library. Arguing against this kind of reuse is like criticizing
> 'std::vector' implementation that uses '__construct' and '__destroy'
> "instead of" bare placement new and explicit loop with destructor
call.

(I'm not sure what optimization - perhaps optimization of compilation
times? )

Again, I believe that bringing the STL as a comparison is not valid as
an argument in our discussion.

> How about the above code snippets? Would you say that the first one
is
> easier to write, read, and understand? It doesn't define any new
types, and
> definitely does not rely on any other "artifacts", - not to speak
about
> "simplicity".

But we are talking about completely different things. STL does help,
does simplify, does improve. Without doubling your source code size
and making it incomprehensible.

I really understand it is very uncool that I criticize mpl like that,
especially to its own developers. In particular, this is a bad time to
do so - a time when I need, and asked, for boost's support (without
getting any, sigh). Let me restate there is nothing personal about
that, and I truly hope there is nothing personal in the responses I
receive. But I just can't stop telling my opinion, because I believe
it is sound and that I have valid arguments to support it.

This being said, it is a surprise to me that there's no consensus that
MPL's find_if is much more complicated than the version I posted. To
me it is obvious. It is so obvious, that I thought there's going to be
no discussion about it. I thought the argument in MPL's favor is that
it makes complicated things simple. A convincing argument would be:
"Well, I agree that count_if is big and hairy, and can't be understood
but by an MPL savvy, but look, here's a nice example of MPL solving a
real, hard problem, in a very cool manner! How about that?" So it
seems like we can't find agreement on the simplest premises.

So MPL's message to me is the following: "I'm a library. Things that
you were doing in a simple and elegant manner, I will have you do in
an ugly and mightily complicated way. But in exchange, I offer you
flexibility in a direction you could care less about. There is no
example to this day witnessing that you should."

> > I understand that count_if is more general, so it is entirely
acceptable
> to
> > pay a cost in ease of understanding for the benefit of generality.
The
> > question is whether that generality is worth the price in
complexity. To
> me
> > it looks like it's not - the type processing needs I have are
satisfied by
> > dot-lists and simple algorithms such as count_if above.
>
> Well, ours are not.

I understand that.

Andrei