6 ms·
The benefit of FP has nothing to do with it being easier to read. FP is HARDER to read. The benefit of FP is modularity. Take your example: arr.map().filter
by ninetyninenine 1y ago
The benefit of FP has nothing to do with it being easier to read. FP is HARDER to read. The benefit of FP is modularity. Take your example:
arr.map().filter().filter().map()
Every step on that is a modular operation.
const x = arr.map()
const y = x.filter()
const z = y.filter()
const d = z.map()
now I can easily do this:
const x = (arr) => arr.map()
const y = (arr) => arr.filter()
const z = (arr) => arr.filter()
const d = (arr) => arr.map()
o = d(z(y(x(arr))))
This is the main reason why functional programming is elegant. It makes every corner of your program modular and solves the fundamental program of program organization and modularity.
with a for loop it is easier to read initially but if that filter chain grows the functional approach will begin to be better.
Take an example of a for loop doing the same thing:
const acc = []
for (const x in arr) {
y = map1(x)
if(filter(y) {
continue
}
z = y
if(filter(z)) {
continue
}
d = map2(z)
acc.push(d)
}
Yes more readable but imagine if the logic gets even more complex. Then at scale functional will become more readable AND more modular. Modularity, however, is the main problem here. You cannot split or modularize that for loop.
But I agree with you. Initially and not at scale, functional programming loses readability. Functional programming is harder to read because people think procedurally over functionally. We like numbered instructions or a todo list, not a series of composed function calls and thus from a general view point functional programming is harder to read than procedural programming. But this has never been the benefit of functional.
Functional programming is supposed to solve the modularity problem with how you organize programs to be reusable. Functional programming objectively does this while it is only subjectively considered less readable by the majority of people.
- madeofpalk 1y agoI don't actually have all that much of a problem with chaining fp-style functions, but I note that I see a fair bit of anonymous functions and excessive chaining where none of the benefits you point out are realised. My actual problem is with bad reduce functions that try to shoehorn multiple things into one function and often break the core concept of functional programming by mutating the input arguments. It's that code that would just be better written as a normal loop.
- whilenot-dev 1y ago> It's that code that would just be better written as a normal loop. Have to disagree with your conclusion here. It's that code that should be rewritten, so it doesn't mutate the input arguments at all.
- edoceo 1y agoWhen I'm doing FP, rather than making a long chain, I assign at each step, then call the next one. As you've shown above. Sometimes I even comment on why the code is doing stuff. Making it read as a list of steps, helps me understand what it's doing a little easier than that long chain.
- monkpit 1y agoSame. Chaining all of those together does nothing useful, is arguably less readable, and the JIT will optimize out the intermediate assignments. So there’s not really any reason to do that big chain (unless you’re talking about HoC/composable functions, which this example is not).
- edoceo 1y agoFuture me has to re-solve this issue. And Past Me is an idiot. I gotta write code both those fools can understand.