Why do people hate OOP?

When I was first introduced to the idea of OOP I was skeptical but didn’t know why - it just felt “wrong”. After its introduction OOP became very popular (I will explain why later) and criticising OOP was rather like “swearing in church”. OOness became something that every respectable language just had to have.

As Erlang became popular we were often asked “Is Erlang OO” - well, of course the true answer was “No of course not” - but we didn’t to say this out loud - so we invented a serious of ingenious ways of answering the question that were designed to give the impression that Erlang was (sort of) OO (If you waved your hands a lot) but not really (If you listened to what we actually said, and read the small print carefully).

At this point I am reminded of the keynote speech of the then boss of IBM in France who addressed the audience at the 7th IEEE Logic programming conference in Paris. IBM prolog had added a lot of OO extensions, when asked why he replied:

“Our customers wanted OO prolog so we made OO prolog”

I remember thinking “how simple, no qualms of conscience, no soul-searching, no asking "Is this the right thing to do” …

Objection 1 - Data structure and functions should not be bound together
Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds. Why is this?

*Functions do things. They have inputs and outputs. The inputs and outputs are data structures, which get changed by the functions. In most languages functions are built from sequences of imperatives: “Do this and then that …” to understand functions you have to understand the order in which things get done (In lazy FPLs and logical languages this restriction is relaxed).

Data structures just are. They don’t do anything. They are intrinsically declarative. “Understanding” a data structure is a lot easier than “understanding” a function.
Functions are understood as black boxes that transform inputs to outputs. If I understand the input and the output then I have understood the function. This does not mean to say that I could have written the function.

Functions are usually “understood” by observing that they are the things in a computational system whose job is to transfer data structures of type T1 into data structure of type T2.

Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage.

Objection 2 - Everything has to be an object
Consider “time”. In an OO language “time” has to be an object. But in a non OO language a “time” is a instance of a data type. For example, in Erlang there are lots of different varieties of time, these can be clearly and unambiguously specified using type declarations, as follows:

-deftype day() = 1..31.
-deftype month() = 1..12.
-deftype year() = int().
-deftype hour() = 1..24.
-deftype minute() = 1..60.
-deftype second() = 1..60.
-deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}.
-deftype hms() = {hms, hour(), min(), sec()}.
...
Note that these definitions do not belong to any particular object. they are ubiquitous and data structures representing times can be manipulated by any function in the system.

There are no associated methods.

Objection 3 - In an OOPL data type definitions are spread out all over the place
In an OOPL data type definitions belong to objects. So I can’t find all the data type definition in one place. In Erlang or C I can define all my data types in a single include file or data dictionary. In an OOPL I can’t - the data type definitions are spread out all over the place.

Let me give an example of this. Suppose I want to define a ubiquitous data structure. ubiquitous data type is a data type that occurs “all over the place” in a system.

As lisp programmers have know for a long time it is better to have a smallish number of ubiquitous data types and a large number of small functions that work on them, than to have a large number of data types and a small number of functions that work on them.

A ubiquitous data structure is something like a linked list, or an array or a hash table or a more advanced object like a time or date or filename.

In an OOPL I have to choose some base object in which I will define the ubiquitous data structure, all other objects that want to use this data structure must inherit this object. Suppose now I want to create some “time” object, where does this belong and in which object…

Objection 4 - Objects have private state
State is the root of all evil. In particular functions with side effects should be avoided.

While state in programming languages is undesirable, in the real world state abounds. I am highly interested in the state of my bank account, and when I deposit or withdraw money from my bank I expect the state of my bank account to be correctly updated.

Given that state exists in the real world what facilities should programming language provide for dealing with state?

OOPLs say “hide the state from the programmer”. The states is hidden and visible only through access functions.
Conventional programming languages (C, Pascal) say that the visibility of state variables is controlled by the scope rules of the language.
Pure declarative languages say that there is no state.
The global state of the system is carried into all functions and comes out from all functions. Mechanisms like monads (for FPLs) and DCGs (logic languages) are used to hide state from the programmer so they can program “as if state didn’t matter” but have full access to the state of the system should this be necessary.

