Re: [boost] Re: Re: MPL containers and algorithms

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-08-09 15:50:10

>From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>

> "Fernando Cacciola" <fcacciola_at_[hidden]> wrote in message
> news:005c01c23967$4aaf1c80$0f00a8c0_at_fernandoc...
> > I myself, *a priori*, find hard to believe that such fundamental
> > abstractions are useless in a different computational model. Their
> > different mutating/generative properties might be irrelevant, but not
their
> > different access capabilities .
> >
> > I won't come up with a sound example in the short/mid term mainly
> > because I might not find the need for it myself, but I think it will
come
> > eventually once MPL becomes widely used.
>
> An important detail that's being forgotten is the cost of a design. MPL's
> design introduces complications that make it hard to learn, hard to use,
> and the client code hard to understand. These are important costs.

Ease of understanding is also dependent on what you are used to. It's not as
if Loki was easy to read, once I started to learn about that, either. A more
fruitful path might be if someone are reasonably fluent in both kinds of
libraries, to read and write code for various tasks, and see what was found
more readable.

I have learned to read Loki's typelist code. Still, I find, when writing new
algorithms for it, that you tend to get lot of different specialisations,
that tend to, well, specialise the code. :) That is, you get a specific
solution to something, that may not generalise well. Also, the code tends to
be spread out, like this, which I think may make it harder to read, than if
it was in one place.

Having learned MPL, as well, I disagree with that it should be harder to
learn, harder to use, and the client code harder to understand, than a
library like Loki's typelists. It may well be the other way around.

Like I said, I think it has much to do with what you're familiar with.

In fact, MPL code resembles more run-time code, than Loki's typelists, which
means that you can use your experience with such code, when using it.

> If these costs are to be paid upfront, it would be nice if the benefit
> would be more than "maybe someday..."
>
> MPL has been out for a while and there still aren't examples that justify
> the presence of multiple containers, even from its own authors. I
> understand that MPL uses STL's design, and many say this is a hallmark,
but that's
> not an argument by itself. As said in another post, they use very
different
> means and have very different ends. It's art for the sake of the art if
it's
> not useful.

I think the means and ends are similar.

It's not clear to me what the differences would be, could you point me to
the posting you refer to, or elaborate?

Even if metaprogramming is implemented as functional programming, the
implementation shouldn't decide what are, or are not, useful abstractions.
If that was the case, then we'd use assembly code, because after all, that's
how it's implemented.

Regards,

Terje