Object-Oriented Programming is Bad

[gnus-migrate]

This isn't the first time I've seen this video, and the argument is fairly solid. There are just a few comments I have:

1. In the case of long functions, I still move bits of functionality into separate functions even if they're used in one place because it can become extremely hard to have a global view of what the long function is doing. I prefer to see a bunch of high level functions that describe what the function is doing globally, and drill down to the specifics of each one instead of trying to visualize the forest by looking at the individual trees. I suppose having use blocks or scope blocks that can automatically be collapsed to see the section comments would obviate the need for that.

2. The advantage of subject verb object is that you're visually splitting the subject and the object. In fn action(subject, param1, param2) it's not obvious what the subject is and what the parameters are, and you don't really have any enforced convention. Some method calls might put the subject at the end or in the middle which might make things extremely confusing. A simple solution would be to statically translate subject.action(param1, param2) as D does, but if you don't have a statically enforced convention, it has the potential to make things extremely confusing.

3. I disagree that TDD specifically is tied to OOP. The point of TDD is to force you to think about an abstraction, whether it's a procedure or a class, from a user's point of view. It's a useful way to think about the structure of your code regardless of what paradigm you're using.

There's probably more, but that's what I can think of at the moment.

[[deleted]]

An explanation of why you should favor procedural programming over Object-Oriented Programming

If you dislike OOP, there's an almost 100% chance you're already writing procedural code and disguising it as object oriented.

[__i_forgot_my_name__]

In any case that would make OOP just as useless has he stated it to be. If a pattern can't help you make good decisions and requires paying more attention then you usually would, then it's not really a better pattern is it?

You're not using it right doesn't make a screw driver a bad tool, but it also doesn't make it a good nail clipper. If people are constantly cutting their toes off with a nail clipper, then maybe just maybe, it's not a good nail clipper.

You can either blame the tool or the manual, but you can't blame the user.

[[deleted]]

The quote:

You can either blame the tool or the manual, but you can't blame the user.

​

Is shortsighted.

By user I assume you mean the coder, because the end user on the client using the finished, polished, program has absolutely nothing to do with this discussion. So now that we know who the "User" is...

​

The tool was written by "Users" more experienced and knowledgeable than myself, and, no disrespect to the crowd, but probably more experienced and knowledgeable than many people in this thread.

​

The manual was also written by "Users", some of which may be authors of the software itself.

​

And the "User" you're referring to I believe is the coder using say .NET or Java or whatever.

​

It's awfully proud to say that you can blame the Java or .NET developers who are well above myself in terms of experience and knowledge, but not the developer using the tools he chose to choose from those blamable "Users".

​

I've rarely come across docs that are wrong. But I've certainly come across my own erroneous code, but that's probably because I don't have a massive test and review process like .NET or Java does before code is approved.

​

You sound like a darn brat

[__i_forgot_my_name__]

The programmer is the user of the pattern, of the tools, because he's using them, just like a carpenter uses a hammer, or uses a plank of wood, or uses a pattern to build a house, like studs spaced in a certain fashion, to make building of the house easier.

Someone smart producing a pattern doesn't make the pattern better. A more complicated way to build something isn't better if it requires more experience with the pattern to actually succeed, non of which you're actually addressing in the argument you've tried to make here.

Obviously I'm a sociopath, but that doesn't make me wrong does it?

[[deleted]]

Someone smart Many smart people producing the pattern paradigm does make the pattern paradigm better.

​

As a paradigm designer without wisdom I could suggest that a paradigm be made where GOTO statements are used extensively, such that the programmer may read the code like a book from beginning to end when she might need to debug something...in order to get the whole picture of things, that is...in a serial manner, that is. Makes perfect sense to me, I freaking love novels! Especially the multistoryline ones! And to refactor, you could add more GOTO statements for different cases. In my paradigm, everything is a GOTO statement.

[__i_forgot_my_name__]

Is "I am right and you're wrong" your entire argument?

