Bruno Dutra
[...]
I would like to point out however, that from the point of view of someone 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 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 implementation?
I've just briefly peeked at the code base out of curiosity and it looks pretty clean and organized. The use of global function objects however intrigues me, why not free functions?
Function objects can be used in higher order algorithms, while overloaded functions can't.
I've also found myself stumbling on variable templates. Perhaps that's just me, but really I find they make everything so cryptic. Anyways, I guess it's not Hana's fault to make arguably good use of something that is part of the language.
- What is your evaluation of the documentation?
I find myself blindly using the search button in hope to find whatever I'm looking for more often than I'd rather do, but perhaps it's just a matter of getting used to how the documentation is organized.
I think it's also a matter of reorganizing the documentation. The current layout is great if you know the concepts by heart (great for me), but not so great otherwise (so for everyone else). This was raised a couple of times during the review and I'll try to improve the situation, but that might mean switching away from Doxygen, which is not a slim task.
One thing I'd like to see improved is the alphabetical index. I'd expect it to be thorough, but at least "is_a" is missing, so I assume a rationale exists to decide what goes there? I think it would be better to list everything exhaustively, so users may rely on the browser's find tool to explore the library.
I guess that's because `is_a` is a variable template or something like that. Frankly, instead of fixing this specific issue, I'll put energy on finding a different documentation tool.
- 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 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.
- Did you try to use the library? With what compiler? Did you have any problems?
Yes on Clang 3.6.1. I tried to implement the unification algorithm [1] at compile time using Hana and, though I haven't actually finished, I could see it would be straightforward. In fact I gave up on it when I found a bug which prevented the construction of optional maps, but not too long after I contacted Louis and opened an issue [2] it seems to have already been fixed on develop branch. I didn't test the fix myself though.
The bug is now fixed on develop.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
About 4 hours reading the documentation, another 4 hours trying the library and about 2 hours to write this review.
*Bruno C. O. Dutra*
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