The Case Against OOP Is Wildly Overstated • Hacker News Board

Re: The Case Against OOP Is Wildly Overstated

#91

Post by Guvante » Fri, Jul 31, 2020, 4:59 PM UTC

garethrowlands wrote: post #63

lgessler wrote: post #4

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

A typical microservice tightly binds code and data, and it communicates via messages. So when a microservice is useful, it's an example of binding data and code being useful. Though when a microservice mutates something, it's typically persisted in a database or similar (and, you'd hope, not sprinkled throughout its code). But, yeah, a bunch of communicating microservices are a lot like communicating objects - for be…

Tightly binding code and data works as long as a useful abstraction is created. Keeping the structure of a person and how to interact with that person together is a fine paradigm. Usually the issue with OO is that the abstraction isn't there and it is just half the functions to interact with the person and/or there is an expectation that certain fields are manipulated by calling code instead.

Microservices require every action you take be a message and enforce that messages are the only way to communicate which makes it easier to avoid indirect (and thus hard to track) dependencies.

For instance if the person's age is updated when you calculate their hours worked, in OO that might be hidden from view but in message passing you would at least see that a new person object came back that replaced the one you had.

None of this stops you from doing evil unobvious things with your hidden information (updating everyones age whenever anyone gets overtime) but it is usually harder to accidentally do that.

To be clear while I like microservices I think they have many problems just like OO. For instances caching becomes super complicated and there is a real cost of going over the network for everything you do. The tradeoffs are just a different set of tradeoffs.

Re: The Case Against OOP Is Wildly Overstated

#92

Post by waffletower » Fri, Jul 31, 2020, 5:00 PM UTC

tgflynn wrote: post #41

lgessler wrote: post #4

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

So what is your preferred solution for programs that intrinsically need to deal with a lot of state ? Global variables ? I used to see that type of approach in some complex Fortran simulation programs where every function referenced a huge common block. I really don't think that leads to easier to manage solutions.

You might want to consider examining another programming language for clues here. Perhaps look to a language that has a more modern approach to state such as Clojure.

Re: The Case Against OOP Is Wildly Overstated

#93

Post by lkrubner » Fri, Jul 31, 2020, 5:01 PM UTC

lgessler wrote: post #4

This 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 the essay).

[1] Object Oriented Programming Is An Expensive Disaster Which Must End

http://www.smashcompany.com/technology/object-oriented-progr...

Re: The Case Against OOP Is Wildly Overstated

#94

Post by ehutch79 » Fri, Jul 31, 2020, 5:01 PM UTC

winstonewert wrote: post #25

dnautics wrote: post #16

Earlier quoted context omitted.

Always prescribing raw sql is dangerous: You typically want something managing your sql queries if there's user input because scrubbing out SQL injections is hard and it's not something you should be 'rolling your own'

I presume that when somebody says raw sql they mean are using parameters and not just building strings.

No, they definitely mean artisanal, handmade, organic sql. 100% free of character escaping or corporate ORMs.

Re: The Case Against OOP Is Wildly Overstated

#95

Post by jerf » Fri, Jul 31, 2020, 5:04 PM UTC

jcelerier wrote: post #49

clktmr wrote: post #27

> The solution to the fragile base class problem and other inheritance hangovers is surprisingly simple — don’t use it If OOP provides the footgun to shoot yourself, OOP is at fault. Overall the article reads as "OOP has no problems if is used correctly". Of course that's true. I have seen well designed OOP programs, but the majority was not. The author should ask the question, why OOP is applied the wrong way so oft…

> The author should ask the question, why OOP is applied the wrong way so often. well, if universities started by teaching something else that "Cat" inherits "Animal" in 2020 ...

Personally, I think this is a large part of the problem with the whole "Is OO Good?" debate. OO was initially thought to be a solution to essentially simulations problems ("Simula"[1] - the first OO language - it was right in the name!), where Cat inheriting Animal makes sense.

It turns out this translates to general purpose programming exceedingly poorly. It spends your valuable class hierarchy budget on the wrong things, while discouraging spending it on the right things.

On the other hand, OO turned out to be a useful gateway into polymorphic programming (not the only one, but a useful one), and to be a useful organization principle in real programs when used differently. Instead of Cats inheriting from Animals, you have interfaces for things like Iterators, which aren't real world objects at all, and you have objects that encapsulate certain operations, or certain patterns, or other much more abstract things that have no concrete physical referent. This style can work fairly well, especially if you don't overuse inheritance.

The simulation argument has really faded in the past 20 years, but even now, you get some crossfire between people attacking that formulation vs. people defending the modern version, and they're talking about such different things they might as well not even be talking about the same paradigm.

And as is typically the case, education is a lagging indicator, and even fairly recently I've seen it training people on the simulation model, even though by the 2010s it was pretty clearly useless in practice.

[1]: https://en.wikipedia.org/wiki/Simula

Re: The Case Against OOP Is Wildly Overstated

#96

Post by acdha » Fri, Jul 31, 2020, 5:07 PM UTC

bussierem wrote: post #32

