Boost logo

Boost :

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-08-01 05:57:30

On 31 Jul 2014 at 20:26, Edward Diener wrote:

> >> On 07/29/2014 05:14 PM, Niall Douglas wrote:
> >>> I'm all for Concepts as in compiler enforced ones, and I'll add them
> >>> to AFIO when and only when C++ gets them. But for documentation they
> >>> don't help.
> >>
> >> Wow, I couldn't disagree more. I can't imagine how the standard
> >> algorithms would be specified without the use of concepts like
> >> "RandomAccessIterator", for instance. Clustering requirements into
> >> meaningful abstractions and assigning them names makes it possible to
> >> document library interfaces without an explosion of verbosity and
> >> repetition.
> >
> > Oh I know programmers similar to how you visualise code in your head
> > would agree with you absolutely. But you must remember programmers
> > like me don't see C++ as really in fact having types nor classes nor
> > concepts - I just see methods of programming the compiler to output
> > patterns of assembler code, and I think primarily in terms of chains
> > of assembler instructions.
> > [snip]
> > It's the essential difference between language-focused coders and err
> > ... mongrel coders? I have to admit I'm not sure what to call myself
> > really. Either way, I see ConceptCheck as a half baked feature giving
> > me nothing useful but bloat and complexity and significantly adding
> > mess to documentation and steepening my learning curve.
> With all due respect to your super-practical low-level approach I think
> you must know that you are very much in the minority. Practical
> programming, as you reflect on above, certainly has its advantages but
> without knowing what one can do with a programming language I see it as
> impossible to design robust code that is both understandable and usable
> to others and effective in accomplishing its goal.

Practical programming isn't the right term ... I'm going to borrow a
term Artur Laksberg used during my interview at Microsoft, let's call
it "data flow centric programming". At scale, those patterns of
assembler outputs start to look like stretchy sheets, and they come
together to form a sort of hills and valleys. You could say that each
CPU core is rather like a river trying to follow a path of least
resistance amongst that topology, and our job as programmer is to
apply transformations to the topology to yield new flows of river. It
is rare that applying any transformation isn't a zero-sum outcome,
and that is where skill and experience comes in.

When visualised in that way, there is no essential difference between
programming languages, or operating systems, or the humans working on
those systems. They're all programmed the same way.

Advantages include agnosticism towards languages, OSs, idelogies ...
disadvantages include inability to relate, communicate or otherwise
transmit meaning to other engineers, except those of a similar bent.
Most engineers accept the difference as a good thing adding an
uncertain value, but the occasional one feels it as a vital threat
that must be destroyed at all costs, which is unfortunate. That can
introduce politics into engineering, which is usually a bad thing.

> I do not think 'concepts', aka largely 'type constraints' as Robert as
> aptly renamed it in this discussion, is a panacea for every template
> programming problem. But understanding the 'domain' of what a 'type'
> entails is just as important as understanding the 'domain' of some
> parameter in a function call. Without documentation of such things the
> user of your constructs has no idea what will work and what will not
> work and programming then becomes and endlessly wasteful game of trial
> and error.
> Nor is that really 'language-focused' programming. Its just programming
> that takes into account that others must usually be able to use what you
> create else it is worthwhile only to yourself and your own solution to a
> problem.

You're making the enormous assumption that all worthwhile programmers
think like you and have the same value sets you do e.g. that domains
have any relevance to parameter types at all, or that outstanding
quality code cannot be written without a language-based approach. One
of my biggest problems with Boost code and its documentation (and the
C++ 11/14 STL additions) is that meaning as well as implementation is
scattered all over the place in fragments. Languagey type programmers
grok that much easier than I or most on StackOverflow do, probably
because they instantly spot the nouns and the verbs and type systems
are natural to them. Me personally, I'm old fashioned and I'd like my
API documentation to tell me what the API actually does and how it
fits with other APIs like a man page does rather than a single line
comment and many hyperlinks to all the semi-concept types being input
and output. I also want to see an essay at the beginning on the
philosophy of the design (what I normally call a design rationale),
because that will tell me how it all is intended to hang together.
After all, as a result of the lack of direct language support there
are many Concept check designs, each incommensurate with the others,
hell even the STL itself has at least two if not three separate ways
of Concept checking, none of which are fully baked either.

In truth, despite your assertion of me being in a minority, I suspect
my sort of programmer is probably the majority in C++ if not in
Boost. If you want a pure or elegant type system you wouldn't choose
C++ for example - in fact, if you cross off the list of reasons, the
only reasons that *anyone* would intentionally choose C++ is down to
(i) potential bare metal performance and (ii) it is also C which is
useful for low level work and (iii) the tools and ecosystem are
mature. That ought to bias against languagey type programmers, though
for obvious reasons the best of the field whom I would assume would
like to congregate here or on ISO are much more likely to be
languagey type programmers as they are interested in C++ as a

One of my great hopes for Hana and why I am so excited by it is that
we might finally get a reasonably good standardised way of doing
abstract base templates for template classes. Concept check
implementations have tended to use class inheritance in the past due
to lack of language support to do otherwise, while libraries such as
Fusion have used a ton of hand written metaprogramming which makes
them very slow and brittle. Hana has been written to be fast which
solves my first objection to using Fusion in any production code, the
enormous question still remaining is how brittle or not it will be to
use in real world code. Can I use Hana to stamp out entire families
of STL iterator so I no longer have to write my own for example? Will
it be easy for me to adjust entire families of STL iterator both from
the top, in the middle and the bottom without tons of compiler error
spew? Will the users of my iterator never notice that I used Hana

Those are open questions of course, and it will be some years before
I can use Hana in any code expected to be portable sadly :(


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at