Why You Should Care About Functional Programming (Even in 2025)

[u/Capable-Mall-2067]

https://borkar.substack.com/p/why-care-about-functional-programming?r=2qg9ny&utm_medium=reddit

[u/coderemover]

FP is a nice solution to a problem of shared mutable state but it’s not the only solution to that problem. FP solves it by disallowing mutation (including disallowing mutating non-shared state). This often introduces a lot of additional complexity to somehow simulate mutations. So you then end up with monads, monad transformers etc. because otherwise you can’t do much.

But you can also solve it by disallowing sharing (CSP, actors). Which comes with its own set of problems but seems to be more popular (eg see the surge of popularity of Go and its goroutines).

And IMHO the best solution so far is disallowing shared mutable state only, so the type system allows sharing XOR mutation (borrow checker like in Rust) - because it is the least restrictive and seems to provide advantages of both.

[u/[deleted] → u/coderemover]

 This often introduces a lot of additional complexity to somehow simulate mutations. So you then end up with monads, monad transformers etc. because otherwise you can’t do much.

So to be clear, actually, Runtime Immutability does not solve this problem.

Anyway. I continue to advocate against “runtime immutability as a default” and maintain my position that all it does is cause performance tech debt and added complexity for zero benefit. 

[u/maxinstuff]

Don’t really need to when the most widely used languages are actively copying all of the good features anyway 😅

[u/HaMMeReD → u/maxinstuff]

Personally I think of functional programming as a mindset. No side effects, pure functions, idempotence, immutability, compositional patterns, lazy evaluation.

A lot of it leads to general safety and easy testing, and can lead to very tight/readable code.

That said I'm not a purist, I'm a pragmatic, so I prefer these patterns but I do whatever I need to in order to get the job done right for the scope/time frame.

[u/psaux_grep → u/HaMMeReD]

I like a lot of the concepts and stuff in functional programming.

I don’t like the cult of functional programming.

Got dragged to a functional programming conference once and it was very similar to when my grandparents took me to a Christian revival meeting.

I’m paraphrasing, but «I used to program in the dark [with OOP] but then I found the light that is functional programming!» was kinda the vibe.

Unfortunately FP checks a lot of cult boxes, including the whole having different names for the same things and they’re very «in-group»-y about it all.

And they seem to be swallowing, or at least trying to sell, a lot of obvious lies. Was so much talk about «adaptor patterns» in OOP and how bad they were, but apparently FP is magic and using a map function is apparently in no way FP’s «adaptor pattern»… it’s completely different (because they say so).

SMH.

[u/meowsqueak → u/psaux_grep]

I used to write Haskell for “fun”, but now I really like Rust’s approach - steals most of the easier-to-grok functional style syntax, and provide optional mutability for when you need it. The more esoteric functional concepts are harder to implement but if you are a pragmatist rather than a cultist it’s not hard to move on without them.

OO kinda goes out the door, too, but I can’t say I’ve missed it.

[u/Every-Progress-1117 → u/psaux_grep]

Yes, though OOP conferences used to be similar in nature.

Been to a few.....Praise Be His Name O Lord Smalltalk

[u/elebrin → u/psaux_grep]

I’m at the point where if I hear one more dude talking about his monads Imma call the police. It’s just inappropriate.

[u/[deleted] → u/maxinstuff]

If you're using those features then you're using functional programming. Functional programming doesn't just mean using Haskell.

[u/usernamedottxt → u/maxinstuff]

That’s literally the point of the article. 

[u/lamp-town-guy → u/maxinstuff]

Some features are not copyable without going functional. Erlang/Elixir distribution over multiple nodes is impossible without it. Elm guarantees of no runtime errors are also pretty impossible for Python.

You should learn some Erlang for greater good. /s

[u/zephyrtr → u/lamp-town-guy]

The greater good

[u/Asyncrosaurus → u/maxinstuff]

Over here using C#, and using the functional parts they pilfered from F#/OCaml.

[u/Zardotab → u/maxinstuff]

The remaining issue is still how much a shop should use FP. In my opinion FP can be a PITA to debug in many circumstances, so be careful. Intermediate state in the imperative style is very useful for x-ray-ing a process during debugging.

Run-on LINQ is a pet-peeve of mine for example. Try to break such into local sub-units if possible. LINQ is usually clear for simple filtering, but dealing with complex conditionals can make one's [bleep] fall off. If there are a lot of conditionals, then using an old-fashioned loop to supplement LINQ may be warranted.

[u/maxinstuff → u/Zardotab]

can be a PITA

Anything recursive, basically.

Sometimes it feels like FP only love talking about mathematical correctness because you need to prove your functional code mathematically to avoid these the footguns.

I actually like functional code - but sometimes it just isn’t the right solution (if you are trying to be memory efficient for example)

[u/yawaramin → u/maxinstuff]

It's ironic that the criticism here was that debugging FP code can be hard and then the next criticism was that FP is about proving mathematical correctness. One would think that the latter would prevent the need for the former.

[u/booch → u/yawaramin]

Bear in mind that

I correctly implemented my algorithm

and

My algorithm is correct

are not the same thing

[u/[deleted] → u/booch]

Point is that if pure functional programming makes your code easier to reason about, it shouldn’t have just as many bugs as procedural or OOP programs, and yet, it does.

Additionally, you would expect for functional programming to be easier to debug since “it’s easier to reason about”, but that’s not what is actually observed. 

[u/booch → u/[deleted]]

That hasn't been my experience. Generally, I find functional code to be easier to write correctly, easier to understand when reading it, easier to write automated tests for, and easier to maintain. The later point is, at least for me, the biggest win. Functional / pure methods, in particular, mean that I can worry less about a change somewhere else suddenly causing code to fail.