The problem I've always had with these back-and-forths between various programming philosophies is that the very nature of the argument exposes the reason the arguments don't work. The most common (but not only) way each side argues its point is to take some contrived example and show how philosophy X does it well, and how philosophy Y does it terribly. These examples are often ranted about by the "Y" proponents beca…

The other related observation I make is that our field suffers from dogmatic thinking. A methodology is a tool, not a holy calling which cannot be altered: if it's working for your team, it's good; if not, adjust to something which works better.

The problems come in when someone reads some over-stated screed about design patterns, pure functional programming, etc. and then decides that they have to throw every other tool in the toolbox out, and follow The Right Way™ in every possible way even when they're spending most of their time on problems of their own creation rather than their job. The various philosophies being debated will change over time but that mindset is remarkably stable.

Re: The Case Against OOP Is Wildly Overstated

#97

Post by meheleventyone » Fri, Jul 31, 2020, 5:07 PM UTC

jeffffff wrote: post #76

Barrin92 wrote: post #56

Earlier quoted context omitted.

depends on the domain. In anything that has say, a very structured 'data flow' in one direction, like in finance or accounting or versioning immutability works well as a concept. In other domains like say, game development it feels forced and out of place. If actual usage of paradigms is an indication rather than belief then it doesn't look like functional programming really is intuitive, it tends to be very useful i…

game development seems to be moving away from OOP and towards entity component systems and data oriented design. i've heard arguments that OOP's killer application is desktop guis, which i could buy, but those become less and less relevant daily. (caveat: my experience is entirely in back end and low level software and anything i say about front end or ui development should be highly suspect)

You can still program in a data oriented manner using OOP. It is after all just about watching data access patterns in view of the hardware constraints and organizing along those lines.

What there actually is in game development is a definite wish for a simpler language than C++ and dislike of many of the newer parts of it.

Re: The Case Against OOP Is Wildly Overstated

#98

Post by nostrademons » Fri, Jul 31, 2020, 5:09 PM UTC

lgessler wrote: post #51

tgflynn wrote: post #41

Earlier quoted context omitted.

So what is your preferred solution for programs that intrinsically need to deal with a lot of state ? Global variables ? I used to see that type of approach in some complex Fortran simulation programs where every function referenced a huge common block. I really don't think that leads to easier to manage solutions.

Essentially, yes, but in a way that sounds more careful than what you saw in that Fortran program. If it absolutely has to be stateful, like with a db connection for example, then there's no getting around that, but what you can do is (1) not bury it in a bunch of stateful objects that didn't have to be stateful, which can cause cascading errors when either one of them misbehaves and also makes it difficult to isolat…

More concretely, for every bit of state in the program I'm interested in two big questions, each with two subquestions:

1.) Who can access this state, and which of those accesses allow writes vs. which are read-only?

2.) What is the lifetime of that state, and what portion of that lifetime is mutable vs. read-only?

Java-style OOP can control #1, but makes no distinction between reads & writes. C++ const correctness and the val/var distinction in Kotlin/Ocaml/ES6/etc. can make that distinction, but only C++ forces you to think in terms of lifetimes. Rust borrowing probably comes closest to answering all 4.

I'm still waiting for a language feature that lets you say "This field of this struct is only mutable while this module is running, and once it completes it will never be changed", though. A lot of data structures are initialized in passes and then passed along as constant data: you construct the basic object structure with nothing but a few IDs, then you compute extra fields as necessary, then you're done and the object is never written to again. If you could keep the fields mutable during initialization (which may be a longer process than just constructor calls) and then seal them off once that's complete, you eliminate a whole class of bugs where a read-only client decides to mutate a field that should only be mutated from designated initializer.

Re: The Case Against OOP Is Wildly Overstated

#99

Post by gizmo385 » Fri, Jul 31, 2020, 5:10 PM UTC

dreamcompiler wrote: post #36

PSA: If you want people to read your tech posts, don't write them on Medium. Medium requires logging in to view their content now, so like Pinterest, Quora, etc they are dead to me. And I know I'm not alone.

Given that the post is ranked relatively highly on Hacker News at the moment, it would appear that there are people who are still reading their tech post even though it is on Medium :)

Re: The Case Against OOP Is Wildly Overstated

#100

Post by addicted44 » Fri, Jul 31, 2020, 5:11 PM UTC

garethrowlands wrote: post #63

lgessler wrote: post #4

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

A typical microservice tightly binds code and data, and it communicates via messages. So when a microservice is useful, it's an example of binding data and code being useful. Though when a microservice mutates something, it's typically persisted in a database or similar (and, you'd hope, not sprinkled throughout its code). But, yeah, a bunch of communicating microservices are a lot like communicating objects - for be…

Eventually data has to be bound to code. Otherwise you'd have apps where you either have functional code running and other apps that are displays of raw data.

The engineering question is what layer is it appropriate to do so. Under traditional OOP (your pre functional forward Java/C#/OOP C++), the answer was that code is almost always bound to data.

Haskell style functional programming binds code to data at the last moment possible.

The best answer is likely somewhere in the middle, depending on your application and usage. I find, for example, that UI controls work well with OOP, but most other stuff I tend to default to functional style programming.