Arcadia is not representative of all functional programming practices ever. Its alpha state isn't reflective of the alpha state of functional programming either, which has been around for longer than most of us (50s-60s).
FP boils down to one thing: referential transparency, or purity. A pure function f is such that any call to f(x) always yields the same result, to the point where any call to f(x) can be replaced with that result with no change in behavior. With it, we also typically use first class functions, higher order functions, closures, and lots of recursion; those aren't the key purpose of it though, I'd argue.
Even in OOP, we're taught not to have globals. Why? They're not thread-safe; it's not clear who owns them; anyone can change them at any time; in languages like C++, there are also lifetime concerns regarding ordering of initialization between translation units. Referential transparency, I'd argue, is pushing the same exact agenda: stop modifying global state. It's not safe and it's not pure. As John Carmack mentioned in the article above, as game developers, we keep so much state in our mind at any given time; this grows exponentially with the number of threads we're also thinking about.
Even in the most OO languages, we can strive to write code based on pure functions to make those functions easier to reason about, test, and compose. When something goes wrong in your function, and it's pure, you need only worry about your inputs, what you're doing in your function, and your outputs. When it's called doesn't matter (such as before or after some global state has changed).
Rich Hickey, the creator of Clojure, said, in his Spec-ulation rant, that it's tough to explain to Java developers why they should consider Clojure. The reason it's tough is that you first need to explain to them that there's a problem they have which they don't realize: an anxious burning sensation regarding all of the mutation going on in their complex systems. When people use Clojure, and similar functional languages, they often feel liberated that an entire class of problems and bugs can be ruled out. With pure functions, systems can be much easier to understand through a narrow lense. With immutable data structures, tasks can trivially be run in parallel without the worry of thread safety; values don't change. As someone who came into Clojure from a background in C++, I've found that it is, indeed, liberating.
FP boils down to one thing: referential transparency, or purity. A pure function f is such that any call to f(x) always yields the same result, to the point where any call to f(x) can be replaced with that result with no change in behavior. With it, we also typically use first class functions, higher order functions, closures, and lots of recursion; those aren't the key purpose of it though, I'd argue.
Even in OOP, we're taught not to have globals. Why? They're not thread-safe; it's not clear who owns them; anyone can change them at any time; in languages like C++, there are also lifetime concerns regarding ordering of initialization between translation units. Referential transparency, I'd argue, is pushing the same exact agenda: stop modifying global state. It's not safe and it's not pure. As John Carmack mentioned in the article above, as game developers, we keep so much state in our mind at any given time; this grows exponentially with the number of threads we're also thinking about.
Even in the most OO languages, we can strive to write code based on pure functions to make those functions easier to reason about, test, and compose. When something goes wrong in your function, and it's pure, you need only worry about your inputs, what you're doing in your function, and your outputs. When it's called doesn't matter (such as before or after some global state has changed).
Rich Hickey, the creator of Clojure, said, in his Spec-ulation rant, that it's tough to explain to Java developers why they should consider Clojure. The reason it's tough is that you first need to explain to them that there's a problem they have which they don't realize: an anxious burning sensation regarding all of the mutation going on in their complex systems. When people use Clojure, and similar functional languages, they often feel liberated that an entire class of problems and bugs can be ruled out. With pure functions, systems can be much easier to understand through a narrow lense. With immutable data structures, tasks can trivially be run in parallel without the worry of thread safety; values don't change. As someone who came into Clojure from a background in C++, I've found that it is, indeed, liberating.