I have always wondered this since I have been confronted with it, but in an interview recently I was given a light docking for not using functional programming. Why is it better?
In functional programming everything is predictable:
input -> [some function] -> output
Where in OO things are:
input -> [some function + some hard to reason about state] -> output
In OO functions tend to be "impure" because you typically have state which can always do something you don't expect. This becomes even more problematic when you add parallelism to the mix because now state can mutate in ways that that is very hard to reason about.
With functional programming if something unexpected happens then you know that it's the function's logic rather than having to try to understand how some unexpected state is causing a function to do something you didn't expect. For this reason functional logic much easier to test and verify because the surface area for unexpected results is dramatically reduced.
That said, functional programming is much less intuitive I think. We tend to naturally reason about the world as a collection of objects with state and actions, and when an action is performed state mutates.
Functional programming requires you get rid of the idea of objects which have mutable state and instead think about the world as a collection of processes which given stateT1, spit out stateT2.
I've noticed people from a math background find the purity of functional programming very appealing. Personally I tend to share that bias, but I still recognise that functional programming isn't the best paradigm for most applications.
If you're building a simple API or app for example, then I think the most important thing is writing code that's easy to comprehend. If the domain is simple then the benefits of functional programming are relatively slim. It's really only when you're dealing with complex state and parallelism that functional programming really starts to have major benefits in my eyes. I think your observation that functional programming being harder to read is 100% correct, and this is its main trade off in my view.
The best metaphor I can think of... imagine a Rube Goldberg machine that works with water. The water starts on one side and moves through a bunch of contraptions, switches, and does a bunch of things at the same time, quite messy but it works. This is your typical programming experience. FP is like doing this but with pipes instead. You build all your pipes, then the water is sealed tight and the flow is controlled nicely.
That said, FP has strengths and weaknesses, but overall I would say it is definitely a superior paradigm, aside from the considerable learning curve and performance drawbacks.
function getLongNames(names) {
let longNames = [];
for (const n of names) {
if (n.length > 20)
longNames.push(n)
}
return longNames;
}
function getLongNames(names) { return names.filter(n => n.length > 20); }
I think that FP matches how some people think - and doesn't match how some other people think. When people that it fits learn FP, they have this "aha!" experience. They think if you don't get it, you just haven't learned enough to have the same experience. But in doing so, they are assuming that everyone else's mind works the same as theirs does. I think that's a false assumption. And I think it plays into the "we're obviously right, and anyone who can't see it is unenlightened/stupid" smugness that FP advocates sometimes have.
Here's what I have gleaned from various HN discussions in the past:
If you can think of your program (or a part of it) as a pipe, then FP is likely a good fit. If data comes in, gets modified, and goes out, that's a decent match for FP. And if it is, that has some real benefits. Pure functions (ones that are only a function of their inputs) are easier to write, debug, and use than non-pure functions are.
But, as someone said here, "real programs have state". Your program often is not just a pipe; there's some state somewhere. In some cases, the state predominates. (This is often the case for OSes and embedded systems.) What are you going to do with the state? In procedural programming, you put it in a global somewhere. In OO, you put it in a class somewhere. In FP, you still have to put it somewhere. FP sometimes does some jumping through hoops to make it not look like you're dealing with persistent state - but you still are, even if you wrap it up in something.
If you add multithreading, this gets far worse. FP is absolutely right that shared mutable state is evil, but if it's necessary for the program you're trying to write, I'm not sure that FP has a good answer. In OO, you put it in a class and protect access with semaphores. In FP, I'm not sure how you handle getting the newly updated state to the multiple threads that need to see it.
So FP isn't "better". It's a better fit for some problems (and some programmers), and a worse fit for others.
All that said, in an interview, if they're a place that uses FP, and you're not an FP person, then it may be valid for them to dock you lightly for that.
Besides being shorter and easier to reason about, functional-style can be easier to test because there are fewer logical paths to test (statement/condition/branch/etc coverage).
Of course, it's still totally possible to write bad code in a functional-style!
Some little advantages of creating arrays in functional-style TS (vs declaring an empty array [] and filling it imperatively with `push()`):
- TS can autumatically infer the type of the array; no need to explicity type.
- Can declare the array as const/readonly if it doesn't change
---
The OP question was at the code-level, the small scale. However FP can be used at both the large and small scales. (And via traditional "non-functional", "inperative" languages.) "Functional programming" is a paradigm and way of thinking; not just a programming language.
In fact, many of the good parts of FP have been borrowed by non-FP languages to the point people don't consider them "functional programming" anymore[0]. (Like JS `.map()` and `.reduce()`. Even Excel macros now support first-class lambda functions[1].)
Another major pillar of FP is immutability (functional purity). Actually Grokking Simplicity[2] states it most elegantly: it's not about avoiding mutation because "mutation is bad." In fact, mutation is usually the desired result, but care must be taken because mutation depends on when and how many times it's called.
So good functional programming isn't about avoiding impure functions; instead it's about giving extra care to them. After all, the purpose of all software is to cause some type of mutation/effect (flip pixels on a screen, save bits to storage, send email, etc). Impure functions like these depend on the time they are called, so they are the most difficult to get right.
In general, I think these are the main promises of functional programming:
1. Program design/code that is easier to reason about/debug.
2. Programs that are shorter, yet more descriptive.
3. Programs that are more performant.
4. Programs that can be easily parallelized.
I wrote a whole article expanding on this: https://blog.leftium.com/2023/04/more-performant-testable-co...
---
Here's a short list of my top introductions/explanations of FP:
- Grokking Simplicity: https://www.manning.com/books/grokking-simplicity
- Functional Core, Imperative Shell: https://hw.leftium.com/#/item/18043058
- ScottWlaschin: https://hw.leftium.com/#/item/21879368
- Greg Young on Event Sourcing: https://youtu.be/8JKjvY4etTY
- https://project-awesome.org/stoeffel/awesome-fp-js
[0]: https://hw.leftium.com/#/item/21280429