Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Dave Gomboc (dave_gomboc_at_[hidden])
Date: 2014-08-03 21:07:25
> > [pfultz2]
> > Yet it uses a lot of foreign functional concepts. Despite what google says,
> > boost libraries are built around mostly C++-like 'interfaces'. I don't think
> > its bad to introduce some functional-interfaces, but I know in the past
> > libraies that libraries that were very functional were rejected from boost,
> > because many people didn't grasp the purpose of them. So introducing a lot
> > of functional interfaces on the surface of a library can hinder its adoption.
This is a solid caution. Louis, it would be worth your while to
review the comments made regarding the Boost review of FC++ some years
back, in order to prepare you for the kinds of questions and concerns
that primarily imperative-style developers raise.
> [Louis Dionne]
> That is sad, because the functional concepts are exactly what makes Hana so
> powerful. Some problems are well suited for functional programming, and some
> are not. Metaprogramming is __inherently__ functional, and it's about time
> people embrace it.
On a related note (not quoting that other discussion here, but there's
been some other postings on the subject), inventing new terminology
for well-established programming concepts is not merely pointless,
it's actually harmful.
If C++ already has an established name for the programming concept,
that would be a justifiable reason to use that other name instead of
the standard functional programming name. So, it would not at all
disturb me if "maybe" ends up being called something like "optional"
(C++ is not even alone: Scala calls it "Option").
However, http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf serves as
an existence proof that "monad" has been in use within the programming
community since at least 1991. C++ doesn't directly model this
concept elsewhere in its most generic form (notwithstanding
In this case, I am aware of no justification for using any other name.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk