OOP is domain-specific in its applicability if you are following the original intent. If you are not strictly following the original intent of OOP, you can get the best of all known worlds if you apply strong discipline and your tools are capable enough.<p>For instance, in most OOP languages you can define your domain model as bags of facts without methods. Then, you could define a separate domain service layer that is exclusively permitted to mutate instances of those types. Next, you enforce immutability by defining a copy ctor for every type in your model. When you return anything to a caller from a domain service you always send a copy. Same idea on create/update requests. The way I look at it, the domain services (methods) protect the model (facts) from unwanted mutations.<p>Having your facts separate from your methods means you can apply things like normalization and start to leverage functional and/or relational techniques. Being able to query your domain model with SQL is next-level productivity if you can manage it.<p>So, the biggest mistake to me in computer science is not OOP, but the blind following of any one specific doctrine to an inevitable dead-end. Good software outcomes require an incredibly difficult balance between many ideologies, as well as conformance to actual realities presented by the real world (i.e. customer requirements, regulations, developers having bad moods, etc.).
A lot of powerful claims made in this article. Are we sure 737s crashed because of spaghetti code? As far as I am concerned the max crashes were due to a string of management failures pushing for wrong ideas.
This blog post seems to equate spaghetti code with OO, which is a false equivalency. I mean, yes, you can achieve spaghetti code with OO, but you can achieve some degree of spaghetti code in most paradigms.<p>It also seems to imply that OO has <i>cost lives</i>, specifically with the Boeing 737 Max MCAS system and Toyota's "unintended acceleration" problem. But I can't seem to find what language MCAS was written in (I'd wager C, Fortran, Ada, and possibly some assembly based on other Boeing systems I've been involved with). And Toyota was using C.
Lately I think that the React framework is the biggest mistake. It's worse than a pile of jQuery spaghetti.<p>It's probably single-handedly responsible for why Reddit, Twitter, and myriad modern popular sites are slower and buggier than ever. They are written in an un-debuggable framework...
People still focuses a lot on procedures, algorithms and paradigms and tend to forget the simplest most basic aspect of computer programming: it is a language before everything.<p>It needs structure, semantics and good abstractions, so that we can better encode programmer intention into procedures, and not only rely on algorithmic effects to tell whether a program works.<p>I believe the software community would be in way better shape if we approached computer science a little bit more like linguistics. We would understand each other better, we would integrate ideas easier and work more cooperatively. But until code stops being just a tool to implement some end and until code quality stops being regarded as cost we will keep writing spaghetti code. Regardless of language. Because when the team culture tolerates bad code, bad code will arise, be that in java, c, python, rust, Haskell. Whatever.
"Read the rest of this story with a free account."<p>No thanks.<p>But judging by the title, it seems click-baity. The "biggest mistake" is definitely not OOP. You can definitely abuse and misuse OOP, where other abstractions would be a better pick, but it's not just universally bad.
Go's minimalist object-oriented approach (interfaces, embedding types within types, and associating functions with named types) is small, simple, and effective<p>No mistake about it
What I miss from articles like this, which make some rather grand claims about how poor OOP is and how much better X is, is less claims and more proof.<p>I really enjoyed the rs-pbrt[1] project that was posted here[2] the other day, as it allowed me to compare some non-trivial code in a (to me) different and interesting language.<p>Does anyone have some good comparative examples for FP? Doesn't have to be as grand as rs-pbrt, but ideally something a bit realistic and non-trivial.<p>[1]: <a href="https://www.rs-pbrt.org/" rel="nofollow">https://www.rs-pbrt.org/</a><p>[2]: <a href="https://news.ycombinator.com/item?id=25812330" rel="nofollow">https://news.ycombinator.com/item?id=25812330</a>
OOP seems to force you to leave the entire codebase for that class open.<p>The member variables can be modified by the methods, which makes the variables a type of global variable, from the perspective of the method.<p>Then over time as your code size increases, you add more methods, and they keep modifying the member variables. Now, if you’re not careful, you can have multiple vectors modifying your member variables, any which way it wants.<p>Thus, when working with OOP, you can never seem to close out parts of the code that you had already completed and tested. Since the entire code base is opened for continual modifications.
If all you have is a hammer you will eventually come across things that are not nails, but close enough you try to approximate them as nails. As the abstracts get more and more leaky you get the "biggest mistakes". I don't think really it matters what it is, if you take it too far it will fall apart.<p>I think clearly this applies to functional programming as well, and probably every other way of thinking.<p>The issue with OOP is that it is taught, and for many programmers they think it is the only way to think so they try to make every problem a nail.
This is not a very good article.<p>OOP has a lot of flaws for why it was a poor design decision, but this article doesn’t seem to address them.<p>Instead, it focuses on things like spaghetti code.
Not going to enable javascript and/or pay money to read this very hot take, but I can definitely agree that OOP is terrible. And, furthermore, spelled backwards it is "POO".<p>Don't use Medium, please.