1. Purist functional programmers: These are the ones who try hard to separate the side effects in your code from the pure functions and make sure every line of code they write is pure, they avoid using variables, avoid assignments at any cost. there's nothing wrong in being a purist, but sometimes, people also try to write a lot of concise code with a lot of magic underneath which has it's drawbacks.
2. Pragmatists: the one's who believe you can do functional programming in any language, be it C, C++, Java, Haskell, Lisp, Go etc if you focus only on the benefits of functional programming, you can get it without really being pure in "every line of code you write" - for instance, if i have to write a function that takes a list and gives the length back, i could either use the fancy map/reduce etc or have a "local" variable declared inside a function and increment it for each element in the list and return the final result.
Well, you might say mutating a variable is not functional programming - but i don't care, my function is still pure and it is referentially transparent and i don't have to think a lot about the various choices that i may have to do the same thing (map, reduce, etc etc). if you have read the book called "paradox of choice", it clearly explains how having multiple choices hinders your happiness and scala always reminds me of that problem, having 100 ways to do a simple thing slows you down and hinders your productivity. That's one of the reason why language like Go made the spec so simple and there's always only one way to do anything syntactically.
I think functional programming should be looked at in a more pragmatic way - how do i achieve all the advantages of functional programming like doing a bottom up design, immutability, testability, readablity etc without really using a specific functional language/syntax which i agree makes it a bit easy for you syntactically, but hey "concise is not always clear" and your end goals are more important than the syntaxes