[boost] Comments on MPL

From: David B. Held (dheld_at_[hidden])
Date: 2002-08-01 14:26:40

I have seen the analysis of MPL which compares imperative vs. functional,
but I would like to offer a different view.  The imperative vs. functional
view
looks at the form of metaprogramming, but not necessarily the features.
Ultimately, you can do essentially the same thing in either paradigm.  I
think the more important distinction is between concrete and generic
programming.  Consider this hierarchy instead:

[Programming]
    Concrete            Explicit types
    Generic              Implicit types
[Metaprogramming]
    Concrete            Explicit metatypes (e.g. dot-lists)
    Generic              Implicit metatypes (e.g. MPL iterators)

As far as I can tell, the argument so far goes: "We don't need generic
metaprogramming, and it costs more, so let's cut the fat".  I agree that
demands for generic metaprogramming are probably few and far
between.  But I don't think that's MPL's fault.  Rather, I would say that it
is simply a library born out of time.  I think it's so far ahead of its time
that we haven't even figured out how to harness its power.

Someone once said of Superstring theory that: "It's a 21th century
theory dropped into our laps in the 20th century".  The problem is that
for the first time since Newton, physics has outstripped the pace of
mathematics, and math has to catch up.  Perhaps it's a bit optimistic,
but can I suggest that MPL: "is a 21st century programming paradigm
dropped into 20th century laptops"?

I'll be the first to admit that I have a hard time thinking in meta-
programming terms.  Writing generic code is easy.  When you see
something repetitive, you look for ways to abstract the type.  Knowing
*when* to do metaprogramming is also easy.  When you can make a
decision that does not depend on runtime behaviour, try to write
metacode.  Knowing *how* to do that is hard.  But there's an even
bigger problem.

Templates were originally designed to ease the burden of repetitive
code, and it didn't take long to see that the million different versions
of linked lists could be abstracted into a single generic type.  Similarly,
meta-templates (if I may invent a term) are designed to ease the
burden of repetitive meta-code.  However, there just isn't enough meta-
code in the world to make it obvious that we need a meta-generic
linked list.  Obviously, part of that problem is that it's hard enough to
just write a meta-concrete linked list (I can probably count the number
of people I can name that know how to do this on a few hands).

Now, I think that MPL will help the situation in two ways.  First, I think
it will make it easier to write concrete metatypes.  And second, as
we get more experience in the metaprogramming world, we will
eventually recognize repetition that can be eliminated by generic
metaprogramming.  And lucky for us, MPL will already be there.  But
it is not at all suprising to me that the demand for generic
metaprogramming is being sought and not found.  I personally do not
think that compile times are a sufficiently scarce resource to motivate
the design of MPL.  I think that MPL is important for a much bigger
reason: I think it is a design that we will "grow into" only after much
experience with metaprogramming.  When the average "trench coder"
can write metacode as easily as Bubble Sort, the value of MPL will
become as obvious as the value of the STL is today.  Unfortunately,
the true value of MPL probably *won't* become obvious *until* that
time.

Dave

P.S.  In the mean time, since MPL has dot-style lists, I don't see why
people can't use those as the concrete metaprogramming subset of
MPL.  I see it like using std::string, instead of std::basic_string<>.