The “hide the state from the programmer” option chosen by OOPLs is the worse possible choice. Instead of revealing the state and trying to find ways to minimise the nuisance of state, they hide it away.

Why OO was popular?
Reason 1 - It was thought to be easy to learn.
Reason 2 - It was thought to make code reuse easier.
Reason 3 - It was hyped.
Reason 4 - It created a new software industry.

I see no evidence of 1 and 2. Reasons 3 and 4 seem to be the driving force behind the technology. If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money.

This is is the real driving force behind OOPs.

Because it's popular, and on Jow Forums people like to hate popular things.

Because he is a faggot

Underrated

Nobody except boomers hate OOP. Boomers just don't want to learn new things.

It's impressive how something can be made out of grammatically sound English sentences that use all the terminology of a subject matter, and sound very reasonable to a layman, while actually making no fucking sense whatsoever to anyone familiar with the material. Good job, user. Where did you get this from?

I think a better question is, why do people like OOP?

OOP, OP, what's the difference. You're still a faggot.

>while actually making no fucking sense whatsoever to anyone familiar with the material
Not him, but care to refute his objections if you're so familiar with the material?

only hobbyist programmers hate oop

/thread

It's difficult to tackle because a lot of it isn't wrong per se but it's based a lot on opinion and preference.

The only one I truly object to is . You can absolutely separate data structures and functions in an OOP language. He's just never seen this in action. To the fair most people when they're taught OOP are lead to believe they're supposed to mingle them.

is true in many ways but it's not necessarily a bad thing. I could build his Time object as described and also include some logic that would prevent you from creating a date of February 31st but oh hey whoops I just mingled data and functions now he's unhappy. I do like the way you can define types in languages like Erlang/Haskell though, there's definitely some utility to them.

No idea what he's rambling about in . It's not difficult to create a Time class and put it somewhere that can be easily accessed. Maybe he wants to jam everything into one file and can't?

is again more about how you've constructed the system. It's not the language guarding keep you from accessing state, it's the library you're using or have created. Sometimes there's a good reason for it, sometimes not.

They don't take any time for planning and are classifying real world objects into categories, or abstracting essential characteristics.

>Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage.
But they are NOT animals. If you try to use analogies, please don't use them for reasoning, but just to illustrate difficult concepts.

With exception of this incoherent point I enjoyed reading your posts!

>java codemonkey poojit cope
write in a functional language for a living like a real man

There better be hiding a cock behind those pants or I'm going to be really disappointed.

Functions only behave that way if they're purely functional. These languages are imperative, so the functions can have side effects.

I think he criticize the fact OOP push into having bad programming habits. People won't think again about using functional programming and simple structures but heavily rely on objects.
I don't know how much he hates OOP, but I think on some occasions it can be okay to use it.

oop > functional programing

Attached: oop.png (1000x1132, 58K)

I'm a faggot who sucks cock.

OOP in and if itself is not bad at all.
The problem is the way the most pipular languages which support it (Java and C++) do it.

I hate OP for being a disgusting pedo scum.

This is all just cat-v sperging, ignore.

In my opinion, while not a problem with OOP itself, a sad side effect of OOP is that it tends to lead to code-oriented, rather than data-oriented designs.
In order to provide different functionality and keep it "extensible", you start getting massive inheritance hierarchies and the like where an appropriate data structure, such as a hash table, would do.
Take this example: csis.pace.edu/~bergin/patterns/ppoop.htm
I hope it's satire, but if it isn't, oh boy.
Why not use a table to look up values instead of such an abomination?

But even then, data and functions are a lot closer than most people realize.
Pure functions in particular can be thought of as tables mapping inputs to outputs. Not much different than using a dedicated structure to hold values.
And data? In terms of the language used, you can think of it as "whatever is returned by an appropriate constructor function", therefore making data functions as well.
Of course, the distinction becomes more apparent once you throw side effects into the mix.

Gay.

BUT, in a project based on OOP you must then implement the stuff that doesn't need it as OOP as well or risk total and absolute spaghetti

