| > Everything you said is true for both of our programs, the only difference is whether or not it's hidden behind function calls you can't see and don't have access to. This is a key difference between imperative programming and other paradigms. > You don't really think that functional languages aren't appending things, using temp vars, and using conditional logic behind the scenes, do you? A key concept in a FP approach is Referential Transparency[0]. Here, this concept is relevant in that however FP constructs do what they do "under the hood" is immaterial to collaborators. All that matters is if, for some function/method `f(x)`, it is given the same value for `x`, `f(x)` will produce the same result without observable side effects. > What do you think ".filter(node => !node.isHidden)" does? Depending on the language, apply a predicate to a value in a container, which could be a "traditional" collection (List, Set, etc.), an optional type (cardinality of 0 or 1), a future, an I/O operation, a ... > It's nothing but a for loop and a conditional by another name and wrapped in an awkward, unwieldy package. There is something to be said for the value of using appropriate abstractions. If not, then we would still be writing COBOL. 0 - https://en.wikipedia.org/wiki/Referential_transparency |