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-07-31 18:28:24

On 31 Jul 2014 at 10:11, Eric Niebler 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. My type of programmer learns just enough 
of the verbiage to understand C++ Now presentations by programmers 
such as you (and I haven't failed to learn something new from yours 
yet), but we'll never think like you any more than you'll think like 
us.

None of this a bad thing of course, diversity of approach and all. 
But to me and people like me a RandomAccessIterator is a pointer and 
is little different to a ForwardIterator. I care about the difference 
only in so far as I can use it to get the compiler to generate code 
one way or another according to need. I furthermore care about the 
difference only in so far as it will get later maintainers and team 
members to behave one way instead of another. Past that I feel no 
issue reinterpret casting STL internal types to bypass the type 
system if that gets me the assembler output I want and doesn't create 
maintenance debt later.

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. I absolutely 
can't wait for language support for Concepts, and will use them with 
vengence when they turn up as they're another great tool for bending 
the compiler in new ways, but until it's fully baked as a language 
feature they get in my way. And hence I don't use them personally, 
and groan every time I'm faced with code by someone who has (no 
offence intended here, we all have our own personal likes and 
dislikes, and I entirely understand your opinions on this and respect 
them, I just don't have those opinions myself).

Niall

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