Functional is for academics. Objects are for Pros

I went through a serious functional programming phase. I came out the other side writing object-oriented code again, and I'm at peace with it.

My Purity Phase

It felt clever. Chain a dozen tiny pure functions together and watch the data flow through. Point-free style, no mention of the argument, pure data transformation. For about a week I felt like I'd ascended.

Then somebody else had to read it

Point-free code is write-only. Come back to a higher order functions stack three weeks later and you have to mentally execute the whole pipeline to work out what it does. The stack traces are useless — every error points into the guts of the combinator library, never your code. Onboarding anyone onto it was a non-starter. Clever is not the same as clear, and the team pays for clever every day after you wrote it.

I rebuilt objects by accident

Here's the thing that broke the spell: I noticed I was threading the same data structure through every function in a module, and bundling related functions together so they'd operate on it. That's an object. I'd reinvented methods on a class, just with worse ergonomics and the state smeared across a dozen closures. The functional purity was a costume over the same shape underneath.

Objects model the domain

A noun that has behaviour. A Order that knows how to total itself. The thing FP advocates wrinkle their nose at is, most of the time, just organising code around the domain it represents — which turns out to be how humans actually think about the problem.

Take the good bits, leave the religion

I still use immutability where it earns its place. I still reach for map, filter and reduce over a hand-rolled loop. Pure functions are great when a function is genuinely a pure transformation. But the backbone of a real codebase that a team has to live in is objects. Functional programming has lovely ideas. As a whole-system religion, on a team, with a deadline — objects win.