This is why we can't have good things

It's all true though

Looks like a load of hipster talk to me, it was all the rage until go arrived.

@nblackburn eh, I've been hearing about composition over inheritance for like 7-ish years, which is basically saying OOP sucks, only use a subset so it sucks less. The complaint isn't new, I'm just young so that's when I started to see it.

read my shirt

Can any of you enlightened ones explain precisely why oop it's an exceptionally bad idea in case of particularly large systems

Saying oop is bad is like saying a screw driver is shite for hammering in nails. Obviously u need to know when to use what. Its a tool, not a religion.

@evilmupp3t true that. The problem was that in the early 2000ers ppl tried to hammer everything into an OOP solution.

@graviton i found this wonderful article about oop a while back that I can recommend: http://smashcompany.com/technology/...

Warning: it's extremely long

OOP is an amazing idea. So good that it got horribly hyped and abused. In particular inheritance turned out to be disappointing. But there's much more to OOP than inheritance, and most of it is common knowledge today so people don't even notice how brilliant it is.

wat

@ElectricCoffee

To you perhaps.

It's because the noobs are afraid of trying something new and they search for these kind of queries just to make themselves feel better about not learning OOP

Actually oop is still researched at university level, where things like model driven development use the basics of oop to create a lot of stuff. But inheritance should not be used too much, but I know that things like polymorphism can be extremely useful, and for polymorphism actually needs some kind of inheritance. (in a static typed language)

@graviton
OOP tries to write programs for humans, not for computers. If you are a programmer you should understand computers and how they like to digest data. It is often said that the compiler can just optimise everything around and translate everything into machine language. That's what compilers do, right? That is true, but a shit essay in Spanish will still be shit when you translate it to English. OOP enforces thinking about computer problems like a human, with entire encapsulated objects, instead of like a computer, which 1. Abstracts the actual problem and introduces unnecessary workarounds to fit the OOP mindset and 2. Makes the processor take unnecessary detours because it has to work in a way that it actually does not like to work in.
OOP just seems easier at first glance, because we can easily picture the data that we are working with. But these constructs introduce so much unnecessary stuff into our program, that it will get increasingly hard to tell what is essential.

2/2
"Data-oriented" programming might take a while to get used to and it takes a while to get used to this way of thinking, but it is actually much more straight forward than OOP, because all this paradigm say is "think about the data relevant to your problem and how to process it" which is all what programming should be.
And you do not even have to abandon objects at all, only the way you describe them in your program. Let all the data of all instances of a certain class be stored in arrays and let an object be a collection of indices into these arrays. Whenever you need to know something about an object you can look it up in the according array. But your objects are much smaller (just a few ints) and because the data of many objects is stored all in one place, it is made really easy for the cpu to process a large amount of objects because you do not have to change state as often and you are not storing any irrelevant data in cache.

@stimulate you make good points. You say that oop is that you can think about it more easily, but the performance goes down. But if performance is your goal then sure, go develop in assembly, directly what the compiler can execute. I hope that you don't do that. But non oop languages, oop languages all abstract some information away from you, this can be more or less in certain ways. In oop this is actually more that for non oop language.

So if you are programming something very complex, what is the in lot of advanced programming applications, why do want to do that in a non oop way??

If it were simple then sure, but were talking about complex applications like 100KLOC. Yes, the compiler has to do more, even the cpu has to do more when working with oop, but I think it will outweigh the fact that the code is easier to understand and with that has less bugs in it and is developed faster(for 100kloc projects).

I say let the computer work for you, not the other way around.

@stimulate btw, in some cases, like on the gpu, it is actually necessary to change the thinking in data oriented. So it is necessary in some cases

@micfort
OOP does not actually make it easier to understand what the code does. It only creates inaccurate pictures which makes it easier to think about the problem. But this is what I use a pen and paper for.

As I said, OOP seems easier at first glance, but it actually makes things more complex than they already are, because you are introducing things which are not actually there.

When you have a problem, you can make it less complex by reducing the amount of variety there is, so you encapsulate things which work together and use these concepts to think of a lot of things with only a few "classes". This can be useful to find a solution, and you can easily find the steps which are necessary to take that way. But please do that on paper and don't make the computer think that way. OOP makes it possible, but this shouldn't be what we are aiming for.

Once you have thought of the problem as abstractions and know what you want to get to and have an idea of what steps you have to take, you will have to break these abstractions and steps down to what they essentially are. A complex problem will always need you to deal with a complex problem and you can't make a simple one out of it. You can of course for the sake of finding a solution, but the solution itself will always be as complex as the problem.

