It's unclear to me what the author thinks OOP is, and what he thinks we are replacing it with. The main point of OOP to me is hiding internal state. So OOP is great for user-interface, because there's all kinds of state there (not just the model, but the internal state of the UI element, like the scroll position of a list or the selection range of a text edit). Microservices, in fact, could be considered "network objects" and a microservice framework as network OOP. The problem there is that normal making a function call is straight-forward. The call produce a failure result, but the call actually happens. On the network, the call might not happen, and you might not be aware that the call cannot and will not happen for some seconds. This is not likely to simplify your code...
OOP can be just about structuring code, like the Java OOP fundamentalism, where even a function must be a Runnable object (unless it's changed since Oracle took over). If there's anything that is not an object, it's a function!
Some things are not well-suited to OOP, like linear processing of information in a server. I suspect this is where the FP excitement came from. In transforming information and passing it around, no state is needed or wanted, and immutability is helpful. FP in a UI or a game is not so fun (witness all the hooks in React, which in anything complicated is difficult to follow), since both of those require considerable internal state.
Algorithms are a sort of middle ground. Some algorithms require keeping track of a bunch of things, others more or less just transform the inputs. OOP (internal to the algorithm) can make the former much clearer, while it is unhelpful for that latter.
> The main point of OOP to me is hiding internal state. So OOP is great for user-interface
One principal I pursue aggressively in UI design is NOT hiding state!
A client had written a script to calibrate an embedded system across several operating parameters. The program consisted of a TUI to capture setup parameters, then ran 5-layers of nested FOR loop for several hours. This original program lacked even a basic progress bar. You never knew what it was doing or when it would be done - it hid a lot of internal state!
You might say, "the TUI program was hiding relevant state; your program should only hide the irrelevant state." But as I iterated on the program I realized that literally all of the program state was relevant! So I meticulously crafted a GUI to display every operational detail on screen at all times. This included the state of each FOR loop, a plot of the intermediate results, the state of each TCP connection, the state of the unit under test, and the user-selected test parameters, the full path of the calibration files the test relied upon.
While the program had some "magic" (it would auto-recall the default parameters associated with the model under test, and would auto detect equipment types with a network scan) I future-proofed it by ensuring that ALL of the parameters were both visible (not hidden!) and human-overridable AND resettable (A reset-to-default option would appear when the user changed defaults, in case the selection was unintended.) The GUI is also wire silent (no network packets transmitted) until directed by the user to scan for/connect to equipment, and it gives a visual indicator while waiting for network responses.
The GUI also tracked test progress as a first-class file-saveable object, so not only was there a progress bar, but tests could be resumed if equipment connectivity was lost mid-test. And a 95% confidence interval estimate, shown as "between 9 and 13 minutes remaining" to help production techs plan their day.
Even when state is read-only, I still don't hide it. Once a test has commenced, the selectable test parameters cannot be changed, but displaying them on screen confirms to users that their 5-hour test was not started with the wrong parameters.
My big takeaway from this effort is that ANY hidden/inaccessible state is a liability. A user should be able to observe at all times what their program is up to.
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.
And to me it's just message passing, no inheritance, and with or without unobservable internal state. So long as you're calling procedures that are determined by the "type" of the object, whether dynamic or statically dispatched, it's OOP.
Personally I'm against the practice of enforced state-hiding. I prefer the convention that state ought not to be depended upon, but if you do want to depend on it (sometimes important for composition or inheritance) you have tests to catch changes in the behavior of that state.
And in practice there's often a state-machine of some kind hidden away inside various object types that you cannot avoid depending on.
> Personally I'm against the practice of enforced state-hiding
Then you are against message passing paradigms. Message passing paradigm implies you can't just go and set state/create state directly, you need to send a message and then the receiver decides what to do with that message.
Its like saying that you like functional programming with mutable state, mutable state makes it no longer functional programming even if you use functions here and there.
IMHO the real key of message passing is localized decision making on a specific instance of data.
Similarly message passing allows an actor to decide how to respond to an event, to forward a message, to ignore it, etc. That's possible but more difficult to achieve with Java/C++ "straightjacket" style OOP. Important patterns for GUIs like the Observer pattern are just simpler with a message passing paradigm.
> 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.
Unnecessarily is the key word here. Sometimes, although admittedly rarely, the benefits do outweigh the costs, and it is necessary.
The problem is that if you grow your monolith to the point that it becomes necessary to split it up, now you generally have a long, expensive and error-prone migration on your hands. If you architect you system with this eventual transition in mind from the start, though, it can be much less painful.
> So OOP is great for user-interface, because there's all kinds of state there (not just the model, but the internal state of the UI element, like the scroll position of a list or the selection range of a text edit).
OOP is not better suited for user-interfaces than the alternatives.
The problem with OOP is that it becomes a death trap for those who like to over-engineer things. It’s like a cabinet full of booze in the house of an alcoholic. I worked with this guy, who loved to tell everyone very proudly that he was a self taught OO developer. Working on his code was truly miserable, an over-engineered mess of deep inheritance hierarchies that had absolutely no reason to exist other than make the codebase impossible to maintain. He also happened to love Regex and would write 50+ character Regex that could have been done with 3-4 lines of human readable code with zero performance penalty. But he loved intriguing one liners. Design patterns in OOP are great if you are disciplined enough to use them when they really matter. If you use them to just signal expertise with convoluted code and excessive abstractions they backfire really bad.
I think that "OOP" is an incredibly overloaded term which makes it difficult to speak about intelligibly or usefully at this point.
Are we talking about using classes at all? Are we arguing about Monoliths vs [Micro]services?
I don't really think about "OOP" very often. I also don't think about microservices. What some people seem to be talking about when they say they use "OOP" seems strange and foreign to me, and I agree we shouldn't do it like that. But what _other_ people mean by "OOP" when they say they don't use it seems entirely reasonable and sane to me.
Using classes hasn't been a part of the definition of OOP since the Treaty of Orlando. Pre-ECMAScript-2015 JS is a mainstream OOP language that doesn't have classes, just prototypes. (Arguably ECMAScript 2015 classes aren't really classes either.)
I think in terms of language features and patterns which actually mean something. OOP doesn't really mean anything to me, given that it doesn't seem to mean anything consistent in the industry.
Of course I work with classes, inheritance, interfaces, overloading, whatever quite frequently. Sometimes, I eschew their usage because the situation doesn't call for it or because I am working in something which also eschews such things.
What I don't do is care about "OOP" is a concept in and of itself.
Well.. I don't understand how you can read a confused and muddled article by someone who doesn't want to know the difference between JavaTM and one of its notable choices in the many dimensions of language choices and not wish to be a little more enlightened as to the difference between hiring an OOP monkey or a VMware jockey to smash some bits about.. The article is like a poster child for taking an hour to learn what your profession is about.
Respectfully, it's not clear to me what you're saying. You're clearly displeased with both the author of the article and with myself, but beyond that, I'm not sure what your thesis is.
We give features of a profession terms so we can refer to them independently and make reasonable discussions that don't confuse people as to which traits we think something that is neither Java nor Python (and so need not match either of them on every dimension) should have.
For example, I hate Java because of OOP, but strong typing can make a lot of bad in a language tolerable. Does the writer of the article agree with me? They don't seem able to understand whether they do.
In a comment about nailing the jargon, kinda ironic that you probably meant to say static typing rather than praise Java for its mediocre strong typing.
Technically maybe yes, but that would confuse me with some of my colleagues that like explicit static types. I like type inference systems but loath type confusion.
I think this is some combination of strawman, and subset of all cases. You can lament complications of OOP. You can also lament the complications of docker, kubernetes, HTTP APIs etc. These aren't mutually exclusive, and they don't span the breadth of programming techniques. I prefer avoiding all of these.
Anecdotally, I've replaced OOP with plain data structures and functions.
>> _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.
IME microservices solve engineering process problems (i.e. synchronization, enforcement of interface boundaries, build and test scale issues), not technical problems in the product.
I agree, very true when used for purposes as you noted. I guess my point was more about using them as a way solve the underlying problems a large OO system can develop.
Microservices enforce you to package data sets for transport, it's very functional if you only take the data and transport into consideration, the mess can still happen within the microservice though.
>> 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.
Objects/classes work best for datastructures (IMO).
Outside that usecase, I think polymorphism via inheritance is generally a mistake.
Programs manipulate data and datastructures organize that data in a way that's algorithmically efficient.
The main issue with OOP is that without a very clear abstraction, it can be almost impossible to reason about code as you end up needing to know too much about the hierarchy of code to correctly understand what will happen next. As it turns out, most programmers are pretty bad at managing that abstraction boundary.
OOP is like alcohol: enjoyable in moderation but dangerous in excess.
In moderation, an object is a data structure with associated functions (methods) that acts as a kind of namespace. If your data structure and functions are separate, you might start having function name collisions.
I'm not really qualified to talk about either topic at length, but my impression is that the Microservice crowd is kind of a different group than the anti-OOP crowd.
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 get not wanting crazy multi tier class inheritance, that seems like a disaster.
In my case, I wanted to do CRUD endpoints which were programmatically generated based on database schema. Turns out - it's super hard without an ORM or at least some kind of object layer. I got halfway through it before I realized what I was making was actually an ORM.
Please feel free to let me know why this is all an awful idea, or why I'm doing it wrong, I genuinely am just winging it.
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.
Large projects benefited from OOP because large projects need abstraction and modularization. But OOP is not unique in providing those benefits, and it includes some constructs (e.g. inheritance, strictly-dynamic polymorphism) that have proven harmful over time.
It may be extreme, but it's very common. It's probably the single most common argument used against OOP. If you drop out inheritance, most of the complaints about OO fall away.
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.
That's because you are wrong. There's nothing in relational databases mapping that make objects a better target than even the normal data structures you see in functional languages.
> In my case, I wanted to do CRUD endpoints which were programmatically generated based on database schema.
What is a pure transformation.
The problem is that CRUD applications are an incredibly bad explored area. There only mature projects out there are the OOP ORM ones. That's not because OOP is inherently better suited to the application, it's because there's simply not a lot of people willing to risk into working at that problem.
(And the reason people are not willing can be because developers don't choose their tools through rational evaluation, or may be some irrational one IDK. Mine is certainly because I know if I built an amazing system, nobody would come.)
I don't know! Can you explain it, or how I would use it for this application?
> And the reason people are not willing can be because developers don't choose their tools through rational evaluation, or may be some irrational one IDK.
I think "do the tools exist in the world" is a pretty rational evaluation. I'd love to see the FP equivalent!
A pure function is a function whose output only depends on the paramters and not has any internal state. Which in my opinion is a somewhat useless distinction, because you can make your state/instance/whatever the first parameter, (what C and Python do) and tada, every function that doesn't use globals (or static in C), is a pure function.
OOP is not simplifying CRUD or DB ops because you want to batch.
You don’t want lazy loading. You don’t want to load 1 thing. You don’t want to update 1 thing.
You want to actually exploit RETURNING and not have the transaction fail on a single element in batch.
If you care about performance you do not want ORM at all.
You want to load the response buffer and not hydrate objects.
If you ignore ORM you will realize CRUD is easy. You could even batch the actual HTTP requests instead of processing them 1 by 1. Try to do that with a bunch of objects.
I would personally never use ORM or dependency injection (toposort+annotations). Both approaches in my opinion do not solve hard problems and in most cases you don’t even want to have the problems they solve.
Optimize for your users above all else. Yes, even above developer experience. If that means optimize for performance, you optimize for performance.
The only thing that matters is what your users feel when using your product. Everything else is a waste of time. OOP, FP, language choice, it's all just fluff.
> 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.
OOP is nothing but trouble when you try to do some advanced database operations. Select some columns, aggregate them. That is hard in OOP. Throw in window functions and OOP just decides you don't exist.
OOP is a fine paradigm for an abstraction boundary, the problem is actually abstraction boundaries in the wrong places. Make your object the database, and none of these problems exist. I know none of these OOP-first/only languages encourages that.
> 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.
I mean, I think this is likely the case. So, I tried this, for example in Go, which is not really a proper functional programming language as I understand it, but is definitely not object-oriented.
So for my use case, I wanted to be able to take a database schema and programmatically create a set of CRUD endpoints in a TUI. Based on my pretty limited knowledge of Go, I found this to be pretty challenging. At first, I built it with Soda / Pop, the ORM from Buffalo framework. It worked fairly well.
Then I got frustrated with using Soda outside Buffalo, and yoinked the ORM to try and remove a layer. Using vanilla Go, it seems like the accepted pattern is that you create separate functions for C R U and D, as you referred to. However, it seems like this is pretty challenging to do programmatically, particularly without sophisticated metaprogramming, and even if you had a language which had complex macros or something, that is objectively significantly harder than object.get() and object.save().
Finally, I put GORM back in, and it worked fine. And GORM is a nice library, even though I think having an ORM is not the "Go" way of doing things in the first place. But also, Gorm is basically using function magic to feel like OOP. And maybe the problem with this idea is that it's not "Proper Go" to make a thing like this, it would be better to just code it. There's an admin panel in the Pagoda go stack which relies on ent ORM to function as well. I can only assume the developer motivations but I assume they are along the same lines as my experience.
I certainly don't think any of this requires insane class inheritance, and maybe that's all people are talking about with OOP. But I still think methods go a long way in this scenario.
In the real world, in business logic, objects do things. They aren't just data structures.
To summarize, CRUD seems pretty easy in any language, programmatically doing CRUD seems super hard in FP. Classes make that a lot easier. Maybe we shouldn't do that ever, and that's fine, but I'm a Django guy, I love my admin panels. Just my experience.
> I certainly don't think any of this requires insane class inheritance, and maybe that's all people are talking about with OOP. But I still think methods go a long way in this scenario.
Methods at all make a language OOP. Class inheritance is almost a side quest in OOP. (There are OOP languages with no class inheritance.)
Go seems quite object-oriented to me. I would definitely assume it is easier to use an ORM in Go than to not use an ORM.
I don't use a lot of Go, so I can't speak to anything about what the "proper Go" way of doing things is.
I could try to describe some of the non-ORM, functional programming ways of working with databases as I've seen in languages like F#, Haskell, or Lisp, but I'm not sure how helpful that would be to show that CRUD is not "super hard" in FP especially because you won't be familiar with those languages.
The thing I'm mostly picking up from your post here is that you like OOP and are comfortable with it, and that's great. Use what you like and use what you are comfortable with. OOP is great in that a lot of people also like it and feel comfortable with it.
I think that's fair, and I generally prefer a lighter stack for CRUD, but I still love Django and Rails. Maybe just having "objects" is not enough to qualify as OOP but for many use cases, the convenience offered by "Batteries Included" is worth the trade off in "overengineering".
If I have to build an app, I'm going for rails. If I'm building a back end, I'm reaching for Go. If I need to integrate with Python libraries, Django is great.
But ask me again when I get to the other side of some OCAML projects
Even in video games, I avoid inheritance, I always much prefer composition. Build a complex object from many small objects, then vary behavior with parameters rather than deriving a child class and overriding methods.
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.
> OpenAPI schemas replace type-checkers, docker compose replaces service factories, Kubernetes replaces the event loop. Every call across components acrues failure modes, requires a slow march through (de)serialisation libraries, a long trek through the kernel’s scheduler.
This has nothing to do with OOP, and can be made out of structured-programming components, or even purely functional components. In fact, stateless services are a staple of horizontal scaling, and could be a poster child of FP taking over the real world (along with React).
What made OOP problematic was mostly shared and concealed mutable state, and the ill-conceived idea of inheritance. Both of these traits are being actively eschewed in most modern software: mutable state is largely separated into databases, inheritance is often rejected in favor of composition. These are all practical, non-ideological choices, ways to relieve well-known pains. It this regard, OOP is on its way out, even in strongholds where it's ingrained into the very fabric, like JVM languages.
The complaints of the author are mostly about component-based architecture, with limited compile-time trust (know thy vendor) and large run-time distrust (every network request should be seen as a potentially malicious request). This is the price that we pay for having so many ready-made building blocks to choose from, and for the ability to make our services available (or access someone else's services) anywhere on the planet, 24/7.
Highly scalable architectures with their complexity were invented by companies who needed them, like, well, Google or Amazon. There is no good way to serve billions of requests daily. If you serve mere millions, you may not even need all that, and make do with a few beefier boxes. It has nothing to do with OOP, again.
> Other bright sparks jumped in on the action: what if this separation did not rely on the personal hygiene of the programmers - something that should always be called into question for public health reasons - and was instead enforced by the language? Components might hide their implementation by default and communicate only though a set of public functions, and the language might reject programs that tried to skip around these barricades. How quaint.
Sounds like C.
When was the last time you did OO against a .h file without even needing access to the .c file?
> And so, the process/network boundary naturally became that highest and thickest wall
I've had it both ways. Probably everyone here has. It's difficult to make changes with microservices. You gotta open new routes, and wait for people to start using those routes before you close the old ones. But it's impossible to make changes to a monolith: other teams aren't using your routes, they're using your services and database tables.
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.
Polymorphism is trivial in C and even less restrictive than in other OOP-first languages. The reason why GTK (actually GObject) is so overengineered is not due to classes, but because it allows to create classes and types at runtime.
I like programming OOP in C, because everything is explicit and you can seamlessly transit between different paradigms, and you can be actually creative with inheritance, which is something you can't do when your vtables are created automatically.
From one rambler to another: I’m not sure who or what this aimed at, as it goes all over the place.
Cloud: Separating resources from what gets deployed is a classic separation of concerns.
I don’t miss the days where I had to negotiate with the IT team on hardware, what gets run, and so on.
Personally, I believe the next evolution is a rebalkanization into private clouds. Mid-to-large companies have zero reason to tie their entire computing and expose information to hosting third parties.
OpenAPI: The industry went through a number of false starts on formal remoting calls (corba, dcom, soap). Those days sucked.
The RESTful APIs caught on, and of course at some point, the need for a formal contract was recognized.
But note how decoupled it is from the underlying stack: It forces the engineers to think about the contract as a separate concern.
The problem here is how fragile the web protocol and security actually is, but the past alternatives offer no solution here.
Many great design patterns have come from OOP and have found their home in functional languages or libraries.
Dependency injection has to be the most successful one, but there's at least another dozen good ideas that came from OO world and has been found to be solid.
What has rarely proven to be a good idea instead is inheritance at behavior level. It's fine for interfaces, but that's it. Same for stateful classes, beyond simple data containers like refs.
You can even have classes in functional programming word, it's irrelevant, it's an implementation detail, what matters is that your computations are pure, and side effects are implemented in an encoded form that can be combined in a pure way (an IO or Effect data type works, but so can a simple lazy function encoding).
No, "we" are not replacing OOP with something worse. "We" are replacing layers of stupid shit that got layered on top of, and associated with OOP, with different renderings of the same stupid shit.
I have been programming since 1967. Early in my college days, when I was programming in FORTRAN and ALGOL-W, I came across structured programming. The core idea was that a language should provide direct support for frequently used patterns. Implementing what we now call while loops using IFs and GOTOs? How about adding a while loop to the language itself? And while we're at it, GOTO is never a good idea, don't use it even if your language provides it.
Then there were Abstract Datatypes, which provided my first encounter with the idea that the interface to an ADT was what you should program with, and that the implementation behind that interface was a separate (and maybe even inaccessible) thing. The canonical example of the day was a stack. You have PUSH and POP at the interface, and the implementation could be a linked list, or an array, or a circular array, or something else.
And then the next step in that evolution, a few years later, was OOP. The idea was not that big a step from ADTs and structured programming. Here are some common patterns (modularization, encapsulation, inheritance), and some programming language ideas to provide them directly. (As originally conceived, OOP also had a way of objects interacting, through messages. That is certainly not present in all OO languages.)
And that's all folks.
All the glop that was added later -- Factories, FactoryFactories, GoF patterns, services, microservices -- that's not OOP as originally proposed. A bunch of often questionable ideas were expressed using OO, but they were not part of OO.
The OOP hatred has always been bizarre to me, and I think mostly motivated by these false associations. The essential OOP ideas are uncontroversial. They are just programming language constructs designed to support programming practices that are pretty widely recognized as good ones, regardless of your language choices. Pick your language, use the OO parts or not, it isn't that big a deal. And if your language doesn't have OO bits, then good programming often involves reimplementing them in a systematic way.
These pro- and anti-OOP discussions, which can get pretty voluminous and heated, seem a lot like religious wars. Look, we can all agree that the Golden Rule is a pretty good idea, regardless of the layers of terrible ideas that get piled onto different religions incorporating that rule.
I'm the kind of person that sees a bowl as a large cup without a handle.
Likewise, I see these patterns as equivalent style choices, since the problem fundamentally dictates the required organization and data flow, because the same optimal solution will be visible to any skilled developer, with these weak style choices of implementation being the only freedom that they actually have.
For example, these two are exactly the same:
state = concept_operation(state, ...args)
and
class Concept:
def operation(self, ...args)
self.state = <whatever with self.state>
and an API call to https://url/concept/operation with a session ID where the state is held.
I suspect people who get emotional about these things haven't spent too much time in the others, to understand why they exist with such widespread use.
It's like food. If you go anywhere and see the common man eating something, there's a reason they're eating it, and that reason is that's it's probably pretty ok, if you just try it. There's a reason they're eating it, and it's not that they're idiots.
OOD/OOP has not gone away, has not shifted etc. but is alive and well; just packaged under different looking gloss. The meta-principles behind it are fundamental to large scale systems development, namely; Separation-Of-Concerns, Modularization, Reuse and Information-Hiding.
These are not the same thing. The GOTO people complained about and what the famous article "GOTO considered harmful" is about, is called longjmp in C. Nearly all C programmers will agree with you that you shouldn't use longjmp. The goto of C has less freedom for control flow than try-catch constructs in other languages.
I think it would be very nice if the author provided citations for their assertions about how OOP was adopted. I was alive and gigging as a coder in the 80s when people had interminable arguments about Structured Programming, unstructured programming, OOP and every now and again LISP or FORTH. None of what the author mentions rings true. Standard interfaces came DECADES before anyone started talking about OOP. Rationalizing standard interfaces was mentioned in mythical man month. Structured Development was all the rage in the early 80s when I started selling 6502 op codes. Half the people I talked to in the 80s insisted C++ WAS OOP while the other half found that quote from Alan Kay who said C++ wasn't what he was thinking of when he invented the term "Object Oriented Programming."
I think the author is correctly picking up on how messy changes in best common practice can be. Also, different communities / verticals convert to the true religion on different schedules. The custom enterprise app guys are WAAAAY different than games programmers. I'm not sure you'll ever get those communities to speak the same language.
I think that the author is confusing OOP with Java. And I agree, Java is great and had most of the things we do now with overbloated infrastructures at least a couple of decades ago. We like to reinvent the wheel, that's what we do, but each time we give it another name. Then we complain about the old good time when everything could run on a Pentium and 64MB RAM.
I've been equally happy with oop and non-oop and have been programming for 35 years of my life between c/c++/java/python/go/ts.
I'd say that right now the edge is with non-oop.
But dare I say too, llms will make this battle mean less than it did 5 years ago. Look, I'm not looking to battle llms vs not - but the bottom line is that nearly all code in a 10 years time will be written and/or managed 99% by llms.
Pet Peeve Trifecta:
(1) Wielding "OOP" as a pejorative without justification or context.
(2) Transferring critiques from one subject to another via superficial similarities.
(3) Patronizing twee storybook tone.
> Every call across components acrues failure modes, requires a slow march through (de)serialisation libraries, a long trek through the kernel’s scheduler. A TLB cache invalidation here, a socket poll there. Perhaps a sneaky HTTP request to localhost for desert.
And this has tangible costs, too. I saved more than $10k a month in hosting costs for a small startup by combining a few microservices (hosted on separate VMs) into a single service. The savings in development time by eliminating all of the serialization layers is also appreciable, too.
Microservices are a bad pattern. Function as a service is better, because that architecture tends to assume vertical integration within the function and you can leverage a shared business logic library across an organization. Having service-to-service communication is the thing that makes microservices suck, if you can give people autonomy while having a shared systems language and keeping computation on one system it works ok.
Nah, I’ll agree with parent: they’re objectively bad. They turn what could be IPC into network calls, and because everything uses frameworks and ORMs, it’s all slow as hell.
“We can move faster” (but at the cost of our product being slower).
Microservices are a great solution to the problems you run into at high scale.
But they come at great cost. If you don't actually HAVE the problems they solve, do everything in your power to avoid them. If you can just throw money at larger servers, you should not use microservices.
> To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.
OOP today is really CBP (class based programming). Its really just imperative code hidden in methods that work on mutable state. Its gross. This is most common in Java, PHP and the likes.
I had a job interview where the guy asked me something along the lines of do I have experience with OOP or Microservices，or both. So I answered how I like both and feel that MS are Objects at the network layer, the dude cut me off and told me to stick to the question. Absolutely gut wrenching, I was being evaluated by who knows who, in a slot of 30 minutes, maybe his entire job was repeating the same set of questions 16 times per day and he was unironically writing down yes/no next to "Microservices?" "OOP"?
>> So I answered how I like both and feel that MS are Objects at the network layer, the dude cut me off and told me to stick to the question.
OMG! As an interviewer I would have asked you to elaborate on that response. Perfect opportunity to see if and how the candidate thinks and how deep some pocket of understanding goes.
do not iterate the bad feeling of this, the guy was not the level to understand the abstraction both give. while i have felt this sentiment towards things being reinvented, we have to assume some innovation is incremental, and the new thing looks like the old but allows kool new stuff such as networking.
TL;DR: OOP is being replaced by microservices (and even more extreme ideas), which is much worse. Yeah, I have to agree with this author.
I will say that service-oriented architecture does have some advantages, and thus sometimes it's the right choice. Parallelism is pretty free and natural, you can run services on different machines, and that can also give you scalability if you need it. However, in my experience that architecture tends to be used in myriad situations where it clearly isn't needed and is a net negative. I have seen it happen.
There is a kernel of insight here that is pretty valuable. Interfaces are a form of security and is a result of a loss of trust. It's interesting to think about how far trust can be extended before it breaks down.
This is so much nonsense. Contracts and interfaces have little to do with OOP. If you don't like inheritance, then talk about OOP. It's fine. Many people, including myself, don't like inheritance. On the other hand, if it's interfaces and contracts that have you bothered, parse-dont-validate to your heart's content. If the domain allows it. Just don't drag unrelated concepts into this particular discussion.
OOP is about messages according to the inventor - messages are about the interface. People get confused with objects which languages without messages don't have (you can get them, but they are not first class in the language)
Even plain objects though, the point isn't the inheritance! The point is to put an interface on the data. Inheritance is sometimes useful because, but there is a reason we keep screaming "prefer composition to inheritance" (even though few listen)
Nonsense. Network service layer separation solves a different problem than OOP. It doesn't replace it. Services and containers bring features and capabilities that OOP doesn't provide. It's orthogonal.
But I think that's really the point: it gets applied to problems it was clearly not meant to solve. The article doesn't really get into that, but that's how I'm reading it because I've seen it happen. To some programmers, every component of a program is its own service, even when there's no need to have multiple processes. The only tool they have is that hammer, so everything has to be a nail.
It's unclear to me what the author thinks OOP is, and what he thinks we are replacing it with. The main point of OOP to me is hiding internal state. So OOP is great for user-interface, because there's all kinds of state there (not just the model, but the internal state of the UI element, like the scroll position of a list or the selection range of a text edit). Microservices, in fact, could be considered "network objects" and a microservice framework as network OOP. The problem there is that normal making a function call is straight-forward. The call produce a failure result, but the call actually happens. On the network, the call might not happen, and you might not be aware that the call cannot and will not happen for some seconds. This is not likely to simplify your code...
OOP can be just about structuring code, like the Java OOP fundamentalism, where even a function must be a Runnable object (unless it's changed since Oracle took over). If there's anything that is not an object, it's a function!
Some things are not well-suited to OOP, like linear processing of information in a server. I suspect this is where the FP excitement came from. In transforming information and passing it around, no state is needed or wanted, and immutability is helpful. FP in a UI or a game is not so fun (witness all the hooks in React, which in anything complicated is difficult to follow), since both of those require considerable internal state.
Algorithms are a sort of middle ground. Some algorithms require keeping track of a bunch of things, others more or less just transform the inputs. OOP (internal to the algorithm) can make the former much clearer, while it is unhelpful for that latter.
> 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.
I'd settle for just getting inheritance to fade away.
> The main point of OOP to me is hiding internal state. So OOP is great for user-interface
One principal I pursue aggressively in UI design is NOT hiding state!
A client had written a script to calibrate an embedded system across several operating parameters. The program consisted of a TUI to capture setup parameters, then ran 5-layers of nested FOR loop for several hours. This original program lacked even a basic progress bar. You never knew what it was doing or when it would be done - it hid a lot of internal state!
You might say, "the TUI program was hiding relevant state; your program should only hide the irrelevant state." But as I iterated on the program I realized that literally all of the program state was relevant! So I meticulously crafted a GUI to display every operational detail on screen at all times. This included the state of each FOR loop, a plot of the intermediate results, the state of each TCP connection, the state of the unit under test, and the user-selected test parameters, the full path of the calibration files the test relied upon.
While the program had some "magic" (it would auto-recall the default parameters associated with the model under test, and would auto detect equipment types with a network scan) I future-proofed it by ensuring that ALL of the parameters were both visible (not hidden!) and human-overridable AND resettable (A reset-to-default option would appear when the user changed defaults, in case the selection was unintended.) The GUI is also wire silent (no network packets transmitted) until directed by the user to scan for/connect to equipment, and it gives a visual indicator while waiting for network responses.
The GUI also tracked test progress as a first-class file-saveable object, so not only was there a progress bar, but tests could be resumed if equipment connectivity was lost mid-test. And a 95% confidence interval estimate, shown as "between 9 and 13 minutes remaining" to help production techs plan their day.
Even when state is read-only, I still don't hide it. Once a test has commenced, the selectable test parameters cannot be changed, but displaying them on screen confirms to users that their 5-hour test was not started with the wrong parameters.
My big takeaway from this effort is that ANY hidden/inaccessible state is a liability. A user should be able to observe at all times what their program is up to.
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.
And to me it's just message passing, no inheritance, and with or without unobservable internal state. So long as you're calling procedures that are determined by the "type" of the object, whether dynamic or statically dispatched, it's OOP.
Personally I'm against the practice of enforced state-hiding. I prefer the convention that state ought not to be depended upon, but if you do want to depend on it (sometimes important for composition or inheritance) you have tests to catch changes in the behavior of that state.
And in practice there's often a state-machine of some kind hidden away inside various object types that you cannot avoid depending on.
> Personally I'm against the practice of enforced state-hiding
Then you are against message passing paradigms. Message passing paradigm implies you can't just go and set state/create state directly, you need to send a message and then the receiver decides what to do with that message.
Its like saying that you like functional programming with mutable state, mutable state makes it no longer functional programming even if you use functions here and there.
IMHO the real key of message passing is localized decision making on a specific instance of data.
Similarly message passing allows an actor to decide how to respond to an event, to forward a message, to ignore it, etc. That's possible but more difficult to achieve with Java/C++ "straightjacket" style OOP. Important patterns for GUIs like the Observer pattern are just simpler with a message passing paradigm.
> 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.
Unnecessarily is the key word here. Sometimes, although admittedly rarely, the benefits do outweigh the costs, and it is necessary.
The problem is that if you grow your monolith to the point that it becomes necessary to split it up, now you generally have a long, expensive and error-prone migration on your hands. If you architect you system with this eventual transition in mind from the start, though, it can be much less painful.
> If there's anything that is not an object, it's a function!
Why, functions have state -- their closure.
Ancient wisdom: closures are a poor man's objects; objects are a poor man's closures.
https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/...
closures and objects with a single invoke() method have been considered equivalent in many views for some time.
Exactly, that's why I disagree with parent's comment:
> If there's anything that is not an object, it's a function!
> So OOP is great for user-interface, because there's all kinds of state there (not just the model, but the internal state of the UI element, like the scroll position of a list or the selection range of a text edit).
OOP is not better suited for user-interfaces than the alternatives.
The problem with OOP is that it becomes a death trap for those who like to over-engineer things. It’s like a cabinet full of booze in the house of an alcoholic. I worked with this guy, who loved to tell everyone very proudly that he was a self taught OO developer. Working on his code was truly miserable, an over-engineered mess of deep inheritance hierarchies that had absolutely no reason to exist other than make the codebase impossible to maintain. He also happened to love Regex and would write 50+ character Regex that could have been done with 3-4 lines of human readable code with zero performance penalty. But he loved intriguing one liners. Design patterns in OOP are great if you are disciplined enough to use them when they really matter. If you use them to just signal expertise with convoluted code and excessive abstractions they backfire really bad.
I think that "OOP" is an incredibly overloaded term which makes it difficult to speak about intelligibly or usefully at this point.
Are we talking about using classes at all? Are we arguing about Monoliths vs [Micro]services?
I don't really think about "OOP" very often. I also don't think about microservices. What some people seem to be talking about when they say they use "OOP" seems strange and foreign to me, and I agree we shouldn't do it like that. But what _other_ people mean by "OOP" when they say they don't use it seems entirely reasonable and sane to me.
> Are we talking about using classes at all?
Using classes hasn't been a part of the definition of OOP since the Treaty of Orlando. Pre-ECMAScript-2015 JS is a mainstream OOP language that doesn't have classes, just prototypes. (Arguably ECMAScript 2015 classes aren't really classes either.)
OOP isn't just about classes... It can also be about JavaScript classes!
"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?
Primarily poor wording on my part.
I think in terms of language features and patterns which actually mean something. OOP doesn't really mean anything to me, given that it doesn't seem to mean anything consistent in the industry.
Of course I work with classes, inheritance, interfaces, overloading, whatever quite frequently. Sometimes, I eschew their usage because the situation doesn't call for it or because I am working in something which also eschews such things.
What I don't do is care about "OOP" is a concept in and of itself.
Well.. I don't understand how you can read a confused and muddled article by someone who doesn't want to know the difference between JavaTM and one of its notable choices in the many dimensions of language choices and not wish to be a little more enlightened as to the difference between hiring an OOP monkey or a VMware jockey to smash some bits about.. The article is like a poster child for taking an hour to learn what your profession is about.
Respectfully, it's not clear to me what you're saying. You're clearly displeased with both the author of the article and with myself, but beyond that, I'm not sure what your thesis is.
We give features of a profession terms so we can refer to them independently and make reasonable discussions that don't confuse people as to which traits we think something that is neither Java nor Python (and so need not match either of them on every dimension) should have.
For example, I hate Java because of OOP, but strong typing can make a lot of bad in a language tolerable. Does the writer of the article agree with me? They don't seem able to understand whether they do.
In a comment about nailing the jargon, kinda ironic that you probably meant to say static typing rather than praise Java for its mediocre strong typing.
Technically maybe yes, but that would confuse me with some of my colleagues that like explicit static types. I like type inference systems but loath type confusion.
> overloaded
I see what you did there
I think this is some combination of strawman, and subset of all cases. You can lament complications of OOP. You can also lament the complications of docker, kubernetes, HTTP APIs etc. These aren't mutually exclusive, and they don't span the breadth of programming techniques. I prefer avoiding all of these.
Anecdotally, I've replaced OOP with plain data structures and functions.
>> _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.
IME microservices solve engineering process problems (i.e. synchronization, enforcement of interface boundaries, build and test scale issues), not technical problems in the product.
I agree, very true when used for purposes as you noted. I guess my point was more about using them as a way solve the underlying problems a large OO system can develop. Microservices enforce you to package data sets for transport, it's very functional if you only take the data and transport into consideration, the mess can still happen within the microservice though.
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.
>> 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.
Objects/classes work best for datastructures (IMO).
Outside that usecase, I think polymorphism via inheritance is generally a mistake.
Programs manipulate data and datastructures organize that data in a way that's algorithmically efficient.
The main issue with OOP is that without a very clear abstraction, it can be almost impossible to reason about code as you end up needing to know too much about the hierarchy of code to correctly understand what will happen next. As it turns out, most programmers are pretty bad at managing that abstraction boundary.
OOP is like alcohol: enjoyable in moderation but dangerous in excess.
In moderation, an object is a data structure with associated functions (methods) that acts as a kind of namespace. If your data structure and functions are separate, you might start having function name collisions.
Hopefully we won't see a prohibition against OOP.
I'm not really qualified to talk about either topic at length, but my impression is that the Microservice crowd is kind of a different group than the anti-OOP crowd.
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 get not wanting crazy multi tier class inheritance, that seems like a disaster.
In my case, I wanted to do CRUD endpoints which were programmatically generated based on database schema. Turns out - it's super hard without an ORM or at least some kind of object layer. I got halfway through it before I realized what I was making was actually an ORM.
Please feel free to let me know why this is all an awful idea, or why I'm doing it wrong, I genuinely am just winging it.
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.
Large projects benefited from OOP because large projects need abstraction and modularization. But OOP is not unique in providing those benefits, and it includes some constructs (e.g. inheritance, strictly-dynamic polymorphism) that have proven harmful over time.
Inheritance == harmful is quite an extreme position.
It may be extreme, but it's very common. It's probably the single most common argument used against OOP. If you drop out inheritance, most of the complaints about OO fall away.
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).
This is probably the correct solution for this use case, but obviously and objectively much harder than object.get(id=1).
I was mainly doing this in Go, posted more in a side post.
> 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.
That's because you are wrong. There's nothing in relational databases mapping that make objects a better target than even the normal data structures you see in functional languages.
> In my case, I wanted to do CRUD endpoints which were programmatically generated based on database schema.
What is a pure transformation.
The problem is that CRUD applications are an incredibly bad explored area. There only mature projects out there are the OOP ORM ones. That's not because OOP is inherently better suited to the application, it's because there's simply not a lot of people willing to risk into working at that problem.
(And the reason people are not willing can be because developers don't choose their tools through rational evaluation, or may be some irrational one IDK. Mine is certainly because I know if I built an amazing system, nobody would come.)
> What is a pure transformation.
I don't know! Can you explain it, or how I would use it for this application?
> And the reason people are not willing can be because developers don't choose their tools through rational evaluation, or may be some irrational one IDK.
I think "do the tools exist in the world" is a pretty rational evaluation. I'd love to see the FP equivalent!
> I don't know!
A pure function is a function whose output only depends on the paramters and not has any internal state. Which in my opinion is a somewhat useless distinction, because you can make your state/instance/whatever the first parameter, (what C and Python do) and tada, every function that doesn't use globals (or static in C), is a pure function.
a pure function doesn't have side effects. it doesn't read from nonlocal state or trigger distant changes nor perform any manner of io.
a pure function doesn't change its inputs, it simply uses them to craft it's outputs.
bringing in an object or function via parameter to perform these side effects still leaves the function impure.
Is that distinct from a pure transformation?
A pure transformation is an abstract operation, a pure function implements it.
OOP is not simplifying CRUD or DB ops because you want to batch.
You don’t want lazy loading. You don’t want to load 1 thing. You don’t want to update 1 thing.
You want to actually exploit RETURNING and not have the transaction fail on a single element in batch.
If you care about performance you do not want ORM at all. You want to load the response buffer and not hydrate objects.
If you ignore ORM you will realize CRUD is easy. You could even batch the actual HTTP requests instead of processing them 1 by 1. Try to do that with a bunch of objects.
I would personally never use ORM or dependency injection (toposort+annotations). Both approaches in my opinion do not solve hard problems and in most cases you don’t even want to have the problems they solve.
I agree with you, but I am not sold on optimizing for performance above all else.
Business logic ran fine on ancient mainframes. It can run fine on Raspberry Pis.
CRUD is super easy. It's also not super resource intensive.
I know that's the path that led us all down into Java OOP / start menu is a react native component, but it is actually true.
ORM adds a convenience layer. It also adds some decent protection against SQL injects OOTB and other dev comforts.
Is that trade off worth it? Probably not. But sometimes it's the best tool for the job
Optimize for your users above all else. Yes, even above developer experience. If that means optimize for performance, you optimize for performance.
The only thing that matters is what your users feel when using your product. Everything else is a waste of time. OOP, FP, language choice, it's all just fluff.
I think this is a wonderful philosophy, but many times the actually more important thing is "optimize for the client's budget"
Sometimes the client just can't afford your services. There is nothing wrong with that. :)
> 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.
OOP is nothing but trouble when you try to do some advanced database operations. Select some columns, aggregate them. That is hard in OOP. Throw in window functions and OOP just decides you don't exist.
OOP is a fine paradigm for an abstraction boundary, the problem is actually abstraction boundaries in the wrong places. Make your object the database, and none of these problems exist. I know none of these OOP-first/only languages encourages that.
> 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.
I mean, I think this is likely the case. So, I tried this, for example in Go, which is not really a proper functional programming language as I understand it, but is definitely not object-oriented.
So for my use case, I wanted to be able to take a database schema and programmatically create a set of CRUD endpoints in a TUI. Based on my pretty limited knowledge of Go, I found this to be pretty challenging. At first, I built it with Soda / Pop, the ORM from Buffalo framework. It worked fairly well.
Then I got frustrated with using Soda outside Buffalo, and yoinked the ORM to try and remove a layer. Using vanilla Go, it seems like the accepted pattern is that you create separate functions for C R U and D, as you referred to. However, it seems like this is pretty challenging to do programmatically, particularly without sophisticated metaprogramming, and even if you had a language which had complex macros or something, that is objectively significantly harder than object.get() and object.save().
Finally, I put GORM back in, and it worked fine. And GORM is a nice library, even though I think having an ORM is not the "Go" way of doing things in the first place. But also, Gorm is basically using function magic to feel like OOP. And maybe the problem with this idea is that it's not "Proper Go" to make a thing like this, it would be better to just code it. There's an admin panel in the Pagoda go stack which relies on ent ORM to function as well. I can only assume the developer motivations but I assume they are along the same lines as my experience.
I certainly don't think any of this requires insane class inheritance, and maybe that's all people are talking about with OOP. But I still think methods go a long way in this scenario.
In the real world, in business logic, objects do things. They aren't just data structures.
To summarize, CRUD seems pretty easy in any language, programmatically doing CRUD seems super hard in FP. Classes make that a lot easier. Maybe we shouldn't do that ever, and that's fine, but I'm a Django guy, I love my admin panels. Just my experience.
> I certainly don't think any of this requires insane class inheritance, and maybe that's all people are talking about with OOP. But I still think methods go a long way in this scenario.
Methods at all make a language OOP. Class inheritance is almost a side quest in OOP. (There are OOP languages with no class inheritance.)
Go seems quite object-oriented to me. I would definitely assume it is easier to use an ORM in Go than to not use an ORM.
I don't use a lot of Go, so I can't speak to anything about what the "proper Go" way of doing things is.
I could try to describe some of the non-ORM, functional programming ways of working with databases as I've seen in languages like F#, Haskell, or Lisp, but I'm not sure how helpful that would be to show that CRUD is not "super hard" in FP especially because you won't be familiar with those languages.
The thing I'm mostly picking up from your post here is that you like OOP and are comfortable with it, and that's great. Use what you like and use what you are comfortable with. OOP is great in that a lot of people also like it and feel comfortable with it.
I get how to do CRUD in FP - I don't get how to generate endpoints automatically in FP. Is anybody doing that?
PostgREST
Dude awesome. I didn't realize this was Supabase backend. I haven't used Supabase but I really like their approach.
"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.
I think that's fair, and I generally prefer a lighter stack for CRUD, but I still love Django and Rails. Maybe just having "objects" is not enough to qualify as OOP but for many use cases, the convenience offered by "Batteries Included" is worth the trade off in "overengineering".
If I have to build an app, I'm going for rails. If I'm building a back end, I'm reaching for Go. If I need to integrate with Python libraries, Django is great.
But ask me again when I get to the other side of some OCAML projects
Even in video games, I avoid inheritance, I always much prefer composition. Build a complex object from many small objects, then vary behavior with parameters rather than deriving a child class and overriding methods.
Right that's still OOP.
Oh yeah, just saying inheritance is the part I don't like.
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.
> In times of old, people wrote programs. Things were easy and simple.
Fake history; the term "software crisis" was coined in 1968:
https://en.wikipedia.org/wiki/Software_crisis
I get that the writing is tongue-in-cheek, but telling just-so stories about how things were so much better in the old days doesn't help anyone.
I also resent our modern problems, but I don't kid myself that I'd enjoy vintage problems any better.
> At around the same time, some bright spark realised that programmers - a population of people not known for good hygiene [ ... ]
OK, I'm out.
> OpenAPI schemas replace type-checkers, docker compose replaces service factories, Kubernetes replaces the event loop. Every call across components acrues failure modes, requires a slow march through (de)serialisation libraries, a long trek through the kernel’s scheduler.
This has nothing to do with OOP, and can be made out of structured-programming components, or even purely functional components. In fact, stateless services are a staple of horizontal scaling, and could be a poster child of FP taking over the real world (along with React).
What made OOP problematic was mostly shared and concealed mutable state, and the ill-conceived idea of inheritance. Both of these traits are being actively eschewed in most modern software: mutable state is largely separated into databases, inheritance is often rejected in favor of composition. These are all practical, non-ideological choices, ways to relieve well-known pains. It this regard, OOP is on its way out, even in strongholds where it's ingrained into the very fabric, like JVM languages.
The complaints of the author are mostly about component-based architecture, with limited compile-time trust (know thy vendor) and large run-time distrust (every network request should be seen as a potentially malicious request). This is the price that we pay for having so many ready-made building blocks to choose from, and for the ability to make our services available (or access someone else's services) anywhere on the planet, 24/7.
Highly scalable architectures with their complexity were invented by companies who needed them, like, well, Google or Amazon. There is no good way to serve billions of requests daily. If you serve mere millions, you may not even need all that, and make do with a few beefier boxes. It has nothing to do with OOP, again.
> Other bright sparks jumped in on the action: what if this separation did not rely on the personal hygiene of the programmers - something that should always be called into question for public health reasons - and was instead enforced by the language? Components might hide their implementation by default and communicate only though a set of public functions, and the language might reject programs that tried to skip around these barricades. How quaint.
Sounds like C.
When was the last time you did OO against a .h file without even needing access to the .c file?
> And so, the process/network boundary naturally became that highest and thickest wall
I've had it both ways. Probably everyone here has. It's difficult to make changes with microservices. You gotta open new routes, and wait for people to start using those routes before you close the old ones. But it's impossible to make changes to a monolith: other teams aren't using your routes, they're using your services and database tables.
> 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.
Polymorphism is trivial in C and even less restrictive than in other OOP-first languages. The reason why GTK (actually GObject) is so overengineered is not due to classes, but because it allows to create classes and types at runtime.
It's older than C. But yes, C does module encapsulation.
C is capable enough to program in a way that is basically OOP and without using non-idiomatic code. The C++ object system wasn't created in a vacuum.
I like programming OOP in C, because everything is explicit and you can seamlessly transit between different paradigms, and you can be actually creative with inheritance, which is something you can't do when your vtables are created automatically.
From one rambler to another: I’m not sure who or what this aimed at, as it goes all over the place.
Cloud: Separating resources from what gets deployed is a classic separation of concerns.
I don’t miss the days where I had to negotiate with the IT team on hardware, what gets run, and so on.
Personally, I believe the next evolution is a rebalkanization into private clouds. Mid-to-large companies have zero reason to tie their entire computing and expose information to hosting third parties.
OpenAPI: The industry went through a number of false starts on formal remoting calls (corba, dcom, soap). Those days sucked.
The RESTful APIs caught on, and of course at some point, the need for a formal contract was recognized.
But note how decoupled it is from the underlying stack: It forces the engineers to think about the contract as a separate concern.
The problem here is how fragile the web protocol and security actually is, but the past alternatives offer no solution here.
Many great design patterns have come from OOP and have found their home in functional languages or libraries.
Dependency injection has to be the most successful one, but there's at least another dozen good ideas that came from OO world and has been found to be solid.
What has rarely proven to be a good idea instead is inheritance at behavior level. It's fine for interfaces, but that's it. Same for stateful classes, beyond simple data containers like refs.
You can even have classes in functional programming word, it's irrelevant, it's an implementation detail, what matters is that your computations are pure, and side effects are implemented in an encoded form that can be combined in a pure way (an IO or Effect data type works, but so can a simple lazy function encoding).
I think the opposite is true, many good patterns have been combined and are now called OOP. Most were already common before that and had another name.
No, "we" are not replacing OOP with something worse. "We" are replacing layers of stupid shit that got layered on top of, and associated with OOP, with different renderings of the same stupid shit.
I have been programming since 1967. Early in my college days, when I was programming in FORTRAN and ALGOL-W, I came across structured programming. The core idea was that a language should provide direct support for frequently used patterns. Implementing what we now call while loops using IFs and GOTOs? How about adding a while loop to the language itself? And while we're at it, GOTO is never a good idea, don't use it even if your language provides it.
Then there were Abstract Datatypes, which provided my first encounter with the idea that the interface to an ADT was what you should program with, and that the implementation behind that interface was a separate (and maybe even inaccessible) thing. The canonical example of the day was a stack. You have PUSH and POP at the interface, and the implementation could be a linked list, or an array, or a circular array, or something else.
And then the next step in that evolution, a few years later, was OOP. The idea was not that big a step from ADTs and structured programming. Here are some common patterns (modularization, encapsulation, inheritance), and some programming language ideas to provide them directly. (As originally conceived, OOP also had a way of objects interacting, through messages. That is certainly not present in all OO languages.)
And that's all folks.
All the glop that was added later -- Factories, FactoryFactories, GoF patterns, services, microservices -- that's not OOP as originally proposed. A bunch of often questionable ideas were expressed using OO, but they were not part of OO.
The OOP hatred has always been bizarre to me, and I think mostly motivated by these false associations. The essential OOP ideas are uncontroversial. They are just programming language constructs designed to support programming practices that are pretty widely recognized as good ones, regardless of your language choices. Pick your language, use the OO parts or not, it isn't that big a deal. And if your language doesn't have OO bits, then good programming often involves reimplementing them in a systematic way.
These pro- and anti-OOP discussions, which can get pretty voluminous and heated, seem a lot like religious wars. Look, we can all agree that the Golden Rule is a pretty good idea, regardless of the layers of terrible ideas that get piled onto different religions incorporating that rule.
I'm the kind of person that sees a bowl as a large cup without a handle.
Likewise, I see these patterns as equivalent style choices, since the problem fundamentally dictates the required organization and data flow, because the same optimal solution will be visible to any skilled developer, with these weak style choices of implementation being the only freedom that they actually have.
For example, these two are exactly the same:
and and an API call to https://url/concept/operation with a session ID where the state is held.I suspect people who get emotional about these things haven't spent too much time in the others, to understand why they exist with such widespread use.
It's like food. If you go anywhere and see the common man eating something, there's a reason they're eating it, and that reason is that's it's probably pretty ok, if you just try it. There's a reason they're eating it, and it's not that they're idiots.
A voice of sanity. The submitted article has zero meaningful content.
This comment i posted in an earlier thread rehashing Inheritance vs. Composition for the gazillionth time is highly relevant here - https://news.ycombinator.com/item?id=45943135
OOD/OOP has not gone away, has not shifted etc. but is alive and well; just packaged under different looking gloss. The meta-principles behind it are fundamental to large scale systems development, namely; Separation-Of-Concerns, Modularization, Reuse and Information-Hiding.
> And while we're at it, GOTO is never a good idea, don't use it even if your language provides it.
Good luck with that if you're a C programmer.
These are not the same thing. The GOTO people complained about and what the famous article "GOTO considered harmful" is about, is called longjmp in C. Nearly all C programmers will agree with you that you shouldn't use longjmp. The goto of C has less freedom for control flow than try-catch constructs in other languages.
Well sure, but don't use it to implement if/while/for.
I think it would be very nice if the author provided citations for their assertions about how OOP was adopted. I was alive and gigging as a coder in the 80s when people had interminable arguments about Structured Programming, unstructured programming, OOP and every now and again LISP or FORTH. None of what the author mentions rings true. Standard interfaces came DECADES before anyone started talking about OOP. Rationalizing standard interfaces was mentioned in mythical man month. Structured Development was all the rage in the early 80s when I started selling 6502 op codes. Half the people I talked to in the 80s insisted C++ WAS OOP while the other half found that quote from Alan Kay who said C++ wasn't what he was thinking of when he invented the term "Object Oriented Programming."
I think the author is correctly picking up on how messy changes in best common practice can be. Also, different communities / verticals convert to the true religion on different schedules. The custom enterprise app guys are WAAAAY different than games programmers. I'm not sure you'll ever get those communities to speak the same language.
OOP is dead. Long live OOP.
I think that the author is confusing OOP with Java. And I agree, Java is great and had most of the things we do now with overbloated infrastructures at least a couple of decades ago. We like to reinvent the wheel, that's what we do, but each time we give it another name. Then we complain about the old good time when everything could run on a Pentium and 64MB RAM.
I've been equally happy with oop and non-oop and have been programming for 35 years of my life between c/c++/java/python/go/ts.
I'd say that right now the edge is with non-oop.
But dare I say too, llms will make this battle mean less than it did 5 years ago. Look, I'm not looking to battle llms vs not - but the bottom line is that nearly all code in a 10 years time will be written and/or managed 99% by llms.
Pet Peeve Trifecta: (1) Wielding "OOP" as a pejorative without justification or context. (2) Transferring critiques from one subject to another via superficial similarities. (3) Patronizing twee storybook tone.
> Every call across components acrues failure modes, requires a slow march through (de)serialisation libraries, a long trek through the kernel’s scheduler. A TLB cache invalidation here, a socket poll there. Perhaps a sneaky HTTP request to localhost for desert.
And this has tangible costs, too. I saved more than $10k a month in hosting costs for a small startup by combining a few microservices (hosted on separate VMs) into a single service. The savings in development time by eliminating all of the serialization layers is also appreciable, too.
Microservices are a bad pattern. Function as a service is better, because that architecture tends to assume vertical integration within the function and you can leverage a shared business logic library across an organization. Having service-to-service communication is the thing that makes microservices suck, if you can give people autonomy while having a shared systems language and keeping computation on one system it works ok.
Micro services are neither bad or good, they are simply misunderstood.
They are a solution to communication and organizational challenges, not a technical one.
As every other solution they have cons, some of which you have outlined.
Nah, I’ll agree with parent: they’re objectively bad. They turn what could be IPC into network calls, and because everything uses frameworks and ORMs, it’s all slow as hell.
“We can move faster” (but at the cost of our product being slower).
I have found that Protocol-Oriented Programming is basically "OOP without classes."
Protocols have their issues, though[0]. Not exactly the same results.
[0] https://littlegreenviper.com/the-curious-case-of-the-protoco...
Microservices are a great solution to the problems you run into at high scale.
But they come at great cost. If you don't actually HAVE the problems they solve, do everything in your power to avoid them. If you can just throw money at larger servers, you should not use microservices.
Biggest problem here is way too many people think they have those problems or they will have them in a second.
Someone is bound to quote Dijkstra here:
> To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.
OOP today is really CBP (class based programming). Its really just imperative code hidden in methods that work on mutable state. Its gross. This is most common in Java, PHP and the likes.
Oh gosh I clicked "Enter the tarpit". I hope I didn't blacklist my IP or something.
Silly link, though. I highly suggest going back and clicking on the link.
There's a time and a place for all of these things. Like everything in life, many people pick the wrong time and wrong place.
> Perhaps a sneaky HTTP request to localhost for desert.
Typo: dessert
I had a job interview where the guy asked me something along the lines of do I have experience with OOP or Microservices，or both. So I answered how I like both and feel that MS are Objects at the network layer, the dude cut me off and told me to stick to the question. Absolutely gut wrenching, I was being evaluated by who knows who, in a slot of 30 minutes, maybe his entire job was repeating the same set of questions 16 times per day and he was unironically writing down yes/no next to "Microservices?" "OOP"?
>> So I answered how I like both and feel that MS are Objects at the network layer, the dude cut me off and told me to stick to the question.
OMG! As an interviewer I would have asked you to elaborate on that response. Perfect opportunity to see if and how the candidate thinks and how deep some pocket of understanding goes.
do not iterate the bad feeling of this, the guy was not the level to understand the abstraction both give. while i have felt this sentiment towards things being reinvented, we have to assume some innovation is incremental, and the new thing looks like the old but allows kool new stuff such as networking.
TL;DR: OOP is being replaced by microservices (and even more extreme ideas), which is much worse. Yeah, I have to agree with this author.
I will say that service-oriented architecture does have some advantages, and thus sometimes it's the right choice. Parallelism is pretty free and natural, you can run services on different machines, and that can also give you scalability if you need it. However, in my experience that architecture tends to be used in myriad situations where it clearly isn't needed and is a net negative. I have seen it happen.
The idea of "we are replacing <thing> with microservices, which is much worse" is true for almost any <thing>, OOP or not.
There is a kernel of insight here that is pretty valuable. Interfaces are a form of security and is a result of a loss of trust. It's interesting to think about how far trust can be extended before it breaks down.
This is so much nonsense. Contracts and interfaces have little to do with OOP. If you don't like inheritance, then talk about OOP. It's fine. Many people, including myself, don't like inheritance. On the other hand, if it's interfaces and contracts that have you bothered, parse-dont-validate to your heart's content. If the domain allows it. Just don't drag unrelated concepts into this particular discussion.
OOP is about messages according to the inventor - messages are about the interface. People get confused with objects which languages without messages don't have (you can get them, but they are not first class in the language)
Even plain objects though, the point isn't the inheritance! The point is to put an interface on the data. Inheritance is sometimes useful because, but there is a reason we keep screaming "prefer composition to inheritance" (even though few listen)
Nonsense. Network service layer separation solves a different problem than OOP. It doesn't replace it. Services and containers bring features and capabilities that OOP doesn't provide. It's orthogonal.
But I think that's really the point: it gets applied to problems it was clearly not meant to solve. The article doesn't really get into that, but that's how I'm reading it because I've seen it happen. To some programmers, every component of a program is its own service, even when there's no need to have multiple processes. The only tool they have is that hammer, so everything has to be a nail.