On Jun 22, 2015 5:25 PM, "Louis Dionne"
Bruno Dutra
writes: [...]
I would like to point out however, that from the point of view of
who has basically solely done C++ his entire life, just like myself, Hana can look *very* unfamiliar. I understand it is mostly my fault for not properly having learnt FP before, however I believe I'm not alone among average C++ programmers, so I fear this could prevent many potential users from adopting Hana, simply because one tends to stick to things that look familiar to one.
Now I'm not sure that is any easy way around this unfamiliarity. I've seen others pointing out that names could better reproduce the C++ standard library (to what I agree) and perhaps that's indeed all one could do to tighten the gap that separates Hana from mainstream C++ libraries. At any rate, I just felt I should stress this point, to make sure it is not underestimated.
I feel like a lot of the functionality provided by Hana can be used without understanding advanced FP concepts. I'm referring (essentially) to the contents of the cheat sheet at the beginning of the tutorial. These algorithms are in essence just algorithms on tuples, and they are very similar to
someone their
STL equivalents.
However, it is true that Hana is biased towards FP concepts, and for several reasons. First, these concepts are very general and they give a lot of flexibility. For example, I don't know many ways to define `filter` on an Optional value, but it works when you go down the Monad road.
Secondly, organizing a lot of things around Functor (and the related FP concepts) matches the compiler's execution model quite well. Indeed, this allows expressing algorithms around the concept of "mapping a function over a structure", which is efficient in the case of parameter packs.
Thirdly, heterogeneous programming prevents the use of a lot of mutation, because most of the time you need to create a new object (with a different type) to hold the result of an algorithm. Assigning this result to an existing value wouldn't make sense, since you don't know the type of that result beforehand. __Most of the time__.
Finally, there's my own personal bias. I wanted to dig deeper into category theory and functional programming, which I did via this library.
- What is your evaluation of the potential usefulness of the library?
At first I was afraid Hana were too academical and abstract to be a good tool for getting down to business, but after playing with it a little bit I can see that, once one gets its design, it does make metaprogramming quite straightforward.
I believe however that most users will attain to a very limited subset of functionalities in order to just get their tasks accomplished. So much so, that I'd strongly advise Hana to be split into one highly specialized tool for straightforward metaprogramming and another more abstract halve providing the more generic concepts. This could ease user experience considerably, reducing the novelty presented by Hana and thus tightening the gap I've mentioned before.
I think there is some desire from the community to have a very simple
I totally get it, there's nothing wrong with the design, very much on the contrary, however, I fear Hana's generality could be too overwhelming for many potential users. What if the documentation presented Hana without mentioning the abstract concepts at first, focusing on the minimum set of well known algorithms which could get any simple job done, then, at a section called " Advanced Hana" (Advanced Black Magic would be even more precise ;)) hana could be presented once again, but this time with all those concepts in hand? I think this way it would be much more didactic. library
providing tuple algorithms, without concepts and anything else. I can understand that, and I will see if Hana can be modularized in a way that makes the core functionality usable without the rest of it.
However, I am under the impression that it would be better to simply create a separate library. I'll make some experiments and time will tell.
Perhaps, instead of actually splitting Hana, it would suffice for now to "logically" segregate the more advanced concepts in the documentation, as I suggested above.
Thanks a lot for your review, Bruno. I'd also like to thank you for your comments and questions on Hana prior to this review, and your challenging opinions about the future of metaprogramming for C++.
Regards, Louis
It has always been a two way street, thank you Louis. Regards, Bruno