OOP

there is nothing wrong with True OOP — that is, languages like Smalltalk and Erlang.

but more often than not, you'll see pajeets advertising some languages and practices which they think are OOP but actually they aren't.
For example, Java has nothing to do with OOP, as well as C++.

I don't fully understand your picture.
You show some data types, but are omitting how to instantiate elements of these types.
Don't tell me you call `new` everywhere in your code - that's hard-coding in the data dependencies!
It would be much more sane to design a factory system (pic related) to leverage for creating these Shapes.
What I need to see is the overlay graph of your Dependency Injection hierarchy on top of your classes to be able to really grok what you see.

pOOP is good.

ABSOLUTELY DESIGNATED

There's a reason OOP is POO spelled backwards :^)

?
Can't you just pass a lambda?

dynamic oop is good
statically typed oop is bad
design patterns are a symptom of a language not being expressive enough

but that's just my opinion man

go home

You can see the problems with OOP in your picture already: rectangles are polygons and squares are rectangles. However, squares have actually less information than rectangles, so the Square class cannot inherit from the Rectangle class.

Some light OOP like classes to group functionality that belongs together is OK, the problem is when the entire program in mandated to be written in an OOP style. With that said, pretty much all of OOP can be replaced with functional programming. Point in case: the object-oriented part of Common Lisp (called CLOS) is built on top of Common Lisp in Common Lisp itself. When you write a class or call a method your code is rewritten in a functional style behind the scenes.

oop in the loo

Seems like you just answered your own question there.

Smalltalk doesn't have message passing. It's just synchronous function calls like JavaScript, but with "meme syntax" so Lisp retards think it's cool. People think there's something special about the syntax. Both are just alternate syntaxes for Ruby/JavaScript.

On the other hand, Erlang is a form of OOP but Lisp retard "memers" think there's something special about the syntax too. Prolog looks like that because they're Horn clauses from logic. Erlang uses "," to mean sequential composition, NOT logical conjunction.

from personsl experience OOP is good when you're creating a lot of variables that are almost identical to one another (ie gamedev, ui design), but, since OOP adds a bunch of verbosity to the language, if you're doing other stuff you'll end up writing more code in boilerplate than you saved by using OOP

nope i don't geddit what's so great about OOP again

Less copypaste.

What the fuck are you even on about?

OOP is sometimes useful and can be nice for general system design. It was hyped to high heavens in the 90s and 00s, so people misapplied it to just about everything (and still do).

The majority of design patterns are just workarounds for a weak language. First-order functions obsolete about half of them and macros obsolete the other half.

OOP can be very good, and it can also be very bad, depending on how you use it. It's a very good tool when you have datatypes that work well with a noun analogy, and are expected to perform actions, and you want to replicate very similar, but not identical behavior among a lot of related types while minimizing repeated code. The analogies that are used to teach beginners are usually retarded.

The perfect use for OOP is a widget toolkit for a GUI (think Qt or GTK+). There's a very good reason why you would do this OO. You want to have a root container type with dozens of container types with similar behavior, you want to have possibly hundreds of widget types with similar behaviors, and the ability to add your own without modifying library code. These widget types will have up to 50 functions that can operate on all of them with similar behavior (identical behavior, for most of the widgets and calls). OO is the best paradigm for this. Even if you do this "without" OO, you will essentially end up with a hand-hobbled object system anyway.

