The author should read less propaganda, do not get too excited about just a tools, and not to try to use same hammer for every job. Suddenly he'll find out that each paradigm has its place along with pros and cons depending on situation.
I think we all agree though. OOP is, in practice used as a hammer for EVERY job when it is actually a tool best used for something extremely narrow.
Two of the most popular modern programming languages that just came out within the last decade eschew OOP all together: Golang and Rust.
A lot of people will argue about the semantics of OOP and whether golang or rust fits the paradigm in terms of the definition. Let's just make it simple. Whatever OOP methodology python, java or C++ is doing... golang and rust are not doing it.
>"OOP is, in practice used as a hammer for EVERY job"
It is NOT. If you're talking dumb developers it is their problem.
Golang is strictly corporate language with very defined goals and using it it as a hammer is just as dumb. Along with Golang Google using other languages just fine. For example they have huge pile of C++ which supports many paradigms, OOP including.
I do not understand these holy wars where everyone has to adopt "THE ONLY TRUE style, practice, language etc". I think this is really near sighted.
I am not using Rust at all so can say little how good it is "hammer wise"
>It is NOT. If you're talking dumb developers it is their problem.
It VERY MUCH IS. I am not talking about dumb developers. I am talking about basically every developer. The pattern is so ubiquitous that it's basically required knowledge. FP is NOT required knowledge.
>Golang is strictly corporate language with very defined goals and using it it as a hammer is just as dumb.
Golang was invented by Rob Pike who has THIS to say about OOP:
"object-oriented design is the roman numerals of computing"
So is golang a corporate language with very defined goals? Maybe from certain angles sure you can think of it that way. But Did Rob Pike not include OOP in the language because of this? No. From the quote, OOP was eschewed from golang because "it's the roman numerals of computing."
>I am not using Rust at all so can say little how good it is "hammer wise"
Rust shares largely the same story and philosophy as golang when judging the OOP pattern.
This is what your post reads like to me: you feel that pure FP is underappreciated and it hurts your feelings.
Me I hold no allegiance and frankly do not give a fuck about pure concepts / tools whatever they are. That includes OOP, FP, insert your favorite. I just use what lets me solve particular situation in a best (for me) way. And since aside of programming I also run business ROI is not the last in the list of my criteria.
I would say then you need to be more logical and rational and be less emotional. Because your statements are completely invalid. I'm just spitting facts but you took as an attack.
You are not unbiased, you hold allegiances and you don't realize it. I know this because you make incorrect assumptions and automatically take a defensive stance against an imaginary attack. I am presenting just facts.
I am a huge proponent of OOP for the right use cases. Read what I wrote... I never said otherwise. But you didn't know this because I'm able to say factual things while being a proponent.
This is what it means to be rational. Learn padawan.
>"I would say then you need to be more logical and rational and be less emotional."
Frankly I completely fail to see where am I being emotional. I thought you are. I guess having totally different cultural background plays a role here.
I come here mostly for entertainment and unless I read some story about horrific abuse of human I could not care less. Too bad if I make different impression.
>Frankly I completely fail to see where am I being emotional. I thought you are. I guess having totally different cultural background plays a role here.
How do you know we have a totally different cultural background when you don't even know my background?
It's obvious emotions play a role in your thinking because your conclusions are illogical. If your conclusions are not based on logic then they are based on emotion. Observe this quote:
>you feel that pure FP is underappreciated and it hurts your feelings.
How do you know what I feel? How do you know it hurts my feelings? You don't. I honestly don't care whether or not FP or OOP is popular. But I do think OOP is over used. That's it. The fact that you can (wrongly) assume something you have no information about displays how emotions are overruling your rational judgement.
>I come here mostly for entertainment and unless I read some story about horrific abuse of human I could not care less. Too bad if I make different impression.
What does this have to do with anything? When I tell someone to be more rational I'm not telling them to become a logical automaton or become a savant. You or most people attempting to do this is a form of lying to yourself. You're human and you feel emotions. That's that. What you can do is allow less emotions to influence your judgement and bias. That's all I'm suggesting.
>"How do you know we have a totally different cultural background when you don't even know my background?"
I can clearly see it from how we "understand" each other.
>"How do you know what I feel?"
In previous message I said literally: "This is what your post reads like to me". In my version of not native English it translates to: I do not really know how you feel but this is the impression I am getting.
As for the rest of your message - Have a nice day.
>I do not really know how you feel but this is the impression I am getting.
That's the problem. You get "impressions" and those impressions are inaccurate to a degree that is completely off base.
>I can clearly see it from how we "understand" each other.
More illogical thinking. Imagine this simple scenario: Two people from the same culture, misunderstanding each other. Is this scenario possible? Two people from the same culture CAN misunderstand each other. Just because you think I misunderstand you or you misunderstand me doesn't mean we're from a different culture.
Please be more rational.
>As for the rest of your message - Have a nice day.
Nah. You're lying. You're just pretending to be above it all. Typical. You don't want me to have a nice day, in fact you dislike me. Just be plain honest about it. You dislike my opinions and you took emotional offense to me stating the truth about your character.
Update: The way I figured this out is that I mod a subreddit called OOP Is Bad. I usually jump the gun on new articles, and then I have to roll back my posts when I realize they're duplicates. Anyway if you want to read up on the subject, you could do worse. http://reddit.com/r/oopisbad
Grain of salt, author is a student (edit: apparently it’s just plagiarized) just learning of these things. OOP is not inherently good or bad, it’s just one tool in a toolbox. Yes, it’s more of a pain in the ass to write, but is much easier for a large, distributed team to maintain and improve upon.
OOP isn't perfect, it is just the least imperfect among alternatives. Something better will come along, but FP ain't it. Because OOP maps well to how humans think, "something better" is going to be refinements of OOP as opposed to total replacement of it.
If you do OOP how "humans think", then you are likely doing it wrong. This is why OOD produced by both novice and intermediate experienced devs tends to suck, moreso than other programming paradigms.
All humans don't think alike though do they? I'd sum up my unintentional journey from OO to FP as the realization that I'm not smart enough to do non-FP. Not saying OO is "wrong", but that maybe it maps better to your mental model than it does mine.
I can easily jump into a more functional oriented codebase and reason about functions with clear input/output and no side-effects. The realtime REPL compiler in my brain can track the private state of functions. And while not all functions can be 'pure', most can be. With OO? Forget about it. Side-effects everywhere, that often aren't obvious when you are new to a codebase.
And when I say "new" I mean it as in "not currently very familiar with". Which includes code I had written myself - years ago - that I have to relearn.
This article is not really worth reading if you've read any criticism of object-oriented programming from the last 3 decades. Except maybe the reference problem related to encapsulation -- that's just wrong.
I really don't have these kinds of problems; it's likely due to experience. It's not that I don't use inheritance, encapsulation, polymorphism, etc. I do. And when I do, it works exactly as it's supposed to. I don't over-use it, I don't use it when it's not appropriate. This is the same with functional concepts as well.
Object-oriented programming is the most successful programming paradigm in history. But you don't get to the front page of hacker news with that information.
>Object-oriented programming is the most successful programming paradigm in history
No it's not. Likely the most popular paradigm. Not the most successful. It's like saying Null is the most successful concept in all of computer science.
Object-oriented concepts are everywhere, even in software products like the Linux kernel, that don't use an object-oriented language. I'd go so far as to argue that 99.999% of all software is object-oriented (and I'm probably missing a few nines).
But you're just saying that's merely popular and not successful? That seems extremely flippant.
I'm not saying OOP is popular, I'm saying it's successful.
You're not making an argument against that at all. You're saying it's popular (not what I'm saying) and bad things can be popular. So what! Good things can also be popular. In fact, good things are often popular.
>I'm not saying OOP is popular, I'm saying it's successful.You're not making an argument against that at all.
No. No. I am NOT making an argument saying is OOP is NOT Successful. I never Made such an argument EVER.
What I am saying is that your argument is completely Invalid. I am saying you can make no such argument for OOP being successful. Big difference. I make no argument on anything other than saying your argument CANNOT be made with your given evidence.
The evidence you present only supports OOP's popularity. Not it's success. Unless you count popularity as success. The argument can still be made that for every application of OOP on ANY project a better non-OOP solution could have been made. This is a possibility. My post only opens this as a possibility and dismisses your post as the absolute truth.
The flaw in your argument is that those non-OOP solutions were not made. They don't exist. The idea that some other programming paradigm is more successful based on products that don't exist is ridiculous.
Many people in the singular are brilliant. You are hand-waving away the fact that the most highly experienced and skilled developers in the world, have in the majority, chosen to develop their software using object-oriented programming. And that software is what we use the most every day.
Tons of smart people vote for trump (Peter Thiel for example). I mean you get what I'm saying. Just because some smart people use it doesn't mean it's right. Just because something is popular doesn't mean it's a success.
A mathematical proof that OOP programs are more modular and less complex then procedural or functional programs.
We are in the realm of logic and idealized language primitives. Thus things can be proven via logic. Science, statistics and other data driven methods are weaker wherever something can be proven via logic. So while popularity doesn't even serve to slightly support the hypothesis of success, even if it did, a logical proof is superior and makes the conclusion definitive.
If such a thing is discovered it is definitive. It will destroy all arguments against OOP.
Until then the next best thing is examples. Given an OOP program, give the FP or imperative equivalent. Prove the OOP program is definitively better for the one single case.
Completely misses the human element though. I spend a significant amount of effort in programming ensuring that the code is readable to humans. Why? Because humans are the most important part -- they're both the creators and the reason why we do it.
You can create the most mathematically perfect paradigm/language but if it's brutal nobody will use it. Is that success? I don't think so.
The biggest issue in software development is the sheer size of it all. How do we build software that literally requires dozens, hundreds, maybe thousands of developers all working on the same thing?
I have evidence in the success of OOP in solving that problem in the form of all the software that exists and works. The proof is literally out there, everywhere. Your measure of success isn't even theoretical, it's an unproven (maybe unprovable) hypothesis. My measure of success is the practical. You can completely disregard that as "popularity" but to what end?
That's the point. The entire programming world moves in circles reinventing the wheel and repeating the same mistakes every decade or so. Humans are biased. We need definitive answers.
>You can create the most mathematically perfect paradigm/language but if it's brutal nobody will use it. Is that success? I don't think so.
No I never said this. All I said was PROVE OOP is BETTER than other paradigms in terms of modularity and complexity. I never said design a perfect mathematical language from scratch. In fact, in mathematics, the concept of perfect doesn't exist. A language is just a language, it's not better or more perfect than any other language.
>The biggest issue in software development is the sheer size of it all. How do we build software that literally requires dozens, hundreds, maybe thousands of developers all working on the same thing?
I don't know where you're going with this. The argument is whether OOP is a good paradigm and an easy way to prove this is to either mathematically prove it's better than all other paradigms or give examples on how it's better. Give me singular examples where OOP is superior and that lends credence to your argument. How does saying that software development is "huge" with "thousands of developers" working on it mean anything at all? It doesn't. It strays from the main point.
>I have evidence in the success of OOP in solving that problem in the form of all the software that exists and works
OOP and FP are both turing complete. That means Every OOP program has an FP and imperative counterpart. In addition to this many Non-OOP software solutions exist in the real world. Linux for example is NOT OOP.
Thus for both OOP and FP and imperative. Mathematical Proof EXISTS that it works. Statistical evidence through existing software also adds to that proof. The argument is WHICH is better? That's all we disagree on right now. Which Paradigm is superior and in what area?
> You can completely disregard that as "popularity" but to what end?
I can completely disregard it because in many areas it has been shown to be completely unreliable, illogical and contradictory. This is statistically valid. For example religion. Thousands of religions are popular in this world. All of them are declared as the absolute truth, all of them are contradictory.
Why are you continuously using a metric that has ACTUALLY been disproved to be reliable as your bar? The popularity of OOP ONLY shows that it works. It does not show that it is BETTER.
You keep moving the goal posts. I never said better, I said most successful. If you want to say better, then you need to say better "for what".
> OOP and FP are both turing complete. That means Every OOP program has an FP and imperative counterpart. In addition to this many Non-OOP software solutions exist in the real world. Linux for example is NOT OOP.
Right so there could be non-OOP counterparts to the overabundance of OOP applications but they don't exist. You argue that everyone in the world is an idiot and you're the one sane person -- think about that.
>You keep moving the goal posts. I never said better, I said most successful.
If something was the "most successful" then by definition it would be "better" then everything else including FP and imperative. No goal post was moved.
>Right so there could be non-OOP counterparts to the overabundance of OOP applications but they don't exist.
They do. Linux was one example. Whatsapp is another example. They exist. I'm not sure why your dismissing them. Sure the majority is OOP but again that doesn't mean anything.
>You argue that everyone in the world is an idiot and you're the one sane person -- think about that.
I never said that. Think about that. I said popularity is not proof it's better. I never said they were idiots, and I never said they are wrong. I am simply saying something being popular doesn't mean it's successful. It doesn't determine anything. A popular thing could be successful it could not be successful and popularity is a bad foundation for arguments.
Additionally you just need to look at the world and contradictory religious practices leading to jihads, crusades and suicide bombings to question the veracity of "popularity."
>Linux has plenty of OOP design patterns.
Sure isomorphism to patterns exist in FP to OOP to imperative. You'll find connections and similarities between patterns of EVERY paradigm. Doesn't change the overall fact that Linux overall is NOT OOP.
You think just because map and reduce exist as methods in java makes it a functional language? No. The overall point of the language and design decision is what matters here. Linux is NOT OOP.
I've proved to you with examples over and over again that majority and popularity aren't good metrics.
A huge portion of the world is muslim, a huge portion of the world is christian and another huge portion of the world is Buddhist and another portion of the world is atheist.
Only one of them can be right. Therefore the MAJORITY is WRONG.
The example above is already definitive proof that POPULARITY and MAJORITY cannot be used as an accurate metric given most of the worlds beliefs are completely OFF BASE.
Yet here you are endlessly parading majority and popularity as the best metric and stating that if I claim otherwise I'm believing the world is flat. Try to be logical.
If your goal is to convince me (which I assume is the case given that you ARE responding to me) then you need to stop using popularity as a metric. By giving one instance where popularity is inaccurate I have ALREADY shown that it is not a valid metric and useless in your endeavor to convince me.
If your goal isn't to convince me then I question the rationality behind why you're even communicating with me? Is it possible that you're just defending your own beliefs?
One religion, right or wrong, could be more successful based on whatever metric is used for success.
In my case, success for a programming paradigm is a large number of successful projects that use it. Note, this says nothing about opinions. It's a measure of facts. The fact is that there are more successful OOP projects than any other by a inescapably huge margin.
You can argue that everyone is misguided and the whole thing is wrong but that's something else entirely. It doesn't change the fact of that success. If Buddhism being wrong, whatever that might mean, wouldn't change the fact of it's success based on how that is defined. God forbid that the measure of success is enlightenment -- your head might explode.
>One religion, right or wrong, could be more successful based on whatever metric is used for success.
The metric that I was referring to is truth. Only one can be true, or None. Either way the majority of religions are False no matter the outcome.
>In my case, success for a programming paradigm is a large number of successful projects that use it.
Oh yeah define the success case to be exactly the evidence. Clearly we're talking about something more nuanced here. If for example all possibly projects were executed in FP or OOP which version would be more modular, save time and be less complicated... I mean this is obvious. You're taking things in stupid direction.
>If Buddhism being wrong, whatever that might mean, wouldn't change the fact of it's success based on how that is defined. God forbid that the measure of success is enlightenment -- your head might explode.
> If for example all possibly projects were executed in FP or OOP which version would be more modular, save time and be less complicated...
The problem is you want to ignore facts -- the unbelievable success of OOP -- so you can concentrate on the theoretical. There's nothing stupid about pointing out that OOP is basically the most successful programming paradigm in history. Most of these paradigms were invented all the around the same time and yet one as overwhelmingly won the hearts and minds of the majority of developers. You still are saying nothing.
As for off topic, when your argument consists of comparisons to religion, Trump voters, etc that's about a lazy as you can get.
No facts were ignored. I addressed your facts with reasons why your evidence cannot be used to support your conclusion.
To prove your point you must disprove my reasoning. But all your doing is reiterating your point. Yes I know you think popularity is valid, but I already told you why I think it's invalid. To convince me you have to attack my reasoning. Look I'm teaching you how to debate.
>As for off topic, when your argument consists of comparisons to religion, Trump voters, etc that's about a lazy as you can get.
Those are called examples to help illustrate my point. They are not off topic. Your little Segway into enlightenment and Buddhism is completely off topic.
Success (in this instance) requires Popularity but Popularity does not imply Success.
You keep attacking popularity but that doesn't affect success at all. Do you take umbrage with the idea that many working and wonderful products is success?
You are making up an alternative definition of success, which is untestable, and then claiming OOP is not successful based on that. But you haven't disproved that my idea of success is invalid. You keep attacking popularity.
>You're making a very basic mistake of logic.
>Success (in this instance) requires Popularity but Popularity does not imply Success.
How is your statement logical? Who says success requires popularity? In what universe does that make sense?
A heart transplant was successfully completed recently. The man survived with no immune rejections. The heart came from a genetically modified pig spliced with genes to prevent rejection and stop growth after transplantation.
First time it occurred. It is a "successful" transplantation and BY DEFINITION since it only happened on one person in the whole of human history... NOT POPULAR. So if this "successful" event happened in the reality we live in... it means that things can be successful and NOT POPULAR at the same time.
"Not Logical"... Come on man.
>You are making up an alternative definition of success, which is untestable,
No I'm using the definition of successful in terms of the English language. Look it up in the dictionary to see if it contains the word "popular."
>But you haven't disproved that my idea of success is invalid. You keep attacking popularity.
My point isn't too prove anything. All I am saying and I repeat for like the hundredth time that you're statements have no logical basis. That's it. You claim is INVALID.
Here's an example that you can probably understand. If you enter a password into a system... I tell you the password is INVALID. I said nothing else. I didn't say no password exists, I didn't say a password does exist. I said NOTHING other than your password (aka claim) is INVALID.
> Who says success requires popularity? In what universe does that make sense?
For a programming paradigm, it's required. A programming paradigm that is not used by many programmers is not successful paradigm. It's a failure or it hasn't succeeded yet.
>For a programming paradigm, it's required. A programming paradigm that is not used by many programmers is not successful paradigm. It's a failure or it hasn't succeeded yet.
No it's not that's just a made up assumption by you. Nix and BSD are currently not popular. Even linux at one point was not popular. There are thousands and thousands of examples in software where the technology isn't popular but very successful on every other metric. There are opposite examples where the technology is popular but pretty unsuccessful in every other metric.
* Functional programming which doesn't handle null well
Null itself is efficient. It has hardware/OS support and is literally zero overhead. It fails fast so you don't see nonsense like "undefined" columns or bad data in your database.
When null fails in a good language you usually get a stack directly to your problem. You have one concept to follow through the code instead of multiple concepts.
I'm not here to convince you. I'm a fan of OOP and you obviously won't agree with me on either. But claiming "all" or even most without data to back it means you live in a bubble.
First off you don't know what you're talking about. The inventor of the concept of Null has this to say about Null:
"I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."
The attack on null stems from Tony Hoare the inventor hating on null. It also stems from programmers who know what they're talking about.
>Null itself is efficient. It has hardware/OS support and is literally zero overhead.
On x86-64, the general registers are simply bits that are mostly interpreted as integer values. They do not have additional states such as “null” in the sense of “not currently holding a value”. (Some architectures do have such additional states, and the floating-point registers in IA-32 can have such a state.) Unless the OS exposes it's own custom ISA (which they don't) then this is NOT an OS concept either.
>When null fails in a good language you usually get a stack directly to your problem. You have one concept to follow through the code instead of multiple concepts.
The argument against null stems from the fact that the failure wouldn't even exist in the first place if null didn't exist period. The language itself should statically handle undefined concepts via types. By moving all runtime errors to compile time errors you eliminate the need of even looking at the stack. Possibly the most extreme example of this is elm. It is not possible for the elm language to have ANY runtime errors. All errors that are otherwise runtime errors in C or C++ are caught as compiler errors in elm.
>I'm not here to convince you. I'm a fan of OOP and you obviously won't agree with me on either.
I'm not a fan of OOP or FP. I'm an unbiased observer. The argument your making here is not either OOP or FP. It's part of mathematics. Type theory. I have a type called int. Why do I have this entity called Null within the type that fails even though everything type checks? It's a violation of the type contract. Your argument is saying the violation is ok for practical purposes. I'm saying it's not.
> But claiming "all" or even most without data to back it means you live in a bubble.
All programmers know how to sort a list. Do I need data to back up that statement? Perhaps I'm wrong. There are programmers out there who don't know how to do this. I thought null being bad was as obvious as sorting a list. Guess there's one person out there who doesn't know it's bad. It's unreasonable for me to get "data" on a If you want data, the quote from the inventor of null is the best possible one.
> Object-oriented programming is the most successful programming paradigm in history.
I don't think it is. The vast majority of code is imperative, with sometimes classes here and there, and these days with sometimes higher-order functions here and there, and with sometimes declarative programming (SQL and stuff like that). But the core is imperative code.
Imperative code is the basis for almost everything -- whether it be OOP or functional or big ball of mud. It's not a significant distinction for this discussion.
It is actually, and it is not the basis for almost everything. Functional code is usually declarative instead of being imperative. SQL is declarative, not imperative. The vast majority of the code written is imperative. It uses "if" instead of polymorphism for example, it doesn't rely on message passing or encapsulation or anything like that. You can't just ignore a paradigm and say that the second one is the most used.
>Imperative code is the basis for almost everything -- whether it be OOP or functional or big ball of mud
Wrong. Imperative is NOT functional. You cannot have both functional and imperative. They are literally opposites.
You CAN technically have both functional and OOP. However removing mutation from OOP removes the concept of setters and many associated "Design patterns" that are part of OOP.... so it's like removing the ignition from all car engines and still saying that the car is a car.
Many people don't understand what functional programming really is. Allow me to elucidate. Whatever program you can write on a single expression. That is a functional statement. If you write multiple functional statements... the code becomes imperative.
A functional program is an imperative program with ONE expression total. To write a functional program is to place your entire program ON ONE line. That's what functional is.
Now you may have heard that all you need to do is make everything in an imperative immutable for the program to be "functional." This is true. Turns out an immutable imperative program is isomorphic to a functional program. See this:
A = 2 + 2
C = A + 4 (immutable + imperative)
is equivalent to:
C = 2 + 2 + 4 (functional)
However if you add mutation the isomorphism is lost.
A = 2 + 2
C = A + 4
A = 3
You can no longer do the substitution above. Because of this isomorphism; to have any real linguistic meaning and differences between the words "functional" and "imperative" means that imperative programs MUST include reassignment. You can reassign a new value to an old variable in imperative programming and such a concept is literally impossible in a functional program because functional programs are just one line expressions.
in FP all variable names are simply aliases or macro shortcut expansions. In imperative programs variables are mutating entities.
I've been thinking about this a lot lately, and my current view of the world is that inheritance as a way of implementing code reuse leads to poor mental models and practices.
A better approach is probably to implement the code reuse model as an implementation of a public interface, which the subclass then implements and delegates. The cause of the brittle base class problem is likely that the interface between the base class and the subclasses is often not defined very well so it tends to not get engineered very well, and then external code can depend upon the implementation of the base class creating the brittleness.
So instead of having Banana and Orange that inhert from Fruit and having a container like a List<Fruit> if you use composition instead you get Banana and Orange that implement IFruit through delegating to Fruit and your containers are List<IFruit>'s now (you can't see the details of how Banana and Orange implement IFruit they just promise to implement it). You are now free to create FruitV2 which is a snazzy new implementation of IFruit, and you can inject it into Banana and Orange without breaking anyone who depends upon IFruit. It also becomes more apparent when you are making breaking changes because you wind up editing IFruit. You can also use DI or a DI Container (if you must) to control injection of behavior into objects.
And really inheritance is just delegation to another class dressed up and made simple to use. It is the exposure of that base class publicly and without good interface design that makes it bad.
Implicit in what I just wrong there though is that encapsulation is a very good thing and you should only depend on interfaces. I don't know why the author argues that encapsulation is bad. I've lived in the ruby land for 10 years with no encapsulation and in the long run it is literally fucking horrible since anything can have been accessed by some user somewhere with tools like `send()` and any change can potentially be breaking, and users will whine about SemVer even though you certainly never documented what they were doing and would have yelled loudly at them for attempting it if you'd ever known. Fences and neighbors and the tragedy of the commons and all that....
Very good critique but from beginner perspective. Even back in the pre-Java days Uncle Bob and Scott Meyers taught us how to deal with these issues to some degree.
The other thing most OO practitioners quickly realize: real world things often don't make good object hierarchies or even classes.
OO has not delivered on its promise to partition large scale problem domains effectively, especially for statically typed languages, but maybe in the age of webapps and microservices it doesn't matter as much. The problems we struggled with in the 90s are not as relevant today.
OOP is just a tool within a toolbox. You need to know how to use that tool.
I'm tired of reading this cookie cutter opinion. Can we go deeper?
I want to discuss why someone like linus hates C++. The extremities of these opinions are what's worth discussing here because we all can easily get behind the whole "Apples and Oranges" argument. The extreme arguments are the ones that are harder and more interesting. It takes more depth and understanding to develop an opinion beyond the cookie cutter one we see everywhere.
Do you love OOP and think it's better than FP and Procedural programming? Or vice versa? I want to hear your opinion.
> I want to discuss why someone like linus hates C++.
Personally reading some of Linus's complaints about C++ seem a little misplaced. And yet, I don't disagree with him either. He says C++ is a terrible language and it's really hard to disagree with that -- not because it's object-oriented but because it's C++.
When I was taught C, we were taught to carefully separate things to avoid trouble. If you're building a linked-list library, you don't export the struct definition you use abstract data type. You prefix your function names to make a namespace. The Linux kernel uses vtables in C to implement polymorphism for various drivers (e.g. different file systems with the same interface). OOP makes these things explicit.
> Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
The problem with dogmatic OOP is that it mixes data structures and code into one. This leads to hard to modify code, unexpected side effects, poor parallelism. Imperative or FP code does the minimum to define what the data should be shaped like and then has a bunch of functions that either modify it or do some IO with it.
That's a lot easier to trace through and reason about. That in turn leads to more malleable code, which lets you evolve it faster as your understanding of the problem domain evolves.
62 comments
[ 3.0 ms ] story [ 123 ms ] threadTwo of the most popular modern programming languages that just came out within the last decade eschew OOP all together: Golang and Rust.
A lot of people will argue about the semantics of OOP and whether golang or rust fits the paradigm in terms of the definition. Let's just make it simple. Whatever OOP methodology python, java or C++ is doing... golang and rust are not doing it.
It is NOT. If you're talking dumb developers it is their problem.
Golang is strictly corporate language with very defined goals and using it it as a hammer is just as dumb. Along with Golang Google using other languages just fine. For example they have huge pile of C++ which supports many paradigms, OOP including.
I do not understand these holy wars where everyone has to adopt "THE ONLY TRUE style, practice, language etc". I think this is really near sighted.
I am not using Rust at all so can say little how good it is "hammer wise"
It VERY MUCH IS. I am not talking about dumb developers. I am talking about basically every developer. The pattern is so ubiquitous that it's basically required knowledge. FP is NOT required knowledge.
>Golang is strictly corporate language with very defined goals and using it it as a hammer is just as dumb.
Golang was invented by Rob Pike who has THIS to say about OOP:
So is golang a corporate language with very defined goals? Maybe from certain angles sure you can think of it that way. But Did Rob Pike not include OOP in the language because of this? No. From the quote, OOP was eschewed from golang because "it's the roman numerals of computing.">I am not using Rust at all so can say little how good it is "hammer wise"
Rust shares largely the same story and philosophy as golang when judging the OOP pattern.
Me I hold no allegiance and frankly do not give a fuck about pure concepts / tools whatever they are. That includes OOP, FP, insert your favorite. I just use what lets me solve particular situation in a best (for me) way. And since aside of programming I also run business ROI is not the last in the list of my criteria.
You are not unbiased, you hold allegiances and you don't realize it. I know this because you make incorrect assumptions and automatically take a defensive stance against an imaginary attack. I am presenting just facts.
I am a huge proponent of OOP for the right use cases. Read what I wrote... I never said otherwise. But you didn't know this because I'm able to say factual things while being a proponent.
This is what it means to be rational. Learn padawan.
Frankly I completely fail to see where am I being emotional. I thought you are. I guess having totally different cultural background plays a role here.
I come here mostly for entertainment and unless I read some story about horrific abuse of human I could not care less. Too bad if I make different impression.
>"Learn padawan"
Sure master.
How do you know we have a totally different cultural background when you don't even know my background?
It's obvious emotions play a role in your thinking because your conclusions are illogical. If your conclusions are not based on logic then they are based on emotion. Observe this quote:
>you feel that pure FP is underappreciated and it hurts your feelings.
How do you know what I feel? How do you know it hurts my feelings? You don't. I honestly don't care whether or not FP or OOP is popular. But I do think OOP is over used. That's it. The fact that you can (wrongly) assume something you have no information about displays how emotions are overruling your rational judgement.
>I come here mostly for entertainment and unless I read some story about horrific abuse of human I could not care less. Too bad if I make different impression.
What does this have to do with anything? When I tell someone to be more rational I'm not telling them to become a logical automaton or become a savant. You or most people attempting to do this is a form of lying to yourself. You're human and you feel emotions. That's that. What you can do is allow less emotions to influence your judgement and bias. That's all I'm suggesting.
I can clearly see it from how we "understand" each other.
>"How do you know what I feel?"
In previous message I said literally: "This is what your post reads like to me". In my version of not native English it translates to: I do not really know how you feel but this is the impression I am getting.
As for the rest of your message - Have a nice day.
That's the problem. You get "impressions" and those impressions are inaccurate to a degree that is completely off base.
>I can clearly see it from how we "understand" each other.
More illogical thinking. Imagine this simple scenario: Two people from the same culture, misunderstanding each other. Is this scenario possible? Two people from the same culture CAN misunderstand each other. Just because you think I misunderstand you or you misunderstand me doesn't mean we're from a different culture.
Please be more rational.
>As for the rest of your message - Have a nice day.
Nah. You're lying. You're just pretending to be above it all. Typical. You don't want me to have a nice day, in fact you dislike me. Just be plain honest about it. You dislike my opinions and you took emotional offense to me stating the truth about your character.
Update: The way I figured this out is that I mod a subreddit called OOP Is Bad. I usually jump the gun on new articles, and then I have to roll back my posts when I realize they're duplicates. Anyway if you want to read up on the subject, you could do worse. http://reddit.com/r/oopisbad
Thank you for letting me know, and apologize for sharing it
https://cscalfani.medium.com/goodbye-object-oriented-program...
I certainly don't use OOP or FP. I write it as a list of procedures.
From this common use case we can know that Procedural programming is the default way humans think.
I can easily jump into a more functional oriented codebase and reason about functions with clear input/output and no side-effects. The realtime REPL compiler in my brain can track the private state of functions. And while not all functions can be 'pure', most can be. With OO? Forget about it. Side-effects everywhere, that often aren't obvious when you are new to a codebase.
And when I say "new" I mean it as in "not currently very familiar with". Which includes code I had written myself - years ago - that I have to relearn.
I really don't have these kinds of problems; it's likely due to experience. It's not that I don't use inheritance, encapsulation, polymorphism, etc. I do. And when I do, it works exactly as it's supposed to. I don't over-use it, I don't use it when it's not appropriate. This is the same with functional concepts as well.
Object-oriented programming is the most successful programming paradigm in history. But you don't get to the front page of hacker news with that information.
No it's not. Likely the most popular paradigm. Not the most successful. It's like saying Null is the most successful concept in all of computer science.
But you're just saying that's merely popular and not successful? That seems extremely flippant.
See: https://www.reddit.com/r/AskComputerScience/comments/bhgtzp/...
People in general are stupid. They get onto hype trains they develop biases and they vote for Trump and try to invade the Whitehouse.
Programmers are people. Hence why stupid concepts can propagate throughout the community.
(Not saying OOP is stupid, just saying that something being popular doesn't negate it from being placed in the stupid bucket.)
You're not making an argument against that at all. You're saying it's popular (not what I'm saying) and bad things can be popular. So what! Good things can also be popular. In fact, good things are often popular.
No. No. I am NOT making an argument saying is OOP is NOT Successful. I never Made such an argument EVER.
What I am saying is that your argument is completely Invalid. I am saying you can make no such argument for OOP being successful. Big difference. I make no argument on anything other than saying your argument CANNOT be made with your given evidence.
The evidence you present only supports OOP's popularity. Not it's success. Unless you count popularity as success. The argument can still be made that for every application of OOP on ANY project a better non-OOP solution could have been made. This is a possibility. My post only opens this as a possibility and dismisses your post as the absolute truth.
Many solutions are made without OOP.
Many people in the singular are brilliant. You are hand-waving away the fact that the most highly experienced and skilled developers in the world, have in the majority, chosen to develop their software using object-oriented programming. And that software is what we use the most every day.
Popular is bad.
Smart people use it, it's bad.
Billions of successful products making trillions of dollars, bad.
You've come to a conclusion and no amount of absolutely overwhelming evidence can convince you otherwise.
>You've come to a conclusion and no amount of absolutely overwhelming evidence can convince you otherwise.
I didn't come to a conclusion. All I am saying is YOUR conclusion has no basis. Popularity is not evidence for success.
We are in the realm of logic and idealized language primitives. Thus things can be proven via logic. Science, statistics and other data driven methods are weaker wherever something can be proven via logic. So while popularity doesn't even serve to slightly support the hypothesis of success, even if it did, a logical proof is superior and makes the conclusion definitive.
If such a thing is discovered it is definitive. It will destroy all arguments against OOP.
Until then the next best thing is examples. Given an OOP program, give the FP or imperative equivalent. Prove the OOP program is definitively better for the one single case.
You can create the most mathematically perfect paradigm/language but if it's brutal nobody will use it. Is that success? I don't think so.
The biggest issue in software development is the sheer size of it all. How do we build software that literally requires dozens, hundreds, maybe thousands of developers all working on the same thing?
I have evidence in the success of OOP in solving that problem in the form of all the software that exists and works. The proof is literally out there, everywhere. Your measure of success isn't even theoretical, it's an unproven (maybe unprovable) hypothesis. My measure of success is the practical. You can completely disregard that as "popularity" but to what end?
That's the point. The entire programming world moves in circles reinventing the wheel and repeating the same mistakes every decade or so. Humans are biased. We need definitive answers.
>You can create the most mathematically perfect paradigm/language but if it's brutal nobody will use it. Is that success? I don't think so.
No I never said this. All I said was PROVE OOP is BETTER than other paradigms in terms of modularity and complexity. I never said design a perfect mathematical language from scratch. In fact, in mathematics, the concept of perfect doesn't exist. A language is just a language, it's not better or more perfect than any other language.
>The biggest issue in software development is the sheer size of it all. How do we build software that literally requires dozens, hundreds, maybe thousands of developers all working on the same thing?
I don't know where you're going with this. The argument is whether OOP is a good paradigm and an easy way to prove this is to either mathematically prove it's better than all other paradigms or give examples on how it's better. Give me singular examples where OOP is superior and that lends credence to your argument. How does saying that software development is "huge" with "thousands of developers" working on it mean anything at all? It doesn't. It strays from the main point.
>I have evidence in the success of OOP in solving that problem in the form of all the software that exists and works
OOP and FP are both turing complete. That means Every OOP program has an FP and imperative counterpart. In addition to this many Non-OOP software solutions exist in the real world. Linux for example is NOT OOP.
Thus for both OOP and FP and imperative. Mathematical Proof EXISTS that it works. Statistical evidence through existing software also adds to that proof. The argument is WHICH is better? That's all we disagree on right now. Which Paradigm is superior and in what area?
> You can completely disregard that as "popularity" but to what end?
I can completely disregard it because in many areas it has been shown to be completely unreliable, illogical and contradictory. This is statistically valid. For example religion. Thousands of religions are popular in this world. All of them are declared as the absolute truth, all of them are contradictory.
Why are you continuously using a metric that has ACTUALLY been disproved to be reliable as your bar? The popularity of OOP ONLY shows that it works. It does not show that it is BETTER.
> OOP and FP are both turing complete. That means Every OOP program has an FP and imperative counterpart. In addition to this many Non-OOP software solutions exist in the real world. Linux for example is NOT OOP.
Right so there could be non-OOP counterparts to the overabundance of OOP applications but they don't exist. You argue that everyone in the world is an idiot and you're the one sane person -- think about that.
Linux has plenty of OOP design patterns.
https://lwn.net/Articles/444910/
https://lwn.net/Articles/446317/
If something was the "most successful" then by definition it would be "better" then everything else including FP and imperative. No goal post was moved.
>Right so there could be non-OOP counterparts to the overabundance of OOP applications but they don't exist.
They do. Linux was one example. Whatsapp is another example. They exist. I'm not sure why your dismissing them. Sure the majority is OOP but again that doesn't mean anything.
>You argue that everyone in the world is an idiot and you're the one sane person -- think about that.
I never said that. Think about that. I said popularity is not proof it's better. I never said they were idiots, and I never said they are wrong. I am simply saying something being popular doesn't mean it's successful. It doesn't determine anything. A popular thing could be successful it could not be successful and popularity is a bad foundation for arguments.
Additionally you just need to look at the world and contradictory religious practices leading to jihads, crusades and suicide bombings to question the veracity of "popularity."
>Linux has plenty of OOP design patterns.
Sure isomorphism to patterns exist in FP to OOP to imperative. You'll find connections and similarities between patterns of EVERY paradigm. Doesn't change the overall fact that Linux overall is NOT OOP.
You think just because map and reduce exist as methods in java makes it a functional language? No. The overall point of the language and design decision is what matters here. Linux is NOT OOP.
Of course they exist. And they are the exception. That's entirely the point.
> Sure the majority is OOP but again that doesn't mean anything.
Of course it does. Developers choose OOP and over and over again even after decades of failed attempts to unseat with supposedly better technologies.
To deny that is to claim the earth is flat.
> You think just because map and reduce exist as methods in java makes it a functional language?
No, but it certainly demonstrates the success of functional concepts even in an OOP language.
A huge portion of the world is muslim, a huge portion of the world is christian and another huge portion of the world is Buddhist and another portion of the world is atheist.
Only one of them can be right. Therefore the MAJORITY is WRONG.
The example above is already definitive proof that POPULARITY and MAJORITY cannot be used as an accurate metric given most of the worlds beliefs are completely OFF BASE.
Yet here you are endlessly parading majority and popularity as the best metric and stating that if I claim otherwise I'm believing the world is flat. Try to be logical.
If your goal is to convince me (which I assume is the case given that you ARE responding to me) then you need to stop using popularity as a metric. By giving one instance where popularity is inaccurate I have ALREADY shown that it is not a valid metric and useless in your endeavor to convince me.
If your goal isn't to convince me then I question the rationality behind why you're even communicating with me? Is it possible that you're just defending your own beliefs?
In my case, success for a programming paradigm is a large number of successful projects that use it. Note, this says nothing about opinions. It's a measure of facts. The fact is that there are more successful OOP projects than any other by a inescapably huge margin.
You can argue that everyone is misguided and the whole thing is wrong but that's something else entirely. It doesn't change the fact of that success. If Buddhism being wrong, whatever that might mean, wouldn't change the fact of it's success based on how that is defined. God forbid that the measure of success is enlightenment -- your head might explode.
The metric that I was referring to is truth. Only one can be true, or None. Either way the majority of religions are False no matter the outcome.
>In my case, success for a programming paradigm is a large number of successful projects that use it.
Oh yeah define the success case to be exactly the evidence. Clearly we're talking about something more nuanced here. If for example all possibly projects were executed in FP or OOP which version would be more modular, save time and be less complicated... I mean this is obvious. You're taking things in stupid direction.
>If Buddhism being wrong, whatever that might mean, wouldn't change the fact of it's success based on how that is defined. God forbid that the measure of success is enlightenment -- your head might explode.
Please stay on topic.
The problem is you want to ignore facts -- the unbelievable success of OOP -- so you can concentrate on the theoretical. There's nothing stupid about pointing out that OOP is basically the most successful programming paradigm in history. Most of these paradigms were invented all the around the same time and yet one as overwhelmingly won the hearts and minds of the majority of developers. You still are saying nothing.
As for off topic, when your argument consists of comparisons to religion, Trump voters, etc that's about a lazy as you can get.
To prove your point you must disprove my reasoning. But all your doing is reiterating your point. Yes I know you think popularity is valid, but I already told you why I think it's invalid. To convince me you have to attack my reasoning. Look I'm teaching you how to debate.
>As for off topic, when your argument consists of comparisons to religion, Trump voters, etc that's about a lazy as you can get.
Those are called examples to help illustrate my point. They are not off topic. Your little Segway into enlightenment and Buddhism is completely off topic.
Success (in this instance) requires Popularity but Popularity does not imply Success.
You keep attacking popularity but that doesn't affect success at all. Do you take umbrage with the idea that many working and wonderful products is success?
You are making up an alternative definition of success, which is untestable, and then claiming OOP is not successful based on that. But you haven't disproved that my idea of success is invalid. You keep attacking popularity.
How is your statement logical? Who says success requires popularity? In what universe does that make sense?
A heart transplant was successfully completed recently. The man survived with no immune rejections. The heart came from a genetically modified pig spliced with genes to prevent rejection and stop growth after transplantation.
First time it occurred. It is a "successful" transplantation and BY DEFINITION since it only happened on one person in the whole of human history... NOT POPULAR. So if this "successful" event happened in the reality we live in... it means that things can be successful and NOT POPULAR at the same time.
"Not Logical"... Come on man.
>You are making up an alternative definition of success, which is untestable,
No I'm using the definition of successful in terms of the English language. Look it up in the dictionary to see if it contains the word "popular."
>But you haven't disproved that my idea of success is invalid. You keep attacking popularity.
My point isn't too prove anything. All I am saying and I repeat for like the hundredth time that you're statements have no logical basis. That's it. You claim is INVALID.
Here's an example that you can probably understand. If you enter a password into a system... I tell you the password is INVALID. I said nothing else. I didn't say no password exists, I didn't say a password does exist. I said NOTHING other than your password (aka claim) is INVALID.
For a programming paradigm, it's required. A programming paradigm that is not used by many programmers is not successful paradigm. It's a failure or it hasn't succeeded yet.
No it's not that's just a made up assumption by you. Nix and BSD are currently not popular. Even linux at one point was not popular. There are thousands and thousands of examples in software where the technology isn't popular but very successful on every other metric. There are opposite examples where the technology is popular but pretty unsuccessful in every other metric.
The attack on null stems from:
* Bad implementations of null handling
* Functional programming which doesn't handle null well
Null itself is efficient. It has hardware/OS support and is literally zero overhead. It fails fast so you don't see nonsense like "undefined" columns or bad data in your database.
When null fails in a good language you usually get a stack directly to your problem. You have one concept to follow through the code instead of multiple concepts.
I'm not here to convince you. I'm a fan of OOP and you obviously won't agree with me on either. But claiming "all" or even most without data to back it means you live in a bubble.
First off you don't know what you're talking about. The inventor of the concept of Null has this to say about Null:
"I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."
The attack on null stems from Tony Hoare the inventor hating on null. It also stems from programmers who know what they're talking about.
>Null itself is efficient. It has hardware/OS support and is literally zero overhead.
On x86-64, the general registers are simply bits that are mostly interpreted as integer values. They do not have additional states such as “null” in the sense of “not currently holding a value”. (Some architectures do have such additional states, and the floating-point registers in IA-32 can have such a state.) Unless the OS exposes it's own custom ISA (which they don't) then this is NOT an OS concept either.
>When null fails in a good language you usually get a stack directly to your problem. You have one concept to follow through the code instead of multiple concepts.
The argument against null stems from the fact that the failure wouldn't even exist in the first place if null didn't exist period. The language itself should statically handle undefined concepts via types. By moving all runtime errors to compile time errors you eliminate the need of even looking at the stack. Possibly the most extreme example of this is elm. It is not possible for the elm language to have ANY runtime errors. All errors that are otherwise runtime errors in C or C++ are caught as compiler errors in elm.
>I'm not here to convince you. I'm a fan of OOP and you obviously won't agree with me on either.
I'm not a fan of OOP or FP. I'm an unbiased observer. The argument your making here is not either OOP or FP. It's part of mathematics. Type theory. I have a type called int. Why do I have this entity called Null within the type that fails even though everything type checks? It's a violation of the type contract. Your argument is saying the violation is ok for practical purposes. I'm saying it's not.
> But claiming "all" or even most without data to back it means you live in a bubble.
All programmers know how to sort a list. Do I need data to back up that statement? Perhaps I'm wrong. There are programmers out there who don't know how to do this. I thought null being bad was as obvious as sorting a list. Guess there's one person out there who doesn't know it's bad. It's unreasonable for me to get "data" on a If you want data, the quote from the inventor of null is the best possible one.
I don't think it is. The vast majority of code is imperative, with sometimes classes here and there, and these days with sometimes higher-order functions here and there, and with sometimes declarative programming (SQL and stuff like that). But the core is imperative code.
Wrong. Imperative is NOT functional. You cannot have both functional and imperative. They are literally opposites.
You CAN technically have both functional and OOP. However removing mutation from OOP removes the concept of setters and many associated "Design patterns" that are part of OOP.... so it's like removing the ignition from all car engines and still saying that the car is a car.
Many people don't understand what functional programming really is. Allow me to elucidate. Whatever program you can write on a single expression. That is a functional statement. If you write multiple functional statements... the code becomes imperative.
A functional program is an imperative program with ONE expression total. To write a functional program is to place your entire program ON ONE line. That's what functional is.
Now you may have heard that all you need to do is make everything in an imperative immutable for the program to be "functional." This is true. Turns out an immutable imperative program is isomorphic to a functional program. See this:
However if you add mutation the isomorphism is lost. You can no longer do the substitution above. Because of this isomorphism; to have any real linguistic meaning and differences between the words "functional" and "imperative" means that imperative programs MUST include reassignment. You can reassign a new value to an old variable in imperative programming and such a concept is literally impossible in a functional program because functional programs are just one line expressions.in FP all variable names are simply aliases or macro shortcut expansions. In imperative programs variables are mutating entities.
A better approach is probably to implement the code reuse model as an implementation of a public interface, which the subclass then implements and delegates. The cause of the brittle base class problem is likely that the interface between the base class and the subclasses is often not defined very well so it tends to not get engineered very well, and then external code can depend upon the implementation of the base class creating the brittleness.
So instead of having Banana and Orange that inhert from Fruit and having a container like a List<Fruit> if you use composition instead you get Banana and Orange that implement IFruit through delegating to Fruit and your containers are List<IFruit>'s now (you can't see the details of how Banana and Orange implement IFruit they just promise to implement it). You are now free to create FruitV2 which is a snazzy new implementation of IFruit, and you can inject it into Banana and Orange without breaking anyone who depends upon IFruit. It also becomes more apparent when you are making breaking changes because you wind up editing IFruit. You can also use DI or a DI Container (if you must) to control injection of behavior into objects.
And really inheritance is just delegation to another class dressed up and made simple to use. It is the exposure of that base class publicly and without good interface design that makes it bad.
Implicit in what I just wrong there though is that encapsulation is a very good thing and you should only depend on interfaces. I don't know why the author argues that encapsulation is bad. I've lived in the ruby land for 10 years with no encapsulation and in the long run it is literally fucking horrible since anything can have been accessed by some user somewhere with tools like `send()` and any change can potentially be breaking, and users will whine about SemVer even though you certainly never documented what they were doing and would have yelled loudly at them for attempting it if you'd ever known. Fences and neighbors and the tragedy of the commons and all that....
The other thing most OO practitioners quickly realize: real world things often don't make good object hierarchies or even classes.
OO has not delivered on its promise to partition large scale problem domains effectively, especially for statically typed languages, but maybe in the age of webapps and microservices it doesn't matter as much. The problems we struggled with in the 90s are not as relevant today.
I want to discuss why someone like linus hates C++. The extremities of these opinions are what's worth discussing here because we all can easily get behind the whole "Apples and Oranges" argument. The extreme arguments are the ones that are harder and more interesting. It takes more depth and understanding to develop an opinion beyond the cookie cutter one we see everywhere.
Do you love OOP and think it's better than FP and Procedural programming? Or vice versa? I want to hear your opinion.
Personally reading some of Linus's complaints about C++ seem a little misplaced. And yet, I don't disagree with him either. He says C++ is a terrible language and it's really hard to disagree with that -- not because it's object-oriented but because it's C++.
When I was taught C, we were taught to carefully separate things to avoid trouble. If you're building a linked-list library, you don't export the struct definition you use abstract data type. You prefix your function names to make a namespace. The Linux kernel uses vtables in C to implement polymorphism for various drivers (e.g. different file systems with the same interface). OOP makes these things explicit.
> Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
The problem with dogmatic OOP is that it mixes data structures and code into one. This leads to hard to modify code, unexpected side effects, poor parallelism. Imperative or FP code does the minimum to define what the data should be shaped like and then has a bunch of functions that either modify it or do some IO with it.
That's a lot easier to trace through and reason about. That in turn leads to more malleable code, which lets you evolve it faster as your understanding of the problem domain evolves.