Intrinsically Functional
forcomprehension.com
forcomprehension.com
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
That being said I try to firmly plant myself in the second camp at work. As you describe, it's more about the overarching lessons we take away from functional programming. Shared mutable state is scary, referential transparency and purity are easier to reason about, push IO/mutation/scary "complex" things to the edges of your program, etc.
Bottom-up design is a good description. I try to shoot for a functional core with a flexible shell. It lends itself well to the testing story, where the core is covered by unit tests (trivial when coding with pure functions) and integration tests give me confidence in correct behavior at the edges.
I completely agree with this. I think the core advantage of functional programming is the ability to generalize across contexts, which is what makes the purity of the function an important feature. The standard library for Scala is full of while loops and mutable buffers, because if the function call is pure you can then optimize performance through these.
If I make a new context “HasLength” with a single function, “length” and implement it for List, it doesn’t matter how that “length” function is implemented, just that the only context it is bound to is the List one. On the other hand, when implementing “length” for a distributed context, the map-reduce way is probably much easier and more efficient to implement rather than trying to coordinate sistributed variables manually.
> 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.