Goodbye, Object Oriented Programming(blog.devgenius.io)
blog.devgenius.io
Goodbye, Object Oriented Programming
https://blog.devgenius.io/goodbye-object-oriented-programming-a08e1bd0b872?gi=fae95b4a4f21
50 comments
> 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.
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.
>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:
in FP all variable names are simply aliases or macro shortcut expansions. In imperative programs variables are mutating entities.
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)
A = 2 + 2
C = A + 4
A = 3
in FP all variable names are simply aliases or macro shortcut expansions. In imperative programs variables are mutating entities.
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.
>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.
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.
But you're just saying that's merely popular and not successful? That seems extremely flippant.
Null is more popular than OOP. It's also something all programmers can agree is a huge mistake. But this concept is replicated literally everywhere.
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.)
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.)
No. Null is great and has no good alternative.
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.
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.
> No. Null is great and has no good alternative.
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.
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'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.
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.
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.
Linux is not OOP. The react and redux pattern eschews OOP. (You can use OOP components but the overarching pattern is functional)
Many solutions are made without OOP.
Many solutions are made without OOP.
Like tobacco, sugar, whisky, and caffeine, brussel sprouts, cod liver oil, ...
> People in general are stupid.
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.
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.
What will take for you to see that earth is round?
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.
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.
The entire world produces green house gases which will ultimately end the human race doesn't mean it's good even though overwhelming people use it.
>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.
>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.
What is evidence for success then?
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.
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?
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?
>Completely misses the human element though
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.
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.
[deleted]
This link (to devgenius.io) is to a plagiarized copy of the original, which is here: https://medium.com/@cscalfani/goodbye-object-oriented-progra... .
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
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
Ho that's bad. I really didn't knew. I sent a message to DevGenius on twitter and they took the article down.
Thank you for letting me know, and apologize for sharing it
Thank you for letting me know, and apologize for sharing it
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....
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....
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.
[deleted]
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.
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.
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.
I have a set of tasks for someone to complete. How would I record those tasks on paper?
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 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.
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.
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.
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:
>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.
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"
>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.
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.
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.
>"Learn padawan"
Sure master.
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.
>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?
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 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.
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.
As mentioned in the article's comments, this appears to be an article by another author reposted wholesale without attribution:
https://cscalfani.medium.com/goodbye-object-oriented-program...
https://cscalfani.medium.com/goodbye-object-oriented-program...
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.
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.
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.
The standard reply by most people is:
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.
OOP is just a tool within a toolbox. You need to know how to use that tool.
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.
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.
Torvalds (I think):
> 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.
> 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.
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.