Pure Functions in FP

It's not explicitly expressed (the functions could still execute sideeffects and e.g. mutate things), but yes, that is pretty much the style that pure functional programming enforces!.

That's a little vague, I think. Pure functional programming has no side effects. Isn't that as succinct & thorough as it gets?

Author's obviously talking about pure functions, not procedures or subroutines.

Being explicit about effects does not make the function pure, does it? Why claim FP credentials if all or most of your functions are going to be impure?

That's exactly what functional means. You're conflating functional and pure. They happen to be (essentially) the same thing in Haskell, but that's not always the case. A functional language can get you really close to pure (but good luck doing anything interesting without monads or mutable state), but even the purest languages cheat. Putting your side-effect code in a main function might help you catch bugs and limit potential side-effects, but it's still not completely pure (and for good re

Pure functions (with no side effects or state mutation) is pretty core to functional programming.

Purely functional, or simply not having side-effects and using immutability? No need to go full-Haskell to benefit.

Isn't he just rediscovering the idea of pure functions?https://en.m.wikipedia.org/wiki/Pure_function

Without side effects you couldn't do anything. Pure functional languages make side effects explicit, but it isn't about them being missing.

The language does not offer the features that you were referring to, and that the author of the article mentions. You can write pure functions, but the purity is not checked by the compiler, that is what has been meant here.