OOP feels right because it's an imitation of reality. In the reality we live in... a verb cannot exist without a noun. Think about it: how can there be "movemen

OOP feels right because it's an imitation of reality. In the reality we live in... a verb cannot exist without a noun. Think about it: how can there be "movement" without the "thing that moves." OOP makes sense from this perspective. If however we think of abstractions outside of reality as we know it. Things like imaginary numbers, negative numbers and non-euclidean geometry appear. Outside of reality an Object can be further divided into two things that don't really exist in the real world: pure state and pure action (from certain perspectives, ... technically the function still occupies state and can be thought of as an object). In CS it feels as if the discovery came backwards the real world analogue (OOP) came after the abstraction that doesn't exist in reality (mathematical functions and numbers). Anyway, I'm taking this somewhere that has a relation to the parent article so hear me out. Function and State as separate entities is a smaller organizational subdivision then Objects which are Functions With State. Separating Function and State solves a big problem that is central to Designing Systems. The problem is associated with modularity problems grouping two primitives together into a single entity. What happens is more often then not we don't fully understand the true nature of the thing we are building. So in the initial designs of an OOP system we unionize a certain function with a certain state and it seems like the correct thing to do at the time, but over time as requirements change or we gain greater knowledge of the problem we're solving we realize that the function/method is better used in a separate context. But it's too late... at this stage the method that we want to pull out is dependent on the object and that object is a dependency for multitudes of other objects. Thus we either end up rewriting code or creating a hack, thereby inventing technical debt. If that method was never unionized with state, if we used smaller subdivisions in our code where state and functions are separate entities then this would be much less of a problem. The function would not be tied to state and that function can be executed in the context of anything. This metaobject post talks about the isomorphism between OOP and HTTP/REST/Servers and talks about the success of that model and how we should bring it down to the process level. I'm thinking what's the point? JAVA and smalltalk and a bunch of other languages fill that role you're just changing the semantics, but the structure is still the same. He also fails to talk about the problems we have with concept of HTTP, REST and servers taken to the max. We have a term for this it's called "microservices." The problems we have with microservices are exactly the same problems that I just described. I described a problem with OOP and microservices are an OOP model. The difference here is rather then unionizing action and state with Code it unionizes state and action with real cold hard metal. The actual machine that holds state and "does stuff" is the object. So all the problems of realizing how to divide or unionize services and state in microservices are exact same problems that existed when trying to figure out what methods belong with what object in OOP, only when the actual machine is your abstraction barrier, things are much harder to change. The problem is well described even by OOP advocate martin fowler: https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html. His solution for this problem is less then ideal... basically... build it wrong first then tear it apart and mutate it into something else... I don't even know if martin fowler realizes that he's also talking about OOP as the design structure of microservices and OOP are isomorphic. Anyway, I digressed... and I'm still disagreeing with the OPs conclusion. It makes no sense to me why we should bring this server/HTTP model down into code given the fact that it has all these problems and that it's basically already done with JAVA. The way forward is actually movement in the opposite direction. Don't abstract code into a server model rather abstract the server model into code. Basically code that doesn't compile into assembly language but compiles into apps that are automatically networked across a constellation of servers. It's a very hard thing to implement but being allowed to separate function and state at the server level like we do in code is, in my opinion, the way forward. It also sort of exists in a minor way with the whole infrastructure as code thing and aws lambdas.