Monads are actually the "missing" control structure that encapsulates progression from stable state to stable state, and moreover allows you to combine etc. tho

Monads are actually the "missing" control structure that encapsulates progression from stable state to stable state, and moreover allows you to combine etc. those progressions in a functional fashion. If you look at the type signature of (>>=) (monadic bind), it says (>>=) :: Monad m => m a -> (a -> m b) -> m b which, if you instantiate m with a monad that represents state, you you can read as "given a progression 'm a' from state to state with return value of type 'a', and a function that uses this value to construct a progression from state to state with a return value of type 'b', then I can compose both progressions, and get a progression from state to state with return value 'b'". (These "return values" are used to transfer information from one progression to the next progression, and are the only thing that take a bit getting used to). So pure FP languages do allow you to specify step-by-step progression. Seen from this point of view, Alan Kay's statement 'there is no reason to invent “monads” in FP' is just nonsense, because he has no experience with pure FPLs, and seems to be only familiar with Lisp, which is a very impure ad-hoc FP. So while I agree with his conclusion "both OOP and functional computation can be completely compatible (and should be!)." (see e.g. Ocaml for a fusion of both concepts), and I am not particularly impressed by his reasoning.