Car car = new Car();

Attached: 1462191785500.jpg (640x360, 28K)

>Procedural programming is the same as functional programming
Fucking retard

explain

basically this

Circle circle = new Circle();

Attached: 1487490049583.jpg (250x187, 21K)

Spaghetti code bullshit for fucking non-programmer "designers" to lead programmers into a rat's nest of untraceable calls leading everywhere that is nearly impossible to debug and understand.

Circle circle2 = new Circle(circle);

Attached: 49c133afa693fcddb839318ebe8ef7eda6ea555164c1c4cd89302a869decb5f7.jpg (359x347, 23K)

Instead ask why people *like* OO.

OO allows you to transcribe what you encounter in the problem domain into code without giving it too much thought. For very simple problems (and most programming is dead simple) this can already nearly solve the problem at hand.

Also, this makes it (unironically) great for teaching as it lowers the "I'm too dumb to even get started" threshold considerably.

The problem with OO then comes from the fact that most programmers (and it is, in fact, *most*) never grow out of the "oooh, I already know how to get started" mentality. Hence the saying "Days of programming can save hours of planning."

That's basically it. Nothing inherently wrong with OO if used properly. But in that scenario most of its perceived advantages go out the window and you might have been better off using something else.

that's not what spaghetti code means...besides read some production code pre-OOP takeover. Extremely deep call stack of many many methods each with their own questionable state.

>geters and seters
whew lad. Just make them public!
Also get a job. Setters and getters in pojo is good thing.

It's the equivalent of spaghetti code -- code that is so fucked up and has no actual readable flow to it that one is unable to easily read its intent.
>deep call stack
And the answer to that is to sanely refactor that procedurally, not make it worse by making everything a fucking object and creating a labyrinth of shit.

>me anxiously awaiting the arrival of circle3

Attached: goosed.png (437x480, 287K)

>all other objects that want to use this data structure must inherit this object.
That is not how inheritance works and not how you should do what you are describing. It seems you know nothing about oop

Circle circle3 = new Circle(circle, circle2, circle2.radius - circle.radius);

Attached: Aminoappscompageanime8138815ahegaosunday+_ecdb176e134cc8ae41341899102401d8.jpg (450x518, 119K)

spaghetti code in particular refers to bad control flow. eg. abusing GOTO, loops with overly complex counter manipulation.

Ravioli code is when you have clean OOP classes but your program as a whole is difficult to comprehend.

Lasagna code is when your OOP classes intertwined to a point where changes in one class breaks the whole system unexpectedly.

Circle Circle = new Circle(Circle.class);

Because OOP is a faggot

In C++ this is just
Circle c;

Circle c();

No
Learn C++

>Most things don't need to be implemented as OOP
everything can be implemented in OOP.
the problem with OOP is that people write ugly procedural mess and blame OOP. they do job they aren't qualified to do.

I'm hungry.

Because OOP is a faggot

Because it is hard.

fpbp

>It's difficult to tackle because a lot of it isn't wrong per se

Attached: 1528819176171.png (894x894, 473K)

And that's a bad thing.

No it isn't

It should be Circle c{};. The Circle c; should be deprecated for nontrivial ctors.

>deftype day() = 1..31.
range of valid days of month is dependent on the month and year

Plenty of my co-workers also making over 200k hate the java packages they have to deal with every day, and aren't that fond of OOP.

Attached: alignmentsmiley.jpg (640x638, 40K)

Because it's God-tier for analyzing scientific data and creating statistical models.

t. undergraduate research assistant at my university

Pajeet and his design (anti)patterns. Functions often aren't first class objects. The reality of cross-cutting concerns.

Over-reliance, not everything needs to be done in an object oriented style.
Certain applications greatly benefit from objects, certain applications do not.
Remember RTRJ.

>while actually making no fucking sense whatsoever to anyone familiar with the material
maybe you're just a brainlet-
makes perfect sense to me.

Because they have never seen a venus mons pubis in real life after being born, let alone cumming on one.

FizzBuzz Enterprise Edition
github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition