The Case Against OOP Is Wildly Overstated • Hacker News Board

Re: The Case Against OOP Is Wildly Overstated

#281

Post by wrsh07 » Sat, Aug 01, 2020, 2:25 PM UTC

GordonS wrote: post #274

wrsh07 wrote: post #179

Pretty good takes here in the comments (shout out to references to "pit of success") There are two things worth mentioning, though. 1) the best pragmatic programming recommendation is "semantic compression" by Muratori [1]. Incidentally, I find it to be an effective "takedown" of the sort of dogmatic oop that anyone criticizing oop is criticizing 2) Muratori might disagree with this, but for me the whole point of a n…

I enjoyed reading Muratori's blog post you linked to - it's interesting to read the thought processes of a dev who writes so well. But I don't get how "semantic compression" is any different from the more commonly termed DRY (Don't Repeat Yourself)?

I think DRY is a goal for the code and semantic compression (as described in the post) is a path towards that goal.

In Muratori's world they're following best practices like YAGNI and DRY and that allows you to refactor code at the right time

Re: The Case Against OOP Is Wildly Overstated

#282

Post by wrsh07 » Sat, Aug 01, 2020, 2:27 PM UTC

mrkeen wrote: post #227

wrsh07 wrote: post #179

Pretty good takes here in the comments (shout out to references to "pit of success") There are two things worth mentioning, though. 1) the best pragmatic programming recommendation is "semantic compression" by Muratori [1]. Incidentally, I find it to be an effective "takedown" of the sort of dogmatic oop that anyone criticizing oop is criticizing 2) Muratori might disagree with this, but for me the whole point of a n…

> If you need a new invariant, you make a new type. Agreed, but is that OO? From [2]: > Class invariants are established during construction and constantly maintained between calls to public methods. Code within functions may break invariants as long as the invariants are restored before a public function ends. That just sounds like a race condition with extra steps.

I think you can use OO effectively to define invariants. (You could also do this with FP!)

Beyond that, I'm not sure I understand your question.

Re: The Case Against OOP Is Wildly Overstated

#283

Post by ardacinar » Sat, Aug 01, 2020, 2:29 PM UTC

wvenable wrote: post #159

drummer wrote: post #111

OOP has served me well. It is a powerful concept. Problem is that people can misuse and abuse things.

It's the most successful programming paradigm in history. I feel like being anti-OOP is like being anti-vax. It's so successful and ubiquitous that it's success becomes invisible and so people only focus on the failures or misuse. Complaining about OOP requires an entire object-oriented software stack to post your argument.

Hacker news was written in Arc, which, AFAIK, explicitly has no object-oriented features.

Re: The Case Against OOP Is Wildly Overstated

#284

Post by hderms » Sat, Aug 01, 2020, 2:55 PM UTC

juniper_strong wrote: post #249

dionian wrote: post #43

Earlier quoted context omitted.

I don't see why the Law of Demeter cannot be adhered to in OOP. I do it every day.

Me too. I also violate it every day. Just this day I used System.out.println, for example.

Yeah imo law of demeter shouldn't apply for namespace organization of static, globally relevant functionality. The amount of dots in that case is irrelevant to me because it doesn't really imply changing context in the same way. more like drilling down in a phonebook than calling your neighbor and telling them to call Bob for you

Re: The Case Against OOP Is Wildly Overstated

#285

Post by creatonez » Sat, Aug 01, 2020, 3:01 PM UTC

lou1306 wrote: post #140

phendrenad2 wrote: post #131

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 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.

> OOP makes people agree on "where should we put this block of code" in a way that's "intuitive" and scales.

This is the opposite conclusion of Brian Will's Object-Oriented Programming is Bad video.

Since it forces you to think about everything as a real-world "object", OOP often leads to philosophical debates like

Should a Message send() itself?

Should a Sender send() Messages?

Should a Receiver receive() Messages?

Should a Connection transmit() Messages?

With more and more abstract OOP constructs with more and more interaction with the rest of the program, knowing where to put the relevant code becomes more and more difficult. FizzBuzzEnterpriseEdition[1], while it is satire, is quite similar to a lot of large Java codebases that have been through the wringer of alternating cycles of OOAD and code rot. Try to find the right bit of code to edit if you wanted to add a new feature to FizzBuzzEnterpriseEdition. Not very easy.

---

