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

From: Emily Winch (emily_at_[hidden])
Date: 2002-04-10 13:22:24

Andrei Alexandrescu <andrewalex_at_[hidden]> wrote:

>"Emily Winch" <Emily.Winch_at_[hidden]> wrote in message
>news:77D94A9BDCEFD3119DF100D0B73EA6A8014A6D05_at_teleca126...

>Ok, I'll try to detail my view. (Warning, many "I"s and "me"s ahead,
>again. This is to protect myself for making wrong generalizations.) My
>problem with mpl is that I see it as an abstraction going in the wrong
>direction.
>
>The C++ template engine is a Turing complete, pure functional
>language. In pure functional languages recursion is natural, iteration
>is ab(d)ominable. This is a fact, and I believe anyone would agree
>with that.
>
>I personally programmed non-functional languages most of the time, but
>I prefer "nice code" to "non-functional code at all costs".
>
>MPL strives to add non-functional abilities to the template engine. It
>features loops, iterations, iterators, and the such. The intellectual
>effort invested in it is impressive. After all, MPL works in a
>language that's completely unfrendly to what MPL wants.
>
>As much as I am impressed with MPL's intellectual investment, I am
>completely underwhelmed by its approach by large, and in principle. (I
>am sorry, there's nothing personal to MPL's authors. That's how I
>feel.) I would look the same at a package that adds iterations, loops,
>etc. in Haskell. I am much more comfortable with iteration than with
>recursion, but again, in Rome do what the Romans do: Haskell does not
>like loops, and neither does C++'s template engine.
>
>So I ask: why? To what end?

If extra features that you don't want come at no cost to you, does it matter
that they are supported for people that do want them?

>What I think would be reasonable to ask, for example, is a basic "list
>of types" facility, with typical primitives for lists of types:
>append, erase, find, etc. Yet I cannot look at MPL's incarnation of
>these simplest facilities, without shrieking in horror. And I imagine
>that the error messages generated by mpl's misuse are really bad, but
>that's a moot point - all template error messages look bad :o).
>
>By comparison, Loki's typelists are - to me at least - an example of
>elegance and simplicity. They are just so cool and elegant. And in all
>honesty, I hope I'm not being blurred by the fact that they're
>implemented by myself. I'm proud to show loki's typelists to any
>fellow programmer; I'd be ashamed to show mpl's typelists to even
>expert C++ programmers.

Personally, (this isn't meant to be a generalisation) I don't care what the
implementation looks like. I don't care if the idioms under
the hood fit naturally to the language or not. I do care whether it's
(comparatively)
easy to learn and easy to use, and whether it supports all the things I want
to do with it. Does the MPL fit these criteria? Do the Loki typelist
facilities?
This is, to me, a more fruitful line of discussion.

There is also definitely an argument that a C++ codebase, of all places, is
somewhere that you cannot sprinkle idiomatic functional code mixed in with
things from dark corners of the language, and expect all the people who have
to touch that codebase to be able to maintain it. The functional way of
thinking
is a big paradigm shift for your average C++ programmer (me for example!).
Sometimes it's tough even for functional programmers. How many of the more
widely used functional languages have _no_ facilities for non-functional
programming?

[ I snipped some stuff ]

>I guess all of the above is not very constructive, and I am truly
>sorry about that. The least thing I want to do is to cause more
>discussion in contradictory.

I think a good way to generate some more constructive criticism, and to shed
some light on this debate, is to wait until the documentation for the MPL is
sorted out. Like a lot of libraries, it isn't something that I'd expect
people to learn
to use by inspecting the code, and I think a lot more people will feel able
to comment
on it once they have read the documentation.

Emily