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/