While at it: pure functional programming is very easy to grasp. You should just think about programming as of not tinkering with the state, not altering things, but as of producing outputs from inputs.
Say, analog electronics mostly works in the pure functional domain. An amplifier does not try to change the input signal. Instead, it produces a more powerful output signal, following the shape of the input signal. A tone generator in a musical instrument does not try to make a key on the keyboard vibrate. Instead it produces a sound signal according to the key pressed (which note and what velocity).
The simplest way to try practical pure functional programming is to connect a few Unix processes via pipes:
cat somefile.py | egrep '^def \w+' | wc -l
The above is a pure function compositon, as a map-reduce pipeline, in point-free style. (Yay, buzzwords.) It counts top-level functions in a Python file.
But how to achieve something like updating with that? By looping the output back to the input, and switching o the "next version" once it's computed. Conway's game of Life looks like an ultimate "update in place" thing. But it's purely functional, too: the new state of the map is completely computed based on the previous state if the map. Then the new map is seen as "the current map". Similarly, frames in a drawn animation do not change, but they are shown at the same place one after another, giving the impression of motion and change of "the same" picture.
In general, our Universe may be seen as a purely functional computation: its next state is a function of its past states, and the past is immutable.
I like your conviction Re "functional programming is very easy to grasp".
Many won't but I agree in the purest (sorry) sense.
There is no scattered changing state. I think we all learned input-function-output as a construct in maths class?
Spreadsheets (sans-VBA) is arguably the most prolific programming language and simplest, being used by people who do not recognise they are programming. Felienne Hermans gave a good talk on this subject in GOTO 2016.
Spreadsheets have numerous shortfalls though, and "real" functional programming languages make it difficult to not feel intimidated: in my experience, but this is getting much better.
[1] is a game of life in calculang, functional language I'm developing, where for all it's verbosity at least I hope the rules and development over generation (g) can be reasoned with (sans-state!).
Not very practical but can show calculang computation/workings as it progresses and as parameters change - things that are easy for FP and otherwise intractable, and which further help with reasoning.
But, a big challenge is to be approachable (not intimidating), and I'm trying to make that better. I think it helps enormously to be focused on numbers as calculang is, and not general programming.
Type theory can be complicated! OTOH e.g. untyped lambda calculus is purely functional, and lives without types. It can be easily explained using the notion of "macro", or text substitution, familiar to any C programmer.
Certainly knowing some category theory helps. Finding out mathematical underpinnings of e.g. monads is some effort, and a foray into a non-daily math territory. I'd compare it with learning about matrices and quaternions when doing 3D geometry stuff. In either case, you have to make an effort and acquire a bit of special knowledge. But once you've learned it, it becomes and remains "intuitive", you don't have to think deeply or write complex formulae to use it. You just write [int(x) for x in line.split(",") if x] and don't mentally split this chain of monadic operations into an isomorphism and a catamorphism.
Say, analog electronics mostly works in the pure functional domain. An amplifier does not try to change the input signal. Instead, it produces a more powerful output signal, following the shape of the input signal. A tone generator in a musical instrument does not try to make a key on the keyboard vibrate. Instead it produces a sound signal according to the key pressed (which note and what velocity).
The simplest way to try practical pure functional programming is to connect a few Unix processes via pipes:
The above is a pure function compositon, as a map-reduce pipeline, in point-free style. (Yay, buzzwords.) It counts top-level functions in a Python file.But how to achieve something like updating with that? By looping the output back to the input, and switching o the "next version" once it's computed. Conway's game of Life looks like an ultimate "update in place" thing. But it's purely functional, too: the new state of the map is completely computed based on the previous state if the map. Then the new map is seen as "the current map". Similarly, frames in a drawn animation do not change, but they are shown at the same place one after another, giving the impression of motion and change of "the same" picture.
In general, our Universe may be seen as a purely functional computation: its next state is a function of its past states, and the past is immutable.