[1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Re: The Case Against OOP Is Wildly Overstated

#286

Post by School-Cotton » Sat, Aug 01, 2020, 3:10 PM UTC

hinkley wrote: post #188

zozbot234 wrote: post #105

Earlier quoted context omitted.

"Tightly binding data and code" allows you to maintain complex invariants via code, and to abstract away from the specifics of any single implementation. Statefulness per se is quite manageable; what's not manageable is shared, mutable state that isn't isolated to a single, modular, highly cohesive "unit" of code that can be understood in its totality. The real issues with OOP have to do precisely with things that br…

Not just invariants, covariants as well. State and zip code always change together. Having had to fix code that passed 5 variables around for an address (which needed to go to 6 for “address 2”) I replaced it with an address object.

You can have an address struct, and functions that manipulate it in controlled ways (like always updating the state when the ZIP changes), in every language, whether OOP or not.

Re: The Case Against OOP Is Wildly Overstated

#287

Post by winstonewert » Sat, Aug 01, 2020, 3:12 PM UTC

UnFleshedOne wrote: post #261

winstonewert wrote: post #155

Earlier quoted context omitted.

A hashmap wouldn't hide the data. But say, a Customer object might. A purist OO might insist that you shouldn't have a GetName() method because any code which needs the Customer's name should be method on Customer.

This particular example is probably a bad illustration, with all the recent rage about PII and privacy. In some cases (such as this) you want to make sure data doesn't leak all over the place and anything accessing it follows a strict path. Anybody modifying Customer object would hopefully be in the right mindset regarding personal information, but once it gets out as a string from GetName or GetEmail, all bets are o…

I'm having a hard time seeing how OOP style data hiding could be effective at controlling PII. Is this a method you've put into practice?

Re: The Case Against OOP Is Wildly Overstated

#288

Post by winstonewert » Sat, Aug 01, 2020, 3:15 PM UTC

garethjrowlands wrote: post #280

meheleventyone wrote: post #231

Earlier quoted context omitted.

But now you have a stale data problem.

Creating a new value only gives you a stale data problem if you had pointers to the old value. You don't have to have pointers like that, it's a choice. To take an obvious example, you might load a value from a database (company or employees, say), create a new value (with the higher salary, say), then write the new value to the database.

I think the point being made here was that alternative approach don't eliminate the difficulties of global state. Simply using immutable object doesn't make all your problems go away, it makes them different. I think it makes them better, but let's not pretend that all the challenges of dealing with state can be eliminated.

Re: The Case Against OOP Is Wildly Overstated

#289

Post by commandlinefan » Sat, Aug 01, 2020, 3:26 PM UTC

mypalmike wrote: post #239

commandlinefan wrote: post #197

Earlier quoted context omitted.

I had the same thought: he's doing OOP without using the "class" keyword. Well-written C code is actually very object-oriented this way, it just doesn't take advantage of the syntactic sugar of C++.

This is a common misunderstanding. Structural programming like this is clearly similar to what we think of as OO. But it existed before OO and is still heavily practiced in non-OO languages such as C. The main feature that OO added to this was dynamic function dispatch via inheritance. The specific function that gets called at runtime depends on the type of the struct. Inheritance has proven powerful but often result…

... and this inevitable pedantry is why I thought twice about replying to OP.

Re: The Case Against OOP Is Wildly Overstated

#290

Post by arp242 » Sat, Aug 01, 2020, 4:08 PM UTC

wvenable wrote: post #245

kryth wrote: post #229

Earlier quoted context omitted.

That doesn't make any sense. Being an anti-vaxxer is simply stupid, proven by real numbers and repeated experiments. Meanwhile, there are a lot of fair criticisms to OOP. Of course, a lot of them arise due to the fact that the skill floor for software development is quite low nowadays, but then again if we were all that smart, we'd just write C and C++ at the speed of light for everything. P.S: Rewriting hackernews i…

There are plenty of potential side-effects for vaccines as well. The last time I had one, I had a relatively unpleasant reaction. So I'm not saying that there aren't fair criticisms of object-oriented programming. But "the case against OOP" is not proven by real numbers and repeated experiments. It's the most successful programming paradigm in history. The evidence for the success of OOP is more overwhelming than for…

That it's successful doesn't mean it's also a good idea. To quote Dennis Ritchy: "C is quirky, flawed, and an enormous success". I feel this could probably be paraphrased to OOP as well.

OOP isn't super terrible, but it does mix some good ideas with bad ones. Newer languages tend to not be fully "OOP" but do include some of the better ideas from it. OOP isn't the end-goal of programming, it's a stepping stone.

Same applies to functional programming by the way; a lot of non-functional languages include various features pioneered in functional programming languages.