your opinion is super valuable, do you think they make your code shorter, cleaner, more modular, safer ? what do you miss from imperative programming ? or do you consider you would have changed the way you code if you knew about fp idioms long before ?

1: Cleaner and more concise. Perhaps safer, as the less code there is going to performing a task, the fewer places I can make a mistake. More importantly, it directs me to think about my problem from a higher level of abstraction.

2: I do mix both paradigms, so I’m not stuck without imperative features. That being said, there are times where I feel like my attempts to move a concept into FP forces me to make some less than ideal choices to fit it into the paradigm. If those are in inner loops, I forgo functional programming to do precisely what I need. (For example, managing exceptional cases or heterogeneous actions can be awkward.)

3: I would have used them more. I’ve always been a fan of comprehensions and map c/o Python, but my code would have been more efficient and concise had I started earlier. The additions of cppitertools, range-v3, <algorithm> and <functional> make functional programming both easy and efficient in C++ in ways it was not prior to C++1[147]. I think Python made fp accessible by putting it in an imperative language which is concise and readable.

about 2, I remember some old lisp book (Queinnec L.I.S.P) said that if mutable state is entirely contained and invisible, you can forget about purity.

It's cool that cpp is 'flattening' through fp idioms, you can avoid its complexity without leaving the country entirely.

E.g. a pure function can work internally by mutating some local variables. Locally constructed new objects such as conses can be mutated before being returned to the caller. Blackbox testing cannot tell.

My 2 cents: I love functional programming, but sometimes imperative code is the right solution for something, like quicksort.

I'm ok with imperative code as long as the mutable state doesn't 'leak out' into the rest of the code. Quicksort is an example of that -- it's impure in it's implementation but essentially pure to the end user, because you can call it any number of times with the same input and it'll always return the same output

Or if it's some looping construct, recursion might be ok but if it isn't readable or you don't get tail-call optimization, then a for or while loop makes more sense. I do prefer map/filter/reduce/forEach or recursion, I think it's more readable and it avoids the indexing class of errors