Is OOP really as bad as people make it out to be?

According to Alan Kay, OOP is much more like the actors in Erlang than like Objects in Java. The problems to solve are always the same, but every language solves it based on the features it has.

And, since Java Class/Object system sucks horse dicks, some of its solutions are unnecessarily complicated. Because of the fact that the problems that they solved emerge over and over - people just documented the best ways to solve them in java and called them "Design Patterns". Also this enabled people to pajeetpaste them everywhere, which made them into an atomic problem-solving unit just like a single class was, - which is how the """""Enterprise code""""" meme was born.

This way the typical office 9 to 5 drone, who just wants the friday to come to the end thinks:
> fuck, my boss wants this crap to be done by yesterday
> but this shit sucks, and the customer request is retarded af
> I know - I'll just copypaste the """""design patterns""""" I learnt about in grade school all over the place, change some vars and be done with it
> Can't be blamed, because I'll just say "These are industry standard practices"!
And so, instead of actually solving the problem the mess on the right of the OP's pics gets born.

This is why everybody with a gram of brain hates java - it's kind of convenient for the employers, because it allows the office drones to shit out piles of code fast while making everybody look productive, and it's disgusting for anyone actually able to program, because it's painfully hard to be flexible when having such constraints.

This is also a reason Haskell will never make it on the popularity context: it has the same overengineering feeling to it, but it just doesn't compile when you write it in a sloppy way.

tl;dr: OOP is not bad. If your OOP code is bad it's not the languages' fault - you suck.

(contd from )
exactly - because pajeets & shit
haskell, Erlang, SQL. Just stay in the industry a bit longer and look past Javascript. Browsers are not the only thing that gets programmed, you know?
Exception handling is the least OOP thing in any OOP language - basically you pop the current execution stack whenever shit goes wrong, you can (and should) do it in any language ever. Haskell's monad based error management not *that* different - it just uses your heap instead of the stack. Big fucking deal

>human-comprehensible yet robust systems
Care to elaborate on this buzzword bingo and explain how OOP helps?

this.

it's fine don't listen to Jow Forums autists who have never worked on anything beyond solo projects

Use the wrong tool for the job.

Use the right tool for the wrong job.

If OOP is bad why does linux write vtables by hand?
Checkmate freetards

OOP makes you write code in a way you can explain how the shit you're writing works without using any terminology.
Procedural code only cares about solving the task at hand and tries to do that in as few excessive actions as possible.
OO code cares about being human-comprehensible and readable first and foremost.
Your solution could be working with hundreds of classes, use dozens of interfaces, inherit shit all over the place - whatever is the thing that makes OOP "difficult" for you - but it will always make sense with just a glance on the code. It'll be always possible to explain what's going on in your solution by just using simple words, class and method names. It'll be always possible for any other (competent) dev to work with your solution, no matter how robust it is. If either of these isn't true for you - you're writing shit OO code.
In contrast, when you're working with an arbitrary multi-million line procedural solution (which you really shouldn't), you are deciphering the code - you ain't just "glancing" at it. And you better hope the said solution is well-documented and the comments are on point.
OOP is not about "programming magic" with old kung-fu guru achieving incredible results via secret techniques no one is capable of comprehending. It's about making the code human-readable.

Only if you use it blindly without knowing what you're taking advantage of.

Is it mainly inheritance, class to object? How is that so hard?

no, read The Art of the Metaobject Protocol

The right side is so true it hurts. But the thing is functional literally doesn't work for giant projects. There's no way in hell we could use anything other than OO at my work. You usually try to stick within your own bundles but when you can't it does turn into that disgusting mess.

>Is OOP really as bad as people make it out to be?
How about you try to list Jow Forums's non-fallacious arguments and then decide what to think when you realize the list is empty?

I still don't understand the point of interfaces in java. They just seem like a waste of code.

I don't use OOP as long as it is not necessary (always).

Well thats because you never finish anything because of how shit it is

Partly this, but most of the time I work with microcontollers, and there it is not necessary.

It's not oop without encapsulation and you can't do encapsulation without interfaces.

>subhuman
>fleas = 14

Attached: whG1fSC.jpg (917x671, 55K)

It's worse

Attached: 1523983227476.jpg (1680x945, 175K)

OOP is fine if you are not a retard

Newcomers take the whole