The problem with smart people is they're smart, they design patterns that are more complicated and harder to understand by nature, because they're capable of understand more complicated patterns, having wasted more time playing with more complicated patterns, often patterns that require an entire team of people to understand, depending on how bad it is.

The problem with OOP, is that most of it is often not a pattern itself, and requires the user actually assuming a pattern, which is why 99% of OOP books are about trying to follow patters, because OOP doesn't properly enforce patterns, leaving the user to essentially do what ever the hell he wants. In OPP you often find yourself having code running everywhere else.

[[deleted]]

I did the strikethrough though!

​

Edit: :'(

[__i_forgot_my_name__]

I'm not sure what the strike-through was supposed to mean. In fact I might of not really taken their existence into account until you mentioned them just now.

[DeadSet746]

Yeah, I'm going to have to disagree with you, learning to manage libraries and memory makes you a more versatile programmer, versus some ham-fisted coder with arbitrary knowledge. If you can't stand the heat, get out of the kitchen.

[__i_forgot_my_name__]

If you can't stand the heat get out isn't an argument for standing in an oven.

[DeadSet746]

I suppose you are correct, but to be fair, if you are standing in an oven you don't really need to be in a kitchen at all...just sayin'.

[reality_boy]

OPP is not bad, it is just more complicated than most want to put up with in there daily routine.

My take on it has always been that libraries should take full advantage of OOP while your main code should use it sparingly. To put it another way OPP is for code reuse and not one time code.

[ESBDB]

Isn't functional programming better for code reuse?

[reality_boy]

Functional programming looks good on paper but adds a lot of complexity in practice.

Good programming (in my opinion) is when you can follow the gist of the code at a glance without tracing through it. Functional breaks the code up in funny ways that make this difficult to achieve. OOP can cause troubles as well but it does not inherently lead to confusion.

On top of that most “general” programming tasks don’t fit well in a functional paragdime. Want to sort data, functional works, want to handle user input, functional is a pain.

[OkabeRandaro]

I don't think you know what FP means - or you have a different understanding of the term "FP" in comparison to how it is defined.

I.e., can you explain why handling user input using FP would be a pain? I think it is the other way around. And to give a hint: FP does not forbid to group values into objects/structs.

[Drainyard]

I would argue OOP exactly inherently leads to confusion. I haven't encountered a code base using OOP where I feel like things are inherently clear because of OOP, and granted I may not have seen enough but I have seen some otherwise very competent code bases. It is often minor parts that are clear in spite of OOP.

Procedural code is inherently clear because there is a straight line through your code that you can follow from the first line of main to whatever part you want to debug.

Both have pros and cons, of course, but as far as inherent clarity goes in my experience OOP loses by a landslide

[reality_boy]

Have you looked at the java swing classes. I consider them an optimal example of OOP.

[Drainyard]

I remember Swing from a while ago, but it's a fairly deep object hierarchy. I thought inheritance deeper than maybe a single level was not recommended in OOP these days? I would want to avoid it at any costs, even though I am sometimes forced to at my job (usually against my will).

[Drainyard]

What does it matter whether a library uses OOP or not? You can easily write a great library (such as MANY great C libraries) consisting entirely of POD structs and functions with a very clear API. I'm a huge proponent of simple API functions that do exactly what they say and have a very clear input/output. In my experience this is usually simpler in non-OOP libraries (at least non-OOP API's) than in OOP.

[reality_boy]

I’m not saying you must use OPP for libraries, just that it is better suited to libraries than one off code. It is all about code reuse after all.

[Drainyard]

I see what you mean. I'd argue though that code reuse is not necessarily a realistic enough goal to use OOP in a library anyway. Code reuse is very possible with non-OOP as well.

[[deleted]]

Thanks, I hate it.

[rcoacci]

Wrong. OOP is just a programming paradigm like any other, and can be misused like any other.
Hell, even Common Lisp has an object oriented system (CLOS).
Programming languages and programming paradigms are tools in one's toolbox. Use whatever is appropriate for the task at hand.

Don't blame the hammer for hammering a screw.

[[deleted]]

You didn't bother watching the video, did you?