We are replacing OOP with something worse

> It's unclear to me what the author thinks OOP is, and what he thinks we are replacing it with.

The author is complaining about bloat.

The thing is, in this case, the bloat has highly tangible costs: Spreading an application across multiple computers unnecessarily adds both operation costs and development costs.

> It's unclear to me what the author thinks OOP is

I rather liked the old post "Object Oriented Programming is an Expensive Disaster that Must End" written over 10 years ago.

https://medium.com/@jacobfriedman/object-oriented-programmin...

Many complained the post was too long, and then debated all kinds of things brought up in the article (such is the way of the internet).

But the one thing I really liked is how it laid out that everyone has a different definition of what OOP is and so it is difficult to talk about.

The essence of OOP to me is message-passing, which implies (hidden) local mutable state (there must be local state if a message can change future behavior). (Really, actor-based languages are purer expressions of this ideal than conventional OOP languages, including Smalltalk.) However, encapsulation is not at all unique to OOP; e.g. abstract data types are fully encapsulated but do not require all function calls to look like message passing.

> overloaded

I see what you did there

"I don't really think about "OOP" very often. I also don't think about microservices."

Why even comment in an article about those topics then?

>> _Anecdotally, I've replaced OOP with plain data structures and functions._

I think this is why FP is becoming more popular these days but I'm not sure some people get why. The problem with OOP is you take a data set and spread it all over a 'system' of stateful (mutable) objects and wonder why it doesn't/can't all fit back into place when you need it to. OOP looks great on paper and I love the premise but...

With FP you take a data set and pass it through a pipeline of functions that give back the same dataset or you take a part of that data out, work on it and put it straight back. All your state lives in one place, mutable changes are performed at the edges, not internally somewhere in a mass of 'instances'.

I think micro services et al try to alleviate this by spreading the OO system's instances into silos but that just moves the problems elsewhere.

>> Anecdotally, I've replaced OOP with plain data structures and functions.

Agreed. I think objects/classes (C++) should be for software subsystems and not so much for user data. Programs manipulate data, not the other way around - polymorphism and overloading can be bad for performance.

It is somewhat interesting to realize micro services are conceptually solving the same problem that OOP despite working in such different areas.

Though OOP is just one step - structured programming works on the same problem.

> Sounds like C.

Data hiding is just one of the concepts of OOP. Polymorphism is another one.

How that's implemented is another question. You can do OOP in plain C, several libraries kinda did that, like GTK. Other languages tried to support these concepts with less boilerplate, giving rise to classes and such. But OOP is not about language features, it's fundamentally a way of designing software.

You're not wrong.

It's fashionable to dunk on OOP (because most examples - like employee being a subtype of person - are stupid) and ORM (because yes you need to hand write queries of any real complexity).

But there's a reason large projects rely on them. When used properly they are powerful, useful, time-saving and complexity-reducing abstractions.

Code hipsters always push new techniques and disparage the old ones, then eventually realise that there were good reasons for the status quo.

Case in point the arrival of NoSQL and wild uptake of MongoDB and the like last decade. Today people have re-learned the value of the R part of RDBMS.

Almost all languages have some sort of object representation, right? Classes with their own behavior, DTOs, records, structs, etc.,. What language are you working in? If you're coupled to a specific database provider anyway there's usually a system table you can query to get your list of tables, column names, etc., so you could almost just use one data source and only need to deal with its structure to provide all your endpoints (not really recommending this approach).

> As a total beginner to the functional programming world, something I've never seen mentioned at length is that OOP actually makes a ton of sense for CRUD and database operations.

I've heard this a lot in my career. I can agree that most object-oriented languages have had to do a lot of work to make CRUD and database operations easy to do, because they are common needs. ORM libraries are common because mapping between objects and relations (SQL) is a common need.

It doesn't necessarily mean that object-oriented programming is the best for CRUD because ORMs exist. You can find just as many complaints that ORMs obfuscate how database operations really work/think. The reason you need to map from the relational world to the object world is because they are different worlds. SQL is not an object-oriented language and doesn't follow object-oriented ideals. (At least, not out of the box as a standardized language; many practical database systems have object-oriented underpinnings and/or present object-oriented scripting language extensions to SQL.)

> it's super hard without an ORM or at least some kind of object layer

This seems like you might have got caught in something of a tautological loop situation that because you were working in a language with "object layers" it seemed easiest to work in one, and thus work with an ORM.

It might also be confusing the concepts of "data structure" and "object". Which most object-oriented languages generally do, and have good reason to. A good OOP language wants every data structure to be an object.

The functional programming world still makes heavy use of data structures. It's hard to program in any language without data structures. FP CRUD can be as simple as four functions `create`, 'read`, `update`, and `delete`, but still needs some mapping to data structures/data types. That may still sound object-oriented if you are used to thinking of all data structures as "objects". But beyond that, it should still sound relatively "easy" from an FP perspective: CRUD is just functions that take data structures and make database operations or make database operations and return data structures.

A difference between FP and OOP's view of data structures is where "behaviors" live. An object is a data structure with "attached" behaviors which often modify a data structure in place. FP generally relies on functions that take one data structure and return the next data structure. If you aren't using much in the way of class inheritance, if your "objects" out of your ORM have few methods of their own, you may be closer to FP than you think. (The boundary is slippery.)

"OOP actually makes a ton of sense for CRUD and database operations."

Not at all OOP is great at simulations, videogames, emergent behaviour in general. If you do crud with oop you will complain about overengineering.

Maybe I am not exactly what you mentioned, but I do feel OOP set us back about a decade or two and do think the general concept of microservices is a good idea. But maybe to your point, these beliefs are completely orthagonal to one another, and why they are mentioned as being related baffled me. To be honest the whole post baffled me and I am disappointed I can not downvote the submission. Anyway more to your topic- OOP in the early 2000s was put on this massive pedestal and trying to point out its flaws would often get you chastised or shunned, and labeled that you just didn't get OOP and such. But the object hierarchies often became their own source of inflexibility, and shoehorning something new into them could often be very difficult and often involve an hour or three of debate/meetings on how to best make teh change.

Microservices are more about making very concrete borders between components with an actual network in between them... and really a contract that has to be negotiated across teams. I feel the best thing this did was force a real conversation around the API boundary and contract, monoliths turn to a big ball of mud once a change slips through that passes in an entire object when just a field is needed, and after a few of these now everything is fairly tightly coupled- modern practices with PRs could prevent a lot of this, but there is still a lot of rubber stamping going on and they don't catch everything. Objects themselves are fine ideas, and I think OOP is great when you focus on composition over inheritance, and bonus points if the objects map cleanly into a relational database schema- once you are starting getting inheritance hierarchies, they often do not. If I had to guess, your experience with OOP is mostly using ORMs where you define the data and it spits out a table for you and some accessor methods, and that works... until it doesn't. At a certain level of complexity the ORM falls apart, and what I have seen in nearly every place I have worked at- is that at some point some innocuous change gets included and now all of a sudden a query does not use an index properly, and it works fine in dev, but then you push it to prod and the DB lights on fire and its really difficult to understand what happened. The style of programming you are talking about would be derided by some old heads as "C with objects" and not "really" OOP. But I do think you are onto something by taking the best parts and avoiding the bad.

"Micro" services aren't great when they are taken to their utmost tiny size, but the idea of a problem domain being well constrained into a deployable unit usually leads to better long term outcomes than a monolith, though its also very true that for under $10k you can get 32 cores of xeons and about 256 gigs of ram, and unless you are building something with intense compute requirements, that is going to get you a VERY long way in terms of concurrent users.