class Cat extends Animal

crap to heart, but most of your time with OOP will be spent dealing with interfaces instead of subclasses, and this is very valuable once you understand the concept of dependency inversion

I've seen enough of these threads to realise that the people who post these threads simply just haven't been a programmer for very long

OOP is ok when not used by spergtarded brainlets who try to abstract too much. however most OOP programmers fall into this category

>streamlining your workflow
wikipedia.org/wiki/List_of_buzzwords

The point of any interface is to define a specification, because that is what it is. It's barely code by any means

Having a function that accepts an interface as an argument means someone else can write their own class that implements this interface and pass an object derived from this class to the function with the guarantee that it will cooperate. This is called design by contract

If you plan to release any software that will be used by others for years to come, and be both forward- and backward-compatible, you will have to define a specification, thus you will create an interface

This doesn't just hold true to OOP but also any exposed APIs, REST or otherwise

The kind of people who make the mess on the right will make a mess no matter the language or tools they use. OOP isn't the problem, it's just that most easy languages are oop, so it's the one we see the most messes in.

How do functional languages handle interface like constructs?

Typeclasses. Or traits

You know what? I'll show you what are interfaces practically used for without any stupid theory.
Let's say you're writing a method that accepts an object and makes it do something
public static void DoStuff(Object alert)

What can you make "alert" do? Well, that would be whatever the Object class can, because "alert" is an instance of an object.
For example,
System.out.print(alert.hashCode());

will work just fine, because the method knows it's working with an Object, and the Object class has the hashCode() method.
But let's say, you want to call a delete() method on the "alert".
alert.delete();

Can you do that? No, the only thing the method knows about "alert" is that it's an Object, and Object has no delete() method.
Sure, you can make a separate class with this functionality
public class Message(){
public void delete(){
...
}
}

and redefine your DoStuff() method
public static void DoStuff(Message alert)

Now you can call
alert.delete();

without any problems.
However, now you can't "DoStuff" with just any Object - only Message will do.
But what if you want to "DoStuff" aka "call delete()" with something else? Well, you can overload your DoStuff() method for every single class in your solution that's going to be used with it. That also means whenever you're making a new class you want DoStuff() to work with, you have to also make another overload.

cont Interfaces give you another way to achieve this result. It's clear that the only thing DoStuff() cares about is "alert" having a delete() method. Then, if you do something like this
interface Trash(){
void delete();
}

You are creating an Interface that guarantees anything implementing it *has* a void delete() method without telling anything about how that method is actually implemented.
Then, you make your Message class implement the new Interface
public class Message implements Trash(){
public void delete(){
...
}
}

and change your DoStuff() to accept the Interface instead of the previous Message class
public static void DoStuff(Trash alert)

The compiler will still have no problems with
alert.delete();

because it knows that any class that implements Trash interface must also implement delete() method.
So, now you can create an entirely new class
public class History implements Trash(){
public void delete(){
...
}
}

and you'll still have no problems with calling DoStuff on an instance of History class because it still implements Trash interface thus fits the criteria of being a parameter for it.
So instead of writing a new overload for DoStuff() whenever you create a new applicable class, you just add the Trash interface implementation to the class itself and everything works like a charm.

In C# the same interface would be called like IDeleteable or something.

Is your project bigger than Linux kernel? If not then your opinion is shit.

The Linux kernel is shit.

>subhuman
gets me everytime

No. People just say it is bad because they have see the entire Gupta bloodline use it wrong.

your life is too, tho
this

I was going to say left: Smalltalk, right: CLOS personally lol.

OOP is bad if you use it for deep inheritance trees that create not only system overhead, but mental overhead in development.
If you keep it simple, it works fine.
Going off in to the deep-end serves fucking no one and only makes it harder to manage.
Going off the deep-end is akin to the retards that use Loops,If-then or some other shit hack to get around having to use Goto because "muh professor said the things!!".

OOP is perfectly fine for the tasks that demand it.
Deep trees help nobody, though. They do not improve workflow, speed or any of those things memed about.
Keep your trees simple.
OOP-bloat is shit for everyone, but especially as a developer.
If you need to look through 20 classes to figure out what the fuck you are doing, you are already doing it wrong. Stop that shit, it's retarded.

As always, keep it simple, stupid!

OOP hating is so reddit/ycombinator