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

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-07-31 20:26:07

On 7/31/2014 6:28 PM, Niall Douglas wrote:
> 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).

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.

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.