[Hana] Formal review
Dear all, Following is my review of Hana. - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes, absolutely, but please read on. - Are you knowledgeable about the problem domain? I've been playing with metaprogramming as a hobby since 2011 when I first came across Boost.MPL. I experimented with a library that implements the unification algorithm at compile time using Boost.MPL for a long time, on and off, and recently I've decided giving a shot at my own implementation of a C++11 version of Boost.MPL. - What is your evaluation of the design? The design seems to be very general and abstract, based on formal mathematical concepts. I've had my dose of FP through SML and lisp, however I've never dug deep into category theory, so I won't venture into judging the way these abstract concepts were translated to C++, but all looks sound to me. I'm very fond of the way type computations are carried out by value through the use of type<> and decltype(). Such an ingenious simplicity. Once one gets it, one realizes how beautifully it merges value and type computations into one. I also like very much the design of compile time constants, their custom _c suffix and operators. To me, that is material for standardization. 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. - 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? 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. 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. - 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. - 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. - 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* [1]: https://en.wikipedia.org/wiki/Unification_(computer_science) [2]: https://github.com/ldionne/hana/issues/149
Bruno Dutra <brunocodutra <at> gmail.com> writes:
[...]
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
On Jun 22, 2015 5:25 PM, "Louis Dionne" <ldionne.2@gmail.com> wrote:
Bruno Dutra <brunocodutra <at> gmail.com> writes:
[...]
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.
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.
- 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.
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
Bruno Dutra <brunocodutra <at> gmail.com> writes:
[...]
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.
Isn't the tutorial already built like that? From my POV at least, the tutorial gently introduces the library without ever mentioning the word Functor/Monad, and the rest is left to the reference. However, the tutorial could arguably contain an introduction to those concepts, which would also act as a rationale for ditching more classic/less general non-FP concepts. I think reorganizing the reference documentation so that concepts stand on their own and algorithms stand on their own would also help a lot. This way, you wouldn't have to really understand the "black magic" to get down to work, but if you want to extend the library then you would still benefit from having very general concepts.
[...] 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.
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.
Yes, this.
[...]
Regards, Louis
On Tue, Jun 23, 2015 at 2:17 PM, Louis Dionne <ldionne.2@gmail.com> wrote:
Bruno Dutra <brunocodutra <at> gmail.com> writes:
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.
Yes, this.
+1
Zach
participants (3)
-
Bruno Dutra -
Louis Dionne -
Zach Laine