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

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-08-03 12:58:36

On August 1, 2014 5:57:30 AM EDT, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
>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.

I have to assume you're using hyperbole to make your point. C++ has types and it has classes, so I can't believe you perceive it otherwise. OTOH, I can imagine that you see those things merely as levers and knobs to produce the desired machine code.

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

You use abstractions whenever you discuss real world objects. In fact, you use them in any natural language conversation. I'm sure you use them in programming conversations, too. Consequently, I think you're overstating your case.

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

Concepts are so much noise in introductory documentation. However, for detailed and reference docs, they are indispensable to avoid repetition and to reveal similarities and differences among the types on offer by a library. I wonder if your complaint is more about their use on specific cases than about them on general.

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

Your view of programming languages and libraries as means to an end doesn't mean you don't have to know the languages and libraries you happen to use. Documentation use natural and programming languages to convert information. Human communication uses abstractions for efficiency. Good abstractions are helpful, even to someone like you, aren't they?

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

Differences are often beneficial. They can also be a source of friction. However, to my knowledge, I've never before encountered anyone with your view of programming in over 30 years of programming who wasn't using assembler.

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

I don't think anyone has suggested that concepts solve all documentation problems.

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

That's the purpose of good naming, clean APIs, and good documentation generally.

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

I suspect, like me, he's never encountered someone like you. While the specific does not the general make, it certainly informs one's views.

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

I'm not sure where I fit in your taxonomy, but I dislike Boost.Filesystem's documentation because Beman wrote it as if it was to be submitted for inclusion in the Standard, while providing little other information. I read the Standards, and I can extract beneficial information from them without a lot of difficulty, but it isn't helpful when trying to learn about something for the first time.

The same can be said for a manpage, which you mentioned below. They are focused on giving reference details, not on providing tutorial and introductory information, though they do take a step away from standardese, which is helpful.

> 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 want both. The former is the contract, the latter is the summary.

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

As do I.

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

Flawed concept checking does not negate the value of concepts for the documentation. It just makes them less helpful at compile time.

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

Setting aside your view of languages as the means to the end of bits flowing over a landscape, I agree.

> 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 
That's a misguided view. I choose C++ because it's multiparadigm. It provides low level tools, OO, meta-programming, etc.

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

I'm interested in improving my and other's ability to use C++ effectively.

___
Rob

(Sent from my portable computation engine)