
Intrinsically Functional - D_Guidi
https://forcomprehension.com/2017/11/28/intrinsically-functional/
======
yehohanan7
Functional programming is probably the most misunderstood idea by programmers
today, There are 2 types of people

1\. Purist functional programmers: These are the ones who try hard to separate
the side effects in your code from the pure functions and make sure every line
of code they write is pure, they avoid using variables, avoid assignments at
any cost. there's nothing wrong in being a purist, but sometimes, people also
try to write a lot of concise code with a lot of magic underneath which has
it's drawbacks.

2\. Pragmatists: the one's who believe you can do functional programming in
any language, be it C, C++, Java, Haskell, Lisp, Go etc if you focus only on
the benefits of functional programming, you can get it without really being
pure in "every line of code you write" \- for instance, if i have to write a
function that takes a list and gives the length back, i could either use the
fancy map/reduce etc or have a "local" variable declared inside a function and
increment it for each element in the list and return the final result.

Well, you might say mutating a variable is not functional programming - but i
don't care, my function is still pure and it is referentially transparent and
i don't have to think a lot about the various choices that i may have to do
the same thing (map, reduce, etc etc). if you have read the book called
"paradox of choice", it clearly explains how having multiple choices hinders
your happiness and scala always reminds me of that problem, having 100 ways to
do a simple thing slows you down and hinders your productivity. That's one of
the reason why language like Go made the spec so simple and there's always
only one way to do anything syntactically.

I think functional programming should be looked at in a more pragmatic way -
how do i achieve all the advantages of functional programming like doing a
bottom up design, immutability, testability, readablity etc without really
using a specific functional language/syntax which i agree makes it a bit easy
for you syntactically, but hey "concise is not always clear" and your end
goals are more important than the syntaxes

~~~
catnaroek
You complain that:

> Purist functional programmers (...) avoid using variables

Variables are pretty much unavoidable, unless you want to program in a
combinator calculus (think SK(I) or BCKW). Few functional programmers,
“purist” or otherwise, want to program without variables. But perhaps you mean
“assignables”?

> (...) also try to write a lot of concise code with a lot of magic underneath
> which has it's drawbacks.

Let's call things by their proper name. It's not “magic”. It's
incomprehensible code.

That being said, in my experience, functional programs are usually easier to
understand than their imperative counterparts. When an imperative program is
straightforward, it's usually (though not always) because it's a
straightforward translation of a functional program, as in your loop
accumulator example.

\---

You suggest that:

> you can do functional programming in any language, be it C, C++, Java,
> Haskell, Lisp, Go etc if you focus only on the benefits of functional
> programming

The following point has been made several times by several people, but
apparently it hasn't been made enough times, so I have to restate it:
Functional programming means programming with (mathematical, there is no other
kind) functions. Recall that a function is a mapping from values to values, so
you have to define interesting[0] values before you can define interesting
functions. Recall also that two values are equal precisely when they are
indisinguishable[1]; for instance, it doesn't make sense to make a distinction
between “this 2” vs “that 2”, because they are equal _anyway_.

Unfortunately, in languages such as Lisp, Python, Java, etc., it is impossible
to define values by aggregating simpler ones (e.g., pairs, lists, trees, etc.)
in a way that respects the indistinguishability of equal values. Everything
has an _object identity_ that permeates the structure of the entire language.
It can't be abstracted away. It can only be ignored by social convention,
because no sound technical reason justifies it. In other words, you don't have
aggregate values, you have _proxies_ for aggregate values that only exist in
your mind. Making things worse, an object that's a proxy for a value might
become a proxy for a _different_ value (or even not a proxy for a value
anymore!) later on. The object identity of the proxy is most certainly a
value, but it is not the value you actually want to manipulate.

This foundation is too weak to do functional programming.

\---

Footnotes:

[0] By which I mean “related to your problem domain”.

[1] This is called Leibniz equality.