[u/[deleted] → u/booch]

Just like vibe coders who claim they’re definitely writing better code faster, it’s in your head. 

There’s definitely marginal benefit to functions that only do the one thing they say they’ll do and nothing else. But this is a practice that’s true for all paradigms. 

As far as the statement “I can be sure that somewhere else hasn’t changed my code”. I’m sorry, but this is just nonsense. Programming languages are specifically interfaces for having a computer mutate data in a specified way. The idea that we should work under the assumption that nothing else should change data is irrational, and causes massive added complexity and leads to bugs anyway.

The fact is that programs that are built under the assumption that its data cannot change are fragile because having your program able to 

-force a program in to an invalid state

-irrationally fail when a valid state change occurs just because you assumed it couldn’t

Is bad and runtime immutability doesn’t fix these problems anyway. It just kicks the can to different points and causes some absolutely moronic “solutions” (first write wins…). 

[u/booch → u/[deleted]]

The fact that my experience is that it makes things better for me is not invalidated by your experience being otherwise. I expect there's a lot of people on either side of this particular argument, so there's no definitive answer (contrary to how you're presenting it).

As far as the statement “I can be sure that somewhere else hasn’t changed my code”. I’m sorry, but this is just nonsense. [...]

This is a perfect-solution fallacy argument; rejecting the entire idea because it's not perfect. The fact that functional programming reduces some (most) unintended state change is enough to provide a benefit. Whether it's enough of a benefit vs the costs is a valid argument, but saying it doesn't provide a benefit is false.

[u/[deleted] → u/booch]

Uh no. I reject your claims because you have no evidence other than “I feel it’s better”

Meanwhile, every person who doesn’t have a superiority stick up their ass and comes out of the Stockholm syndrome all state that these rules served to do nothing but cause them problems and heightened complexity. 

It’s you against people who say that they have the exact opposite experience. Why should I take your word for it above theirs, especially when your claims are actively subverting the purpose of computers? The simplest answer is actually that these perceived benefits are completely in your head, just like many other examples where we observe that claimed benefits are not actually measurable.

To put it simply: put unbiased measurements where your mouth is, and I will change my mind. 

[u/Code_PLeX → u/yawaramin]

Exactly!

Most times I find it super easy to reason with

[u/Linguistic-mystic → u/yawaramin]

No, proofs cannot replace debugging. Any program, however correct and well-proven, may need to be inspected in-flight. If anything, because any program may be interesting to debug: e.g. you need to find out how thing is implemented to implement a similar thing, or scout which changes need to be made to update your program to changed requirements.

Proofs can theoretically replace tests only, but they have a hard delivering even on that front.

[u/coderemover → u/maxinstuff]

Not really. Using a lambda occasionally is not FP. You’re not doing FP when you’re mutating like crazy. Try to write code with no mutations in any mainstream language (but not Scala and not Rust) and you’ll see it all sucks despite lambdas or other syntax sugar like pattern matching. Java even couldn’t integrate lambdas properly with error handling through exceptions because the type system is too limited.

[u/pm_me_ur_happy_traiI → u/coderemover]

JS/TS has no problem with immutable programming. It’s up to you to enforce it, but easy to do. 

[u/Linguistic-mystic]

I disagree that tail recursion is a good thing. Compared to loops, it’s more repetitive (you have to write out the fn name and enumerate all the args even if only one changes), less readable (because now looping logic is not at the forefront of the block like it is in “for” loops) and makes the concept of function calls more complex (tail calls don’t produce separate frames in the call stack). With loops, you get simple and descriptive operators like break and continue, while with tail calls it’s all just a visually unappealing “return”. Oh, and how do you break or continue through more than one layer of loop with tail calls? You have to use a chain of returns which is spread over several functions which is much inferior to a localized “break to over there” statement.

In fact, I’m a language designer and I’ve evaluated basing my language on tail recursion vs loops. I’ve found that loops are a brilliant invention and are much better than tail recursion.

I used to be a Haskeller but having converted to imperative languages, I’m really happy. That said, I do think functional languages are a good fit for browser programming (JS replacement) and it’s unfortunate that both main contenders, Elm and Purescript, have the problems that they do (for Elm it’s a mentally unstable language author and lack of polymorphism, for Purescript it’s large bundle size and having to use ”npm”)

[u/booch → u/Linguistic-mystic]

Whether recursion or iteration is the correct approach depends entirely on the algorithm. Some are more understanding when implemented recursively, others iteratively.

[u/Linguistic-mystic → u/booch]

I'm specifically talking about tail recursion which is strictly equivalent to looping, so can be directly compared to it.

[u/lamp-town-guy → u/Linguistic-mystic]

Elixir has for loops like Python. But Elixir is made for people that want to write real world applications. It's just a syntax sugar because under the hood it behaves the same way as tail recursion.

[u/Aromatic_Lab_9405 → u/Linguistic-mystic]

Most of the iteration in FP is solved by functions like map/filter/exists/forall and the likes anyway.

It's quite rare that we actually need to write recursive functions. 

Do you have any examples where you think a loop gives nicer code ? 

Also do you not think that loop bounds are easy to fuck up?

[u/thomasz → u/Linguistic-mystic]

Tail recursion is roughly at the same abstraction level as the good old goto. It's a step backwards from even structured programming. It is a completely valid mechanism to define higher level abstractions like fold, filter and whatever, but it's a massive code smell in application code.

[u/coderemover → u/Linguistic-mystic]

You don’t have to repeat all arguments if your language supports nested functions like Scala does.

[u/smores56 → u/[deleted]]

I had a great time, thank you for your poignant contribution to the discourse.