Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2014-11-19 00:00:03

On Tue, Nov 18, 2014 at 7:37 PM, Gavin Lambert <gavinl_at_[hidden]>
wrote:

> On 19/11/2014 14:32, Vladimir Batov wrote:
>
>> While I agree with your point I suspect there might be something more
>> fundamental why functional programming in C++ and functional programming
>> in general has been on the fringes of and hardly present in mainstream
>> commercial s/w development (not academia).
>>
>
> The main problem I think is just that functional programming is more
> restrictive.  At least in pure FP, your functions can only see their own
> inputs and provide values by their direct outputs.  Most "real" code is
> messier than this -- you end up with containers of things and operations on
> those things that may have side effects and working state, and often end up
> hanging things off singletons.
>

I feel like it's a little bit different from that. I say this because
"functional" algorithms in C++ aren't usually functional in the sense of
purity anyway -- they still generally operate via side-effects. Using
things like the standard algorithms do not preclude any of those "real"
scenarios. What we do have plenty of in C++ are high-order functions. Pure
functional programming aside, people just seem to not like high order
functions in general, regardless of whether or not there are side-effects.
My personal interpretation of this is that people don't like them because
they add another level of abstraction, or more specifically, a level of
abstraction that is /visible/ in their code. Even though we are software
engineers and should embrace abstraction, many programmers don't like it
because abstraction introduces one more level between what they write and
what they get. This is often interpreted as additional complexity as
opposed to a tool that helps isolate it. In my opinion, that view of things
is a common misconception that sits in the mind of a lot of programmers out
there.

My overall thought is that the general lack of acceptance of high-order
functions and abstraction is mostly just a knee-jerk reaction to that
perceived complexity, and this is something that somehow needs to change in
the programming community. The following is obviously anecdotal, but in my
personal experience, people will hate on something as simple as a
high-order for_each function to no end for being too abstract or for
obfuscating things, but as soon as it becomes a built-in language feature,
such as range-based-for, even if it does essentially the same thing, people
immediately embrace it. Maybe it's because it's syntactically "cleaner,"
but I suspect that's not really it.

So what is it then? Again, I don't think it has anything to do with purity
since a library-based for_each isn't even generally pure. Again, you can
still operate via side-effects. Purity isn't the problem. As far as I can
tell it's that if the for-each algorithm is clearly visible as a /function/
and not simply some built-in part of the language, people perceive the
notion as somehow more complicated, even though both facilities may do
exactly the same thing and with the same amount of abstraction. The
avoidance of the library-form stems from a programmer's [correct] fear of
complexity that they now erroneously associate with a library-level
algorithm even though they wouldn't associate it with a language-level
version of that very same, simple algorithm. People ultimately want a
solution to be as simple as it can be, for good reason, but I think it's
easy to confuse complexity with abstraction and so people immediately look
at an abstract, high-order function as intrinsically complex. The
difference in perception of the complexity and abstraction between the
language-level construct and the high-order library form of the same
construct, in my opinion, purely psychological. People just need to
recognize this and get past it, though in practice that seems like a
difficult step to take and many programmers sadly don't ever take it.

I see this as a huge problem because as software engineers, while we should
always avoid complexity, abstraction is one tool that helps /remove/
complexity in high-level code by isolating invariants and by representing
common patterns as individual high order functions. When people turn away
from high-order functions, I generally see it as turning away from
abstraction, and that is no way to build large-scale software.

Anyway, I have a bad habit of typing a lot of words, but I really feel
strongly that this is all very important in "real" development. High-order
functions aren't merely academic, they are important for isolating
complexity in real-world problems.

-- 
-Matt Calabrese