Re: [boost] [Hana] Formal review

Subject: Re: [boost] [Hana] Formal review
From: charleyb123 . (charleyb123_at_[hidden])
Date: 2015-06-19 11:45:31

>
> > > <snip, concern over Hana header-lib-size>
>

> > > However, even though you may be content with the ease of writing TMP
> code in
> > > C++14, I think you might be surprised to see how shorter it could be
> if you
> > > used Hana. This is, for example, the case of Zach's Units-BLAS
> library. It
> > > was really quite short with C++14 only, but it was even shorter with
> Hana.
> > > And the code was written with a higher level of abstraction. And in
> that
> > > case, there was even a compile-time speedup over std::tuple +
> handwritten
> > > stuff.
> >
> > "really quite short" is good enough if the cost is having to depend on
> > a "32k header mega library" as David notes. Not to mention having to
> > learn another library for me and for all future maintainers.
>

 Louis Dionne respondeth:

> Regarding the "32k header mega library" thing, I'd like to precise that
> it's
> not as bad as it seems. First, part of it is just documentation. Second,
> that's
> a _real_ 32 kLOC, not a 100 kLOC of dependencies hidden behind a 5 kLOC
> library.
> Hana as no dependencies except the <type_traits>, <utility> and <cstddef>
> headers, which you probably already use anyway. In comparison, including
> almost
> any other Boost library will pull in a lot more than 32 kLOCs in
> dependencies.
>

This.

For TMP libraries, and particularly for their application in large
production codebases, I conclude the following pattern tends to hold:  MORE
IS LESS.

Paraphrased, this would be, "More reusable code in libraries means less
application-specific code is necessary, so the program is more feature-rich
and functionality evolves better over time."

Explanation:  A "richer" (well-defined/implemented) library tends to
provide non-linear value improvements over a "smaller" library.

In large codebases, a "more-complete" library is superior because:

(a) (Real-world) Corner cases are addressed.  When confronted with a given
corner case that is unaddressed by the limited ambitions of the smaller
library, you write adapter layers which can be brittle or expensive in many
ways, and which possibly don't really do what you wanted.  These tend to be
inconsistently adapted/used across the codebase, which is bad, because it
should have been centralized somehow (such as through a reusable library).

(b) It becomes unnecessary to also rely upon other (overlapping) libraries
that usually offer a different metaphor, but which sufficiently overlap
with functionality as to cause confusion among developers (because there is
now, "more than one way" to do some things).

(c) Efficiencies are possible within the library implementation.  Those
additional corner cases can be addressed and short-circuited, but as we all
know, for TMP this often relies upon more (partial-)specializations
(requiring more code).

I like Hana's approach because it is unifying, and presents a single
consistent model.  Like Zach said, I don't see it as "big" -- I only care
about that small interface that is relevant for my needs, and my
production-code is smaller/less.

That 32K includes extensive comments (which can be stripped if necessary),
but I think it's particularly awesome that it is truly uncoupled from
almost everything (needing only <type_traits>, <utility>, and <cstddef>).

CAVEAT:

My assertion in support of "comprehensive" (as opposed to "minimal")
libraries breaks down when the library is not well designed/implemented.

Many "big" libraries have bad APIs (usually because they evolved over time
without the necessary refactoring), and are spottily-implemented (usually
because that's work, and the maintainer is tired).  In these cases, the
"More Is Less" does not hold as well.

I don't see this as an issue with Hana -- it has strong and consistent
implementation supporting a conceptually consistent API.

<snip, make compiling faster>

> To do much better, we would probably need a compiler-provided closure type.
> Basically, std::tuple as a compiler intrinsic. I think this could be
> lightning
> fast, but we're not there yet.
>

Hey, that's a really great idea.  I could come up with lots of uses for
that.

--charley