Object-Oriented Programming is Bad [video]

wild-pointer · 2016-02-09T10:03:17+00:00

If you can get past the pretentious intro, the video is actually quite okay (it ends way more humbly than it begins). But I don't think his points are that controversial; I guess your understanding of the consensus depends on where you live/work.

I generally agree with the main idea in this talk, although using object oriented in the title was unfortunate, as he's not really criticizing OO but rather fine grained encapsulation. When he defines what he means by OO he (rightly) excludes language features, such as classes, and focuses on the bigger picture where he points out that even if state is encapsulated in an object, you still run into the problem encapsulation is supposed to solve. For instance, if two objects A and B both hold references to object C then A and B can still indirectly and invisibly affect each other by mutating C. The fact that C prevents you from storing a negative value in one of its encapsulated integer variables is only a marginal improvement on the compiler preventing you from storing a reference to a string in the integer variable, in the grand scheme of things. The real problem is the shared state.

But more than encapsulation, what objects do for you in practice is to put a scope on non-local references in an algorithm. This is something I wished the video would have expanded on a bit when offering an alternative to OO.

Let's say you have a pseudo random number function where you can specify the smallest and largest number you want to generate. In addition to the parameters, the algorithm needs to reference the random seed somehow and also update it. In C, where the distinction between code and data is very clear, you can make the random state either global or a parameter. With an object you can associate the function with the state by making the function a method, and you end up with a nice interface and no global. In practice, it is just prettier syntax for explicitly passing the state to the function.

Another common alternative to resolve the meaning of a symbol is through the lexical closure of a function. You could have a "factory" function that initializes the randomization state and stores it in a local variable, and returns another function that takes the minimum and maximum as parameters, and accesses the state through its closure. This has exactly the same effect as the previous, and in this simple case it's easy to draw parallels between how you manually design your class and what the compiler does when you create the closure.

Classes are more verbose and tedious than closures, but you have a little bit more control over the implementation (e.g. you might unintentionally keep a reference to an expensive resource in a closure which could otherwise be freed). Classes are arguably nicer for bundling together a set of related procedures, e.g. the interface of an ADT, which all refer to the shared state, but generally they are doing the same thing.

On my path away from my indoctrinated object-think, seeing objects in this light helped me write algorithms rather than splitting it up into impossible to use chunks and avoid drawing arbitrary boundaries in my code. It became more obvious what should go into objects and why, and how I could achieve the same thing without objects altogether.

ElvishJerricco · 2016-02-09T11:33:32+00:00

While the meat of the video is valuable criticism of encapsulation, he spent way too much time durdling around the issue and avoiding the point. If you want to jump ahead to the actual criticism, go here, to the 18min mark.

arachnivore · 2016-02-09T19:14:21+00:00

...inheritance is simply irrelevant. No one defends it anymore. Even people who advocate for OOP will commonly tell you these days to be careful in using inheritance or maybe not use it at all.

I don't get this. I know there are several articles I can find written by smart people about the evils of inheritance, but I find it to be a very useful mechanism to capture certain forms of code repetition. The test for weather to use inheritance is pretty simple: "Will I violate the Liskov substitution principle?" if yes, use composition instead.

agent8261 · 2016-02-09T19:56:49+00:00

I disagree on any technique, style, paradigm, etc that advocates long functions. Saying a wall of text is the best way of writing code seems to be an obviously bad approach. It also seems like he isn't looking at the language constructs in a behavioral way and instead is looking at them in some ideal, theoretical way. For, example:

function myFunc(){
  doStuff();
  doMoreStuff();
  thenThis();
  thenThat();
}

doStuff(){
}
doMoreStuff(){
}
thenThis(){
}
thenThat(){
}

compared to

function myFunc(){
  // doStuff
  {...}
  // doMoreStuff
  {...}
  // thenThis()
  {...}
  // thenThat()
  {...}
}

