Ask HN: Explain to me why functional programming is better like I'm stupid

[jagtstronaut]

I have a coworker who really harps on functional programming. To me the block of .map(x).ifelseget().etc() is so much harder to read than defining and mutating variables, if/switch statements, and loops. Also, if you get a stack trace, the line number doesn't really tell you much if you are doing 4 things on a single line.

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?

[kypro]

"Better" is a very strong word to use without any qualifiers – better at what exactly?

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.

[jagtstronaut]

This is really helpful and makes a lot of sense. My coworker who harps on it does have a hardcore math background so your generalization definitely holds true in my experience.

[proc0]

First the readability is an issue of the language not having FP as first class and also lacking the underlying concepts will prevent you from seeing the patterns.

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.

[jollyllama]

For one thing, your functions become easier to unit test, relatively speaking.

[foldr]

I think that's true when it comes to functional programming in the large (designing systems without lots of implicit mutable state), but less so when it comes to the code style of individual functions. For example, one of the following functions is written in a 'functional' style and the other is not, but they are equally easy to unit test:

    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); }

In this case the second implementation is clearly superior, as it avoids implementing array filtering de novo. But the same point applies to other examples where neither style promotes more code reuse than the other.

[jagtstronaut]

The example you gave is obviously superior for the reason you mention, but what about just one where you are mutating the objects in the given list? Isn't the for loop and an if a lot clearer than names.toStream().if(something).then().mutate(thing)?

[foldr]

Sure, I think these things have to be evaluated on a case-by-case basis. Insisting on everything being written in a functional style seems a bit cargo-culty to me.

[AnimalMuppet]

First: You're not stupid. FP advocates sometimes take the stance that you're stupid if you don't use FP, but that's a "them" problem, not a "you" problem. You're not stupid. If they can't explain it to you, either they're lousy at explaining, or FP is as clearly superior as they claim it is.

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.

[jagtstronaut]

That makes sense. I'm thinking for awhile I am just gonna assume my coworker is right and learn how to do it right. Then make another judgement call on whether I like it.

[Leftium]

I think your specific question can be answered by this video. It explains how all branching was removed by refactoring an imperative-style function into functional-style. The original code is on the top, the refactored code is on the bottom: https://youtu.be/GyYME8btMHE?t=1473

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

[1]: https://hw.leftium.com/#/item/26900419

[2]: https://www.manning.com/books/grokking-simplicity

[jagtstronaut]

Thanks for all the sources. It will take me awhile to digest them all.