> but I fail to see why it is a functional programming concept.

"Functional programming" means that you primarily use functions (not C functions, but mathematical pure functions) to solve your problems.

This means you won't do IO in your computation because you can't do that. It also means you won't modify data, because you can't do that either. Also you might have access to first class functions, and can pass them around as values.

If you do procedural programming in C++ but your functions don't do IO or modify (not local) values, then congrats, you're doing functional programming.

Thanks. I now see why it makes sense to me. I work in DE so in most of our cases we do streaming (IO) without any transformation (computation), and then we do transformation in a total different pipeline. We never transform anything we consumed, always keep the original copy, even if it's bad.

> I fail to see why it is a functional programming concept.

Excellent! You will encounter 0 friction in using an FP then.

To the extent that programmers find friction using Haskell, it's usually because their computations unintentionally update the state of the world, and the compiler tells them off for it.

Think about this: if a function calls another function that produces a side effect, both functions become impure (non-functional). Simply separating them isn't enough. That's the difference when thinking of it in functional terms

Normally what functional programmers will do is pull their state and side effects up as high as they can so that most of their program is functional

Having functions which do nothing but computation is core functional programming. I/O should be delegated to the edges of your program, where it is necessary.