@stimulate if I understand you correctly, you mean that by encapsulate function together to make some kind of module, but isn't that the same as using oop(except for the inheritance part), but the data is managed differently.

Stil, programming is creating abstraction from the original problem. This is also the case with languages. Especially when dealing with DSLs. How the compiler/parser/transpiler uses that, that is their domain. So if you use an non oop approach, then there is stil some kind of abstraction. In case of oop there is even more abstraction. When more abstraction is introduced the expressifness is increased. Which increases the overview of the problem. And yes you don't have a complete picture, but that is exactly the point of introducing abstraction.

And oop concepts already exist in a lot of problems, look for example at business applications. A employee is a object.

So I disagree that you introduce new concepts, but only better describe the original problem

@micfort
Non OOP programming does not say you shouldn't use data structures to represent objects. But it tries to only encapsulate only as much as is needed. OOP puts everything into objects, which is not only hard to handle for computers, but also makes it easy for the programmer to encapsulate things together which actually do not have that much in common, even though they might relate to the same concept.

Let's keep the example with the employee. A real life employee is a person with a name, a salary, a position in the company and he might finish a number of assignments per month, which are another concept/class for themselves and might have and amount of hours they have been worked on, a value, a name, etc.

Now the OOP way of structuring these concepts might be to first make a class "Employee" and "Assignment". Each employee stores his salary, his name and an array of assignments he has finished this month. Each Assignment structure in this array will store it's time it took, its payoff, and so on. Now this might be very easy to think about all at once as a concept, even if it was a more complex concept, but if we have a few thousand employees with a few hundred thousand assignments each month and they all have to store detailed information about the task and the employee, it will simply take a long time to update all this data for each employee and assignment.

But if we simply represent an employee by an integer, we can actually have a nearly endless amount of arrays of data about each and every employee. We have an array of all employee names, all salaries, hours worked and so on, and can access them with the employee ID. And whenever we are updating any of these things, we do it for all employees once, and we do not have any unnecessary data in cache.

In order to store multiple items for an employee, say Assignments, we simply introduce a reference structure, for example "AssignmentRange" which stores a count of assignments and an offset into a huge array of Assignments. When we update the assignments we simply get the AssignmentRange for each employee and use that to find the assignments of that employee in the array of all assignments.

We would actually give each employee a range in an array of indices into the AssignmentArray. This way multiple employees could be assigned to the same assignment without having to store it twice.

Once you get used to a coding style like this, it is actually not as confusing as OOP can get, because you are not forced to think in terms of "employee does that" "employee gets changed by X" but rather in terms of "move data X to Y", "change salary of employee X by Y", which is much easier to debug.

You don't actually have an employee in your computer which gets a salary and is working in the assignments, you only have many employees and many assignments and you represent the relations between them with simple integer links.

@stimulate yeah, it is true what you say. That way your code doesn't have as much useless information in the cache. But this is actually what relational databases does, they just have simple arrays of data that can be joined with indexes.

It is faster, but I think that this is not an issue with an oop language. Because if you model the language it is possible to translate an oop language where you have these kind of issues to the kind you describe (in an automatic way).

You're was also talking about concepts that are joined together because they seems to be connected to each other. This is actually true for any paradigm where you do modularisation. An interface of a library is never as good as implementing a custom part yourself. In a library interface things are also joined together.

This is an issue of view and requirements. Is it necessary for the employee object to to store everything it does, or only how much workload it has. This is something how you use any modularisation technique. And this is something that needs training and experience to make it good enough in for your case.

@micfort of course everyone has to find the tool for his job and I believe there are many applications which are either small enough or only run occasionally so that OOP gets the job done faster, but I am working on a game engine right now, and that is why OOP is just not at all fit for me. And you are right about what you say about libraries, I also prefer to write everything myself (down to a certain level) because it will work much better and with most libraries it takes much longer and is much more frustrating to learn them than to write the same functionality step by step by yourself.

Anyways, maybe I will find my way too OOP some day, but until then I honestly hope that more people will see the problem with it. But I guess am way to inexperienced to judge it yet.

@stimulate btw, I'm sure that oop isn't the solution to everything, that is also the reason why things like aspact oriented programming or feature oriented programming are introduced. But they are not taking off yet for number of different reasons.

For speed, yes of course the idea of arrays of structs is definitely slower then struct of arrays. Then the number of caching ia definitely lower. (on the gpu that is even more so then on the cpu)