Re: [boost] [GSoC] [Boost.Hana] Formal review request

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 
language.

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 
underneath?

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 :(

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/