OOP is a crazy academic-esque idea that happened to stick because it works at scale. When you have hundreds of programmers working on a codebase, it's useful to constrain people with UML diagrams and rigid hierarchy. Otherwise, cowboy coders hack up something the other 90% of coders can't understand. This is why languages like Scala and Haskell haven't taken off outside of a few small-team-focused niches, like data science.
The Case Against OOP Is Wildly Overstated
131–140 of 312 posts
Re: The Case Against OOP Is Wildly Overstated
#132The author flatly says "do not use inheritance." Without inheritance and polymorphism, what is left in OOP? If you look at the author's 4 pillars, the only thing left is encapsulation (and "Oversimplified Hot Takes") It seems like the author himself has proven why OOP is bad. You can have encapsulation without OOP. People were doing it in C 40 years ago. And people are doing it in Go right now. No one would call Go a…
Yes, you could do encapsulation in C. You'd have a struct. But the problem is, any function in the whole program could modify the data in the struct, possibly placing it in an invalid state. When the struct wound up in an invalid state, you had to look at the entire program to find out who did it.
(C++ style) OOP encapsulation is different. Only member functions can modify the "struct" (object) data (unless you did something crazy like make your data members public). If the data is in an invalid state one of the member functions did it. Nobody else had the ability to do so. Your debugging got easier, because there's a much smaller set of places where the problem could be.
Now, true, you could do that in C, with the structure declared only in one C file (and no header file), and all functions declared file static except the "public interface". But C++ make that the normal way to work, not something that you had to go out of your way to do.
Inheritance: If you have a problem where it adds value, use it. It's a tool, not a religious dogma (either for or against). You could argue that most people, when they think they have a problem where inheritance adds value, are mistaken. You could even be right. But never use it? It's always the wrong choice? Get outta here. I'll use it when it helps - when the shape of the problem calls for it.
Re: The Case Against OOP Is Wildly Overstated
#133Earlier quoted context omitted.
But that is the tradeoff of ORMs. Black box with free stuff but more complexity. Sometimes (usually?) it does not make sense to use them.
Of course the biggest gain of ORMs is initial dev speed. If you're going to stand up a business in a week or a month, Django ORM and its migrations are going to get you a pretty darn good solution without spending hours and hours thinking about your RDB design and handling many-to-many relationships "by hand".
Yeah, why spend hours on the most important part of the application and likely the most important part of the business when you can gloss over with with an ORM and not worry about designing the database until it comes back to bite you in the ass when you can no longer grow your business because of the incredibly stupid thing you did which is not designing your database. Frankly, those businesses deserve to fail if this is the kind of idiocy that drives their decisions. But hey, we got the app going really quickly before going bankrupt.
Re: The Case Against OOP Is Wildly Overstated
#134Usually when I see people rant against OOP, they're not ranting in favor of FP (or even better, in favor of something like Scala that combines OOP and FP) but rather in favor of a return to procedural/top-down programming. There are very good reasons that procedural programming was abandoned a long time ago and the need for global variables to make it work is one of the big ones.
> There are very good reasons that procedural programming was abandoned a long time ago and the need for global variables to make it work is one of the big ones.
Procedural programming does not, at all, require global variables to make it work.
I'm not a big fan of procedural programming at scale because it almost always seems to assume mutability (by default) and shared state when dealing with concurrency, but let's set those aside.
You use structures to contain what a naive programmer (or a prototype) would use global state for. Instead of:
player_t current_turn; // a global
struct game_state {
player_t current_turn;
}
Re: The Case Against OOP Is Wildly Overstated
#135Earlier quoted context omitted.
I think the key differentiater is that OOP (in some versions) wants to hide the data and not just implementation details. For example, a hash map data structure hides the details of how the hash map is implemented, but it doesn't hide the data. In some versions of OO, the object should not only hide the implementation details but also the data. Any function that needs that data MUST be a method of that object. That's…
In what versions of OO does a hash map hide the data? The definition of a map requires that you can access the data.
'the data' is a vague concept. Usually, a hash map doesn't expose, for example, the bu met array, or the length of the bucket array. Sure, you can ask the hash map to give you the contents associated with a hash key, but you can't access the entire data structure that the hash map represents.
By contrast, in an 'extreme procedural' style, you would have a struct that is an array of buckets and an integer, and functions that can take such a struct and return information from some particular place inside it. In normal use you would just use the function, but if you're passing your hash map to someone else, there is no longer a guarantee that the length field still matches the actual buckets, or that objects are still arranged into buckets based on their hashes.
Re: The Case Against OOP Is Wildly Overstated
#136This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.
I was about to write exactly this. In 2014 I wrote an essay that has been discussed here on Hacker News several times [1]. When I re-read it now, parts of it seem very subtle, parts of it seem to be matters of opinion, but what jumps out is how really dangerous it is to tightly bind data with behavior, especially because this then leads to the problem of initiation (which I devote a lot of time to talking about in th…
I enjoy reading your takes, e.g the Case against Docker. It's good to have sane minds still around in the industry.
Re: The Case Against OOP Is Wildly Overstated
#137IMO, OOP just puts too many footguns at your disposal, the most dangerous one being mutability (how normal is it that our methods mutate instance variables?). The larger a system grows the more mutability will make it even harder to understand and control. It may be tolerable in small-scale embedded software, but outside of that we should make use of the better alternatives that modern hardware affords us.
This might be because almost all languages that support OOP are mutable, which goes all the way back to Smalltalk and CLOS, and becomes popularized with C++ and Java and then the dynamic languages like JS, Ruby and Python.
Re: The Case Against OOP Is Wildly Overstated
#138Person, Woman, Man, Camera, TV: The Class Hierarchy
Re: The Case Against OOP Is Wildly Overstated
#139This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.
Agreed. The biggest problem with OOPS lies in its original premise: that code and data should be the same thing! This is grevious error, IMHO, that leads to nothing but problems: endless boilerplate code, lots of "interfaces" that essentially do nothing (that couldn't be done directly with said data), and debugging nightmares. I much prefer to work with systems where code and data are separate and never the twain sha…
This reads like a rejection of von Neumann architectures. I don't think this is quite right.
Re: The Case Against OOP Is Wildly Overstated
#140OOP is a crazy academic-esque idea that happened to stick because it works at scale. When you have hundreds of programmers working on a codebase, it's useful to constrain people with UML diagrams and rigid hierarchy. Otherwise, cowboy coders hack up something the other 90% of coders can't understand. This is why languages like Scala and Haskell haven't taken off outside of a few small-team-focused niches, like data s…
In my opinion the "killer feature" of OOP at scale, more than hierarchy, it's compartmentalization of code.
Class hierarchies tend to have issues at scale, but OOP makes people agree on "where should we put this block of code" in a way that's "intuitive" and scales.