Niall Douglas wrote
On 3 Aug 2014 at 11:32, Robert Ramey wrote:
To me the "type class" of the Hana library is a muddled re-implemenation of the boost concept check library. Its much more complicated and subtle and not as well documented and doesn't add anything to BCC.
You probably didn't mean to Robert, but that review came across as mean spirited. I'm going to assume you didn't mean it that way,
I don't mean to be mean spirited and I haven't made any comments referring to anything but the documentation and code. The statement above accurately summarizes my views after spending a couple of hours looking at part of the documentation. I realize that it's not positive - but I honestly think that Louis is on the wrong track here and I don't know how else to say this.
the same way you didn't mean it that way when you hassled Paul, also a GSoC student by the way, in his C++ Now presentation about porting AFIO to Boost.
well, I don't remember hassling anyone - at least on purpose. The only thing I remember about that presentation was mentioning that I thought that porting a new library to work with C++03 was not necessary to be considered for inclusion into Boost. I thought was unfortunate that he spent this (considerable) effort and said that had I known about it, I would have defended a decision not to do it. That's all I remember, so maybe I did hassle him. If so sorry about that. If you want to pursue this, feel free tocreate a separate thread.
Hana is different. This student engineer new to Boost and the way things are done here has tried to break new ground and do new stuff which demonstrates the power delivered by C++ 14 compilers. He's taken a very Haskell-y route, right down to the un-C++ terminology and not using STL idioms, but then so what if he has?
I understand that. But when I look at this I'm seeing a) re-invention of the wheel b) and the new wheel compares unfavorably with the wheel we already have.
The STL is an ancient legacy design, it may be time to diverge drastically, or it may not.
well, algebra is an ancient legacy design - but it's still quite useful. STL has a number of rough edges - but it had a clear understandable design so it will be around for quite a while. Certainly, with C++xx it might be possible to make something better, but we haven't seen it yet. We've seen some hints though - ranges touch on upon this. constexpr and the "melding" of compile time/runtime programming will yield something interesting and I suspect that this is what Louis is driving at. But we haven't arrived anywhere yet.
I have no idea if what he's done or how he's done it is the best approach - I'm not competent in this area like Eric or Joel is. But how he went about the prior art research, the benchmarking of all implementation approaches, the presentation of his work at C++ Now before proceeding with implementation, all of this bodes extremely well indeed. Whatever he has done, it isn't going to be ill judged and muddled, that's for sure.
I'm aware of this and don't dispute it. This why that's why I took some time to make a good argument based sincere attempt to study things in depth as far as I could. I've made a sincere criticism based on references to specific quotes from the documentation and examples. If I'm missing something I'd be happy to hear about it.
Hana isn't BCC. It's far more -
I didn't say that hans is BCC. I said that hana type classes offer no more than BCC - I stand by that statement.
it's potentially a hint of how C++ in the 2020s could look like, which hopefully is not how things are currently done right now.
well, I've been flogging my ideas about how C++/Boost should look in the future. (So far with very little success). So I'm not unsympathetic to changes - in fact I think they are necessary.
I hope that the Boost culture is still able to welcome radically new ideas and new engineers and stride forth instead of this constant defence of the (ancient) past and its way of doing things as if we're losing something vital other than our membership, which if I can remind you, has been dropping for two years now.
My view is that Boost needs to improve the quality of it's product. Boost Libraries need: a) better design b) better conceptual integrity - easier to understand, better isolation between interface and implementation. c) better documentation - so far the only documentation approach which has really worked well is that implemented for STL which "formally" defines type constraints for generic algorithms. We need to build on that - not set it aside. d) Easier tools to make and submit libraries. e) more submissions f) more and better peer reviews. This is what drives me. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Typeclass-tp4665978p4665986.html Sent from the Boost - Dev mailing list archive at Nabble.com.