Hacker News Reader

Hacker News

Comment by cooljacob204 | Hacker News Reader

Full thread

cooljacob204

Who is this everyone?

Everyone I know loves OOP.

I am primarily a Ruby developer so I know I'm in a bit of a bubble but still... The title is pure click bait.

View on HN

I think it has become trendy on HN and r/programming to claim OOP is dead and no one has ever liked it.

In meatspace, everyone I know is fine with OOP. Usually it is other aspects of the programming languages that result in griping.

I think it's trendy now, in general but especially in tech, to generalize anything that anyone doesn't like as "everyone hates this". It's not a new tendency, but it feels like hyperbolic projection became the new normal in the last few years.

In general, I've noticed a trend in most communities I participate in that criticism is inherently negative. There's no view that you can be critical just understand something or see how to improve it, if you're critical you're attacking.

It's been trendy for about 10 years to love FP and hate on OOP.

I think it comes down to how you use it.

I have seen people write entire systems in DOS batch script. Was that a good idea? Not really. Can it be done? Oh very much so. But is that the fault that DOS batch script let you do that? Not really.

OOP is the same sort of thing. It is a tool. You can take the abstraction too far and make it miserable to use and extend. It depends on the team/person doing it. Perhaps they are fine with 'too far' the next poor soul to come in may not be able to keep up with the 13 layers of abstraction that they had no decision in. Where is that line? That is more art than CS as the rule is 'it depends'.

<- a loose associate of this "everyone" here. (10+ years exp, proficient in FP and OOP languages.) Primarily Scala dev now so I write code that's both functional and object oriented. I'd say my code leans more towards the functional side of things, favoring composition, type inheritance over class inheritance, separation of data structures from behavior that acts on data, and a reduction of shared state to the bare minimum. However when it comes to persisting state throughout a programs lifecycle then objects/actors become a great way of handling that data in an easy to reason about structure. They're great for encapsulating data after all.

Seeing code that goes all in on OOP absolutely makes me cringe as I know it generally means the unit tests are going to be more complex than they would be in an FP environment, the code's likely going to be harder to extend as there's no amount of class inheritance planning that can prepare you for all future business requirements, and in most cases it's just going to be so much more verbose than an FP solution would be (I know this last point is a bit of a personal issue).

Code that goes all in on FP I absolutely love on a pure nerd level, but absolutely hate on a practical level. Pure FP is neat in the same way that seeing someone who can calculate out pi to a hundred digits is neat. Sure it's impressive, but like... I got this calculator that will handle it much easier.

Exactly, while FP is a good addition in some cases, where is the "everyone" that hates OOP? OOP is still 1000x more widely used and loved than FP to say the least.

"Everyone" in this post is being defined as "Everyone in my extremely small tech bubble"

Part of the problem is that “OOP” is poorly defined and lends itself to no-true-Scotsman arguments. If you criticize OOP for its characteristic use of inheritance, people retreat to “true OOP is about message passing” or “true OOP is about encapsulation” and “inheritance has nothing to do with OOP”. Feel free to replace “inheritance” with any criticism of OOP, such as the gratuitous use of mutability relative to other paradigms or the remarkable popularity of gratuitously large object graphs (the “banana with a reference to the gorilla holding it with a reference to the entire jungle” problem). Everyone insists their own definition of OOP is the one true definition, but none of these purely theoretical definitions absent any of the faults typically attributed to OOP actually exist in the real world (or perhaps they do exist and we just call them “data oriented programming” and “functional programming”).

For a parallel in a totally different domain, see Umberto Eco's definition of fascism [0]. It is a list of 14 properties typical of fascism, but it is not necessary to actually possess them all to be considered fascist (and they're mutually contradictory).

The same thing happens with FP and OOP. Both are too broad to be defined concisely, and the definitions, when collected, are often contradictory or necessarily exclude what others would consider valid <paradigm> languages.

Any discussion about these paradigms and their relative merit or "goodness" has to be clear about which subset of OOP and FP properties are being discussed and compared.

An example: A popular view of many current FP proponents is the idea of immutability as a key requirement of FP. But this necessarily excludes Common Lisp, a multi-paradigm language with the ability to use many other FP ideas. Instead, CL would be included under FP (or include FP as one of its paradigms) by someone focusing on things like higher order functions, being able to construct functions at runtime via closures, etc.

The same can be used to understand OO. Message passing is a property of some OO systems. Inheritance and class hierarchies are a property of others, possibly overlapping with the first. Closely tying methods to classes (see Java) is another common property. But Java and Smalltalk are both considered OO and both contain ideas absent in the other. Which of those ideas are OO, which are ancillary. And which OO ideas are present in one but absent in the other, does it invalidate the other language as an OO language or does it just mean it has a different view of OO?

[0] https://en.wikipedia.org/wiki/Definitions_of_fascism#Umberto...

I find it's more helpful to think about these labels as regions in a continuous multidimensional space. One such dimension is im/mutability, and you have languages like Haskell that exist on an extreme of that continuum and then languages like Java which exist nearer an opposite extreme in which mutability is common, and languages like CL where mutability is permitted but relatively infrequent. Similarly, another dimension is the frequency of inheritance, another is the aggregate cleanness or spaghetti-ness of object graphs (I'm sure there's a mathematical term for this), and so on. CL permits some mutability, but it pretty clearly belongs to the cluster that we typically call FP, and while definitions for FP do label slightly different but largely overlapping regions in this multidimensional space, there is relatively little variance.

OOP on the other hand is very poorly defined. There is a tight little cluster of languages which are commonly called OOP, but the defining features of that cluster are generally negative so "OOP proponents" began arguing that while those languages are OOP, the things that unite them aren't actually defining characteristics of OOP. Advocating for other regions in this space for which to apply that label is problematic because they either exclude other traditionally-OO languages or the described region overlaps too much with the "functional" and "data-oriented" regions (one can retort, "per your definition, Haskell is also an OO language"). So in their loyalty to the term, "OOP" proponents instead make arguments about what doesn't define the language (note that not all proponents make all of these claims):

* OOP may or may not involve inheritance.

* OOP may or may not involve message passing.

* OOP may or may not involve a high degree of spaghettiness in object graphs

Ultimately they'd prefer the term be semantically useless than useful and negative.

Ironically, the only thing that unites all OOP advocates is a fondness for the term.

I do invite OOP proponents to prove me wrong by coming up with a common, semantically useful ("meaningful" in the formal sense of the term) definition that describes all traditionally-OO languages and generally excludes most data-oriented and functional languages.

Note that a common rebuttal is that you can write bad code in any language and with any paradigm, which ignores that the claims are about the frequency and not a binary proposition about whether or not the language precludes a particular anti-pattern. The extent to which a Java program doesn't exhibit the criticisms above is the extent to which that program is not OOP, and very probably data-oriented or functional in nature.

Nobody does OOP anymore, it's too mainstream.

I would consider myself to practice "data oriented design" rather than "object oriented design" but I still usually encapsulate things in objects after I've figure out the data flows. OOP is really a collection of ideas, some terrible, some great.

There is also a big difference if you're working mainly on the backend where you shouldn't keep any state or the frontend to how useful many OOP concepts are to you.

Reply on news.ycombinator.com