One of the more recent common reasons is that OOP or, more specifically, OOD (object-oriented design) often produces code that is not optimal for today's architectures (where the CPU-memory gap starts to widen). An example is a typical "OOP-style" update/render loop, which would go like:

for every entity:
    entity.Update();

for every entity:
    entity.Render();

However, that is really bad for a variety of reasons: virtual function calls are comparatively costly on today's architectures, and the "Array of Structures"-(AoS)-style that is typical for OOP is not optimal for architectures where the CPU speeds have greatly exceeded memory access speeds, so every memory access might, in worst case, stall the CPU for hundreds of cycles. Usually that is where CPU caches come in, but to optimally use CPU caches, memory layout and memory access patterns are vital. For most cases in games (especially concerning game objects/entities), a "Structure of Arrays"-style (SoA) is preferrable, cache-wise.

The performance improvements are not neglegible! (though in some specific game cases, like simpler casual, you may still ignore them since they do not weigh in as much as in more complex games and game worlds)

SoA-style programming is more reminiscent of C-style (non-OOP) programming.

However, obviously you can still use OOP aspects when programming in this more "data-oriented" way. Just don't assume the OOP patterns you've learned in school are silver bullets for everything.

More interesting articles on data-oriented programming:

https://molecularmusings.wordpress.com/2011/11/03/adventures-in-data-oriented-design-part-1-mesh-data-3/

Essentially: don't be shocked, nothing is ever a silver bullet or a solution for everything, and good developers will make use of the tools they know with conscious design decisions and weighing in pros and cons. OOP definitely is not a silver bullet for everything, neither is C++.

Especially, for OOP-trained (I don't want to use the word "brainwashed") people right out of college, getting to know some languages with completely different paradigms, such as functional languages such as Haskell, can be incredibly beneficial in avoiding the OOP "tunnel vision" that is so easy to get nowadays.

Thank you. That was really helpful

I get the feeling this is going to be a long thread.

Hell, even if they're a newbie student who knows some neat trick that I don't, it's worthwhile letting them momentarily be the master and giving them your full attention as an eager-to-learn student.

I can make annoying sounds using only my armpit. :)

(I am joking now.)

Problem is, I will never learn the right way to code from the wrong way if I don't share my code and no one explains it to me.

TL;DR - unless you've been telling everyone that you're the greatest software engineer who's ever lived, you should never feel like that.

. . .

+1!

To add to that:

- Egoless Programming: http://blog.codinghorror.com/egoless-programming-you-are-not-your-job/

- You Are Not Your Code: http://www.hanselman.com/blog/YouAreNotYourCode.aspx

This article sums up my thoughts about OOP: http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end

For an original contribution to this discussion, OOP has all the same problems that global variables and functions acting on them have. Only in OOP instead of a big universe of global, mutable state, you have little microcosms of it. From inside of an instance, how is it any different than global variables whose values can be changed at any moment?

And don't even get me started on abominations like the Singleton Pattern...

Languages like C# have been improving drastically in recent years because they've been incorporating functional programming ideas into themselves. Everything I like about Ruby, it turns out, comes from functional programming.

OOP relies entirely on mutable state, and dealing with mutable state introduces all sorts of headaches, and for no real gain.

And yet, at some point every program does need to deal with mutable state (database, writing to the screen, etc). This talk does a good job of describing a way to deal with that: https://www.destroyallsoftware.com/talks/boundaries.

Edit: change "feelings" to "thoughts" since I don't actually *feel* anything about OOP.

An example is a typical "OOP-style" update/render loop, which would go like:

for every entity:
    entity.Update();
for every entity:
    entity.Render();

Cute, but strawman. Set up in order to be easily torn down.

Thinking of clusters of data as objects is one direction. Thinking of data as a continuous stream of sources and filters is another direction. Thinking of verbs primarily as you do in SQL, rather than mostly nouns and operations on nouns, is another direction.

A better, less strawman condition I encountered recently: When we had a 12 GB data source to rip through and modify, if your thinking is like my co-worker who spends his day in Java, thinking that you need to load a chunck, parse it, make a bunch of objects, then serialize the objects in the other stream, you're doing it wrong. Instead open your toolbox, grab "sed" spend some time figuring out how to code your modifications, and let it work its magic.

Some processing tasks are far easier in other languages or with other tools or with different paradigms. There is good reason Fortran is still the king of numerical computing and the benchmark language/tool for supercomputers. Not because you can use assembler blocks to fine tune performance section, not because it tries to be like C and become a close abstraction of the metal, but because for that type of problem the language is really good at making efficient machine code.

Use the right tool for the job. If the only tools you know are Java, C++, and C#, your collection of tools is too small.

An example is a typical "OOP-style" update/render loop, which would go like:

for every entity:
    entity.Update();
for every entity:
    entity.Render();

Cute, but strawman. Set up in order to be easily torn down.

Thinking of clusters of data as objects is one direction. Thinking of data as a continuous stream of sources and filters is another direction. Thinking of verbs primarily as you do in SQL, rather than mostly nouns and operations on nouns, is another direction.

A better, less strawman condition I encountered recently: When we had a 12 GB data source to rip through and modify, if your thinking is like my co-worker who spends his day in Java, thinking that you need to load a chunck, parse it, make a bunch of objects, then serialize the objects in the other stream, you're doing it wrong. Instead open your toolbox, grab "sed" spend some time figuring out how to code your modifications, and let it work its magic.

Some processing tasks are far easier in other languages or with other tools or with different paradigms. There is good reason Fortran is still the king of numerical computing and the benchmark language/tool for supercomputers. Not because you can use assembler blocks to fine tune performance section, not because it tries to be like C and become a close abstraction of the metal, but because for that type of problem the language is really good at making efficient machine code.

Use the right tool for the job. If the only tools you know are Java, C++, and C#, your collection of tools is too small.

I believe I wrote pretty much exactly the same things you said, and yes, it's a very naive example, but believe me, in my years as lead programmer in various projects, I did encounter that multiple times, both in junior programmers' code, as well as student code (in my time as lecturer).

The link I posted provides a more thorough overview on data-oriented programming and some of the "stumbling blocks" naive OOP might have (also taken from real life, seen as implemented by less experienced developers).