OO is horrible for very data-oriented things, like filesystem drivers. Essentially, if your data can be treated as a noun (rather than a simple pile of data) and needs specific behavior that needs to be extensible, OO is probably what you want. If the analogy is incomplete (ie. your data is a noun, but it doesn't "do" things, you just do things to it, operate on it, or pass it to other things), don't use OO. This is why Filesystem drivers half-fail at OO, because a file doesn't "do" anything, it's just operated on (nonetheless, the file types in C++ are useful as they become generic stream types).

OO can also be useful for, as previously stated, making generic types that operate similarly for all inherited children, like C++'s container types and stream types, but you can get some similar advantages plus more with metaprogramming and duck-typing. In this case, you aren't actually benefiting from OO, but more benefiting from the fact that OO lets you subtype without the type system shitting on you.

This is the most important lesson of programming, kid. If something looks stupid or useless, or if you're trying to make a decision between two paradigms, the answer is almost always "depends what you're trying to do". There is never ever a one-size-fits-all solution. OOP may look horrible to you, but eventually you're going to run into a situation where you'd write 10 times the amount of code avoiding an OO pattern instead of just using one, and it will still run worse.

You'll find out when you've got about 50 different enemies and most of them need custom initialization.

it's called first class functions, Pajeet

Pretty retarded, since both languages were made to facilitate OOP from the start.

Java and C++ are true OO programming languages because they are based on objects that talk to one another.

You still have to write custom initialization with OO.

OOP? More like POO

Every time I think I'm writing something in OOP...I'm not really sure whether I am. That's my problem with abstract concepts like these, because they aren't a rigidly defined process (like...well...a 'procedure'), I have no idea whether I'm actually doing it or not. For example, if I'm writing a function with a lot of subfunctions, isn't that...inheritance? Am I not doing OOP? And as for what the fuck polymorphism is, it's like...I read it, but when I try to do whatever the fuck I think it is, I'm left with this completely unsure feeling.

Tl;dr, I have no idea whether I'm actually even 'doing' OOP when I try to do it.

no

inheritance is extending a class, and the child class has all the properties of the parent

like dalmatian is a child of the Dog class, so it inherits the number of legs from Dog

polymorphism is using the "same" method on a lot of classes.

like you have classes Cat and Dog

you can call

Cat.makeSound(); and it meows
Dog.makeSound(); and it barks.

It's taken me 4 years to understand OOP. Take that as you will. I think part of the hatred of OOP comes from the fact that it's pushed really hard in universities and businesses.
*sniff* Dejine patternsh are onlei usheful ven creetisizing the very foundashins of programming.
In all seriousness, I have no idea what design patterns are, if they're like "command patterns", then they are only applicable to OOP shit.
Entirely depends on what the hell you're doing. If it's developing a game, then it'd be a decent idea. Preferably, you'd use a mishmash of techniques to make programs (i.e. a mixture of imperative, OOP, and procedural techniques, because everything in a program cannot be reduced down to a "procedure" or "object" or anything else.)

Sounds like you don't know what OO really is. If you think encapsulating a struct in C with functions is OO, you'd be half right, but that's only a part and C allows you to break your way out of OO. It's like you ignore the paradigm whenever you please. I wouldn't call C object oriented just because you can play the psuedo-method game from time to time. Also full OO is something you see in smalltalk, when you really define everything with interaction between objects through messages, everything is an object.
What OP says it's true, if you go OOP by the book, you will end up with filthy shit piece of code in a lot of situations.

They are not pure OO, you have primitives that are not objects, you can code anything you want in C++ without ever touching a single object.

Oop provides a set of solutions that just works by using class abstractions. But these solutions are rarely ever the best. Most often than not, youre usin you hammer against a screw.

OOP is useful for code that is meant to be reusable. Works well for APIs. Having examples of how to implement a certain design pattern that fits your problem is good. Design patterns are necessary for some languages like javascript, and it is in your best interest to learn them. The problem with Design Patterns is that their overuse is actually bad OOP practice. If your classes all have design patterns, then you are fucking up. You are not creating useful abstractions. OOP can be taken too far. If your project has inheritance chains of 6-8 classes, then you are fucking up. You are doing unnecessary work that will only take you longer to get to a solution.

It is useful to have knowledge of many different approaches. Though, in the end, the best approach is often what solves the problem with the least amount of code and time required. Work in the field for 20 years, and you will understand that most code is thrown away or rewritten at some point.

Classes were a mistake. Structs + functions + namespaces + interfaces can provide the same functionality without the tangled web of insanity. Rust actually has the right idea on this. Add unified call syntax for extra comfiness.

It's very hard to make resuable code with C. OOP will make it very easy to reuse code that's structured as reusable.

It doesn't get you all the same functionality. Anything resembling subtyping doesn't work without some horrible aliasing or dispatch magic like gobject does. It is sufficient for most situations, but not all. You have to use a user-defined callback in most C libraries (like CURL, notably) for this reason, whereas in real OO languages, you can just pass a subtype of a specific class or (in duck-typed languages) just pass in a type that exposes the necessary functionality. Rust lets you get this with type traits. In this case, it's more about polymorphism, but at this rate, polymorphism of some sort is guaranteed with every modern OO language.

A square is a special case of a rectangle. You usually will go with Rectangle only if the Square doesn't have any special action/property attached to it, but if you need to differentiate the special case from the regular one (think having to do a instanceof check), it may be good to refine.
That IS stupid. Everything but Circle should inherit from Polygon in this stupid example.

But you can group it better. Writing code is not the problem, understanding it months later is where the money goes. Use a factory pattern (a decent one, not a Java-style meme factory like ) and you'll be fine.

They are patterns of design (lel) to solve certain problems that are common in OOP - i think a few of them maybe could be used in functional programming, but I can't really remember any examples.
For example, let's say you have a really complex Object that you create in your application, and you need to load instances of it every time you're using it. However, most of the time, you may need only a small set of that object's attributes - say, it's name and image, to use them on a list. You can apply the Proxy Pattern to solve that proble,, which is basically a fancy way of saying "create a smaller object that contains only what you need, and a method to load the full object when you need the rest of it."

This is the sort of thing OOP can create.
ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.RequestProcessorFactory.html

...