Re: [boost] [Hana] Formal review

Subject: Re: [boost] [Hana] Formal review
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2015-06-23 08:45:25

On Jun 22, 2015 5:25 PM, "Louis Dionne" <ldionne.2_at_[hidden]> 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