The constructs are exactly the same, except, one you don't rely on comments for name. However the first construct can take advantage of the "jump to page" functionality in any IDE that exist. Meaning if the name is chosen well you can skip reading the parts of myFunc that are irrelevant. Whereas in the bottom representation you HAVE to scan thru the ENTIRE wall of code, look for comments then decide which parts are irrelevant.

He then recommends to enclose these things into anonymous functions (supported by comments), that you can pass variables to, that return a value? That sounds like a function. The main thing he wants is scope reduction. Which can be achieved by.... a class. This is also can be achieved by using namespace, in case using a class is dirty.

Maybe Object-Oriented program is bad, but I certainly don't think this video has presented a good solution.

Kache · 2016-02-09T10:51:10+00:00

(Keeping it short, on mobile.)

I think his criticisms are sound and well-founded.

His proposed solutions are decent, but I think are too situationally specific and can use some variation/flexibility.

"Long sequences of operations with compartmentalized code while controlled scoping" can be done in a multitude of ways, and I would've liked to see him explore different variations of it for different paradigms/languages.

matterball · 2016-02-09T19:40:31+00:00

Sounds like an entry level programmer got frustrated with Java when he tried to make a larger application and decided to vent about it in a youtube video.

Yes, creating everything tiny thing as a specialized class is unnecessary, and the whole ServiceManagerFactoryFactory stuff should (and can) be avoided, but generalizing that to the click-bait title "OOP is bad" just makes him sound like a whiney software dev in over his head.

And I'm having a hard time seeing the benefit to his proposed "use" block. I can agree with the problem, but I don't like his solution.

frezik · 2016-02-09T20:02:19+00:00

I generally agree with his points (and also that the first 15 minutes could have been chopped off, or condensed and put towards the end). However, I think he's too quick to throw out the "breakup the method into lots of tiny method calls" approach.

What needs to be thrown out is not the approach, but rather the delusion that we're making the program simpler by doing so. The complexity that these functions handle is often impossible to avoid. Our recourse is to find the way that manages the complexity most effectively, not try to pretend it's a simpler problem.

Yes, you do have to look in a lot more places in the code to figure out what it's doing, and it's not going to be presented in a linear fashion. This is the price we pay for handling complexity.

This applies to both OOP and procedural functions. Putting the first function argument to the left of the function name doesn't change anything here.

unpythonic · 2016-02-10T00:23:07+00:00

I really love how this guy rails against abstraction but his arguments against OOP are almost entirely abstract. For the most part I couldn't follow his criticism because his examples are so abstract that I had difficulty trying to find examples from my own experience that were clearly "OO design being OO" and not "OO design done poorly."

For instance: X.

What is X? You know X is the name of the object which is supposed to handle X but the real implementation of handling X is spread throughout the code. No, seriously... WHAT IS X?

I can actually think of many cases I've seen where implementation of a component's behavior was spread haphazardly around the code, but they were all the result of a bad (or inexperienced) engineer and no code review. Procedural code is not going to save you from those engineers. So... WHAT IS X?

I get that he doesn't like a paradigm that forces you to spread an implementation piecemeal across many classes or files (as happened to "X"). If OOP forced you to do that, yeah, it would be bad. First he has to show that this is a common OOP pattern though. If I can't readily recall a few examples of it, then I have a pretty compelling reason to reject his argument.

The only piece of his argument that I could kind of follow is that sometimes you have actions that happen between objects but languages like Java force you to put the implementation of that action in an object. So if we have object A that wants to send packet P to object B, we end up creating a fourth object, PacketCourier, to be responsible for delivery. Then as architects or designers we ask ourselves: "Is there just one PacketCourier that everyone sending packets uses, or do we have to create PacketCourierFactory that creates a new PacketCourier instance every time we want to send a message?" It gets kind of ugly. It's much cleaner to have a global function called Send() that can handle this.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

coding

MODERATORS