The great achievement of OOP is that it inspires such passion.

In essence OOP is just, "hey, if you have a struct and a bunch of operations that operate on that struct, let's put the name of the struct and a dot in front of the names of those operations and you don't need to pass the struct itself as an argument"

It beats me how either the high priests or its detractors get so worked up about it, even with the add-ons like inheritance, poly-morphism or patterns. (Which of course also exist in a more mathematically clean way in functional languages.)

These patterns have seen real use (not saying optimal) in the wild.

Of course we know today composition is better than inheritance, plain data structs are enough for most cases, and "parse, don't validate". but did people know it in 1990s?

You’re missing the depth of the difference. It’s not just syntax sugar for calling object.method() instead of func(object). The key distinction is what happens when the method mutates the object.

When state is mutable, every method that touches it becomes coupled to every other method that touches it. The object stops being a collection of independent behaviors and turns into a shared ecosystem of side effects. Once you mutate state, all the code that relies on that state is now bound together. The object becomes a single, indivisible unit. You cannot take one method and move it elsewhere without dragging the rest of its world along with it.

Functional programming avoids that trap. Functions are isolated. They take input and return output. They don’t secretly reach into a shared pile of state that everything else depends on. That separation is not aesthetic, it is structural. It’s what makes functions genuinely modular. You can pull them out, test them, recombine them, and nothing else breaks.

   # OOP version
   class Counter:
       def __init__(self):
           self.value = 0

       def increment(self, n):
           self.value += n

       def double(self):
           self.value *= 2

   c = Counter()
   c.increment(5)
   c.double()
   print(c.value)

Here, every method is bound to self.value. Change how one works and you risk breaking the others. They share a hidden dependency on mutable state.

Now compare that to the functional version:

   def increment(value, n):
       return value + n

   def double(value):
       return value * 2

   increment_and_double = lambda x: double(increment(x, 5))
   print(increment_and_double(0))

In this version, increment and double are completely independent. You can test them, reuse them, and combine them however you like. They have no shared state, no implicit dependency, no hidden linkage.

People often think OOP and FP are complementary styles. They are not. They are oppositional at the core. OOP is built on mutation and shared context. FP is built on immutability and isolation. One binds everything together, the other separates everything cleanly.

Mutation is what breaks modularity. Every time you let a method change shared state, you weave a thread that ties the system tighter. Over time those threads form knots, and those knots are what make change painful. OOP is built around getters and setters, around mutating values inside hidden containers. That’s not structure. It’s coupling disguised as design.

Functional programming escapes that. It separates state from behavior and turns change into a controlled flow. It makes logic transparent and free. It’s not just another way to code. It’s the only way to make code truly modular.

You can write these same methods in an OOP language like Java. You dont have to use classes for everything.

But alot of times, yes it makes sense to group a set of related methods and states.

You say this is not a natural way of thinking but I strongly disagree, it lines up perfectly with how I think. You are you, the car dealership is a dealership. You buy a car from the car dealership, the dealership gets money, you lose money, the dealership loses a car and you gain a car. I want these states reflected in the objects they belong and not passed around globally and tracked

Or if I am writing an API library, yes I very much want to 1. group all my calls together in a class, and 2. keep track of some state, like auth tokens, expirations, configuration for the http client, etc. So you can just do api.login, api.likeX, etc

Moreover, most methods youd write in a large project are so limited in scope to the type and purpose, this idea of some great modularity is nonsense. Its not as if you can have a single delete function that works on deleting users, images from your s3, etc. Youd end up writing bunch of functions like deleteUser(user), createUser(user), deleteImage(image), and wow wouldn't it be great if we could just group these functions together and just do user.delete, user.create? we could even define an interface like Crudable and implement it differently based on what we're deleting. wows

Ok simple question. Have a method called increment(n) on an object called tracker. It’s used to increment tracking id values.

I want to reuse the logic of increment(n) inside another object called childHeight to increment height values.

Can I import the method and reuse it inside another object? No. I can’t.

But if increment was a pure function thats like this increment(c, n) then I can move it anywhere.

That is what I mean by modularity. For oop lack of modularity is fundamental to its design. The grouping of methods around mutating state breaks modularity.

You’re talking about a semantic issue. Grouping methods by meaning. I’m talking about a logistical issue where the grouping by semantics cannot be broken even though the logic is the same. Incrementing height and incrementing ids are identical in logic even though the semantics are divergent.

That is the problem with OOP.

There are multiple ways to handle that.

Class Number {

   static Int inc(Int n) {
      return n+1
   }

}

import static Number.inc

Class Tracker {

    Integer height = 0;

    incHeight() {
        this.height = inc(this.height)
    }

}

class Tracker extends Numbers {

    Integer height = 0;

    incHeight() {
        this.height = this.inc(this.height)
    }

}

Or

interface Number {

   default Int inc(Int n) {
      return n+1
   }

}

class Tracker implements Numbers {

    Integer height = 0;

    incHeight() {
        this.height = this.inc(this.height)
    }

}

Or my pick

class Number { //or extend the Integer class and add your methods

    int num = 0;

    inc() { 
     this.num +=1
  
     }

}

class Tracker { Number trackingId; }

class Building { Number height; }

t = Tracker()

t.height.inc()

b = Building()

b.height.inc()

All OOP does is really give you a way to group state and methods, how you use it is up to you. There is a reason almost all big software is written this way and not in Lisp.

Do you see the problem? What you wrote is the problem with oop. Gotta tear your whole program apart and rewrite it. You had to create new things and rewrite your methods.

With functional you don’t rewrite. You recompose what you already have.

It means oop is not modular. You didn’t create modules that can be reused. Nothing could be reused so you had to reconfigure everything.

Take a look at the Interable interfae in Java if you want some good examples of reusable functions.

It enables map, filter, stream, reduce, groupby, etc on lists, sets, etc

or collections class which gives sort, min, max, replaceAll, etc

There's a video from Gary Bernhardt called Functional Core, Imperative Shell which made sense to me. These paradigms can work well together. OOP can be great too, the Ruby language is deeply OO and the core library is rich and OO. You can also only use hashes and arrays and type them with Typescript, using functions, types and namespaces and duck-typing, instead of classes and methods.

ps: closures are worth thinking about, we use them without even thinking about it

OOP and FP are in theory orthogonal principles. Maybe I'm too much of a pragmatic and purists might scoff at me, but I use and appreciate both.

No they are not. Fp and oop are opposing principles. They are in direct conflict with one another. See my other reply to see why.

Did you use ChatGPT to write this?

No

I want to believe you, but some of this verbage sounds very strange, as if you're don draper trying to sell me functional programming. There are a lot of stinks within those paragraphs. I have no proof that you did, but something about it feels off.

There’s no need to respond then. No point in this accusation either. You make an accusation, I deny it, life goes on and nothing is different except a little wasted effort. Save the effort.