You complain that: > Purist functional programmers (...) avoid using variables Variables are pretty much unavoidable, unless you want to program in a combinat

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.