Some programmers actually hate OOP languages? WHAT?!

Recommended Posts

Hello everyone,

So today I was watching this stream about making a games from scratch. And he was talking about OOP and how bad it is. Now I did not fully hear what he was saying, because I tuned in to the stream a bit late, so I missed the beginning of his talk. But from what I understood is that OOP is bad.

So I went ahead a Googled "object oriented programming languages is bad" and I was shocked that there are people who actually hate OOP. Now I'm not that experienced in programming. I graduated from college three years ago and I only have five years experience in programming. Its not a lot but I would say I'm an ok programmer. Now in all these five years of programming I have only used four programming languages, C#, Java, python and C++. My favourite one out of all four is C#. Its easy. It has a nice syntax and overall its served me well.

So my question is, How and why do some programmers think OOP is bad? and why do some say if you are using OOP you are a bad programmer? I don't understand since every language I have used is OOP based and that's what I was taught in college. It absolutely makes no sense to me.

I'm really confused. Can someone more experienced than me please explain?

Do these programmers hate OOP because of a genuine reason or is it like your grandpa when he would say "In my day we used to do so and so, but now you kids have it easy". is that it. I'm genuinely confused.

for anyone who is interesed in hearing what Casey actually said about OOP here is the link. He starts talking about OOP at 12:00 min and then stops then starts againg at 18:45 min

Edited by FantasyVII

Share on other sites

Some programmers may only know how to program procedurally (as in just a bunch of functions of subroutines), and baulk at the amount of code they have to write to do something simple with OOP.  You have to be much more disciplined to write OOP (or it forces you to be), but there are massive advantages to it, which may not be obvious.

This is how I felt moving from non-OO basic to C++ years ago, no idea if it is still relevant today.

Share on other sites

Object oriented programming is not a feature of the language. While some languages are better oriented toward encapsulated objects, a specific language is not required. You can use C, Fortran, Cobol, and even assembler in object oriented programming.

Object oriented development means, effectively, that your code is oriented toward objects, that is, specific bundles of data and operations done on or with those bundles of data.

There are many other paradigms that work well with objected oriented programming. Event-driven programming works well, as you are passing an object called an event. Automata families like finite state machines and related paradigms can work very nicely as objects.

[...]

You write that you have learned four languages, but all of them are closely related to each other and have a strong basis in object oriented development. It is commonly recommended that developers should try to pick up another language or two every year to help stay current and to develop new skills. Since you currently only have those few procedural languages under your belt, I'd recommend picking up another language, perhaps Clojure or Lisp or R, just to get an introduction of a different side of the programming workshop.

Wow, I actually feel stupid now. I didn't know there are other paradigms than OOP. Well I did know but I thought they were obsolete and no one uses them any more, I have a lot of research to do.

But from what I understood is that OOP is bad.

This is partly because people don't actually understand OOP. It's taught terribly in schools, utterly misrepresented in books and tutorials, and so on. Over-reliance on inheritance, poorly-structured classes, bad inter-dependencies, oodles of abstractions and interfaces that hide what's really going on... OOP isn't bad, but a good amount of OOP code is very badly written.

[...]

You say your favorite is C#, so F# might be a great introduction for you to a more strongly functional language, though you can write in a pretty functional manner in C# itself (you've probably already done it without realizing it).

I will make sure to check out F#.

Share on other sites

Two main points:

#1:  OOP programming languages are a fad, and to many programmers, a religion.

#2:  A great many programs and applications can be written without objects of any kind.

Having said that, I'll make a couple personal comments.

#1:  I absolutely loathe OOP programming languages.

#2:  Most but not all the programs I write are chock full of object oriented aspects.

Perhaps the best way to explain this [perhaps] seeming contradiction is the following.  I absolutely loathe other people telling me what to do, and how to do so.  I absolutely loathe other people forcing me to do things "their way".  I also absolutely loathe putting application-specific mechanisms in programming languages.  I also absolutely loathe "hiding", which is not absolutely necessary in an OOP programming language, but they all are (that I know of).  I also absolutely loathe staring at code that I can't understand without needing to read 65536 to 4-billion lines of header files and other code.  I also absolutely loathe completely bogus, unreadable, incomprehensible operators... instead of completely readable, comprehendable function names.  I also absolutely loathe having 50,000 code libraries that don't work together, and have 148,000 "approaches" (yes, sometimes several approaches per code library).

Shall I continue?  Because I could continue for hours!

Here is another very relevant way to express the above.  My programs are chock full of object-oriented aspects, and I have no trouble whatsoever implementing those aspects myself in conventional C code.  And when I do implement OOP aspects in my programs, my programs remain completely readable and easy to comprehend.  I also don't need to learn enormous quantities of obscure syntax and methodologies (that are often not applied uniformly by everyone).  I can implement OOP aspects in plain old C code quite happily, BTW.  And each is appropriate to what I need to accomplish, not some attempt to hyper-generalize until cows turn into leptons, making everything sooooo general that it is chock full of clutter (required to be ultra-general), chock full of hidden or difficult-to-learn assumptions (sometimes to make hyper-generality even possible or workable).

KISS.  Keep it simple, stupid!

I can do everything... EVERYTHING... with C that anyone else can do with C++, and my code will be simpler, faster, more readable, more reliable, easier to modify, easier to collaborate with others, easier to document, and just plain better.

Why?

KISS.

The short answer is, I can do absolutely everything with:

#1:  statements
#2:  variables
#3:  operators
#4:  functions

Did I forget something?  Probably one or two.  Maybe you don't think of "structures" as being variables.  Maybe you don't think of "structure declarations" as being "types".  You can argue the C language contains a few more kinds of gizmos, but frankly, very few.

?????  WHAT DOES THIS MEAN  ?????

This means I only need to know (or remember) how statements work, how variables work, how operators work, how functions work... and THAT IS ALL.

Well, guess what, noobies?  If you do everything with only half a dozen very simple and fundamental mechanisms... ALL DAY, EVERY DAY... you not only learn them thoroughly... you habituate them very quickly and thoroughly, so they become like "how to breath".  You do not forget!  You do not get confused.  You don't need 37 ways to walk, you just freaking walk.

They are pretty much all exactly the same.  They are a huge pile of functions.  PERIOD.  Everything works the same, because they are all functions, just like the functions in your own programs, and just like the functions in other libraries.  And when you look at a function declaration, you understand it.  Some arguments are inputs, some arguments are outputs (the arguments passed by address without "const").  And you KNOW how every single one of them is passed... either the value of the variable is passed, or the address of the variable is passed.  Just look at the type of each argument.  The value of "int" or "double" or any other type argument is passed directly.  If you see one or more "*" as part of the typename in function declarations, you know the address (or the address of the address, etc) of the argument is passed.  So argument type "int*" means the argument is an address (pointer-to) an int.  And so forth.  You know what's happening.  With C++, you don't even know what a reference type is, because they reserve the right to hide and obscure that (and millions of other aspects of "what's going on" under the covers where you cannot see, or even if you can, it may change next Tuesday).

I'm gonna stop here, because I know there are already at least 256 hit men trying to figure out who I am, so I can be "taken out" for my atheistic views of the world, and especially for wanting my life to be simple, yet utterly flexible.  Religious freaks hate thinking like mine.

Just for the record, I learned C++ before C.  I just hated C++ so much, I decided to give C a try.  It was like removing 65536 scorpion stingers from my brain!  What a freaking relief!!!  You cannot even imagine.

Nonetheless, the fact of the matter is, humans can learn, habituate and even love just about anything, including horrific abuse.  So if you do learn to program in C++, you'll eventually habituate some way of doing things in C++ (there are about 143-million ways, and roughly 1 way to do things in C, not counting trivia like "which style comments do you prefer").

BTW, if there are any advantages to C++ (and I'm sure someone can concoct some convincing-on-the-surface examples), the totality is absolutely, definitely, certainly much more complex and problematic with C++.  Best things about C is... it works the same for 30 years, and it will work the same for another 30 years unless some C++ lover decides to "destroy C from within".

Perhaps the biggest lie of all is... C++ is better for "large programs" with "lots of contributors".  Boy is that the opposite of true!  Holy smokes!  You know how to know this is a total line of BS?  Easy.  Do you think a group of programmers who do everything with 6 simple mechanisms ALL THE TIME (with zero to nothing hidden away out of sight) can work together and understand each others code easier than a group of programmers who adopt varying subsets of 87 mechanisms and 93 non-compatible class libraries?  Hahaha.  You guess!  The additional proof is this.  The way to write good, solid, reliable C programs is the same today as 20 years ago.  The way to write good, solid, reliable C++ programs has not been invented yet, but thousands of people (who claim C++ is the greatest thing since sliced bread) will swear on a stack of bibles that THEIR WAY is the best way in the history of the universe.  Decide for yourself which you suspect is true.

And good luck!  You're gonna need it!

PS:  If you love to be loved, and hate to be laughed at... you must adopt C++.  That's for certain.  If you just want to write great code that works for years, and interoperates easily, well, prepare to be hated and vilified by the most vocal self-proclaimed programmers on planet earth.

Edited by maxgpgpu

Share on other sites

OOP isn't bad, but a good amount of OOP code is very badly written.

Then it's partly - as frob pointed out - that there are many other methodologies for programming.

It's funny you say this since much of the OOP diatribe that comes from people like Casey is actually geared towards using methodologies in general. I always hear negative things about mindless programmers following a methodology without thinking. This to me, seems to be a major reason for all the OOP hate. Edit: example.

Edited by Randy Gaul

Share on other sites
For me personally, Casey confuses the way OO is misused (largely due to poor teaching as has been said) with OO itself. He blames OO for the inadequacies in the education or practice of programmers who use OO.

Back in the 70s, people wrote bad code too, but they were just bad programmers. Nobody blamed procedural programming for this.

But don't be concerned that, among professionals, if you use OO you will be laughed out of the room. Its just important to know how to use it well and when to apply different approaches. Edited by Aardvajk

Share on other sites

Functional programming languages are the new hotness these days.  If you read HackerNews, every day you'll see somebody pimping their latest Haskell/Clojure/Lisp/Scala (not much love for F#, oddly) re-implementation of something that was written 30 years ago in C.

On the other hand, OO has been tarred with the brush of twenty years of Enterprisey Java where AbstractFactoryAdapterFactoryFacadeFactories and other such abuse of the Gang of Four design patterns book have been allowed to run amok.  Also, I would agree that object-orient programming is taught in a really awful way, because they always want to fill your mind with the hairy bits that are not terribly useful in practice.  Class hierarchies more than two layers deep are, in my mind, a code smell, unless you are writing a big framework library.

C# is a nice language because it does give you the option of picking and choosing what paradigms you want to support. If you want, you can write straight procedural code, using static classes as pseudo namespaces to let you stick your procedures somewhere.  If you want, you can also write very functional C# code, and particularly LINQ is quite functionally-inspired.  You can also write very OO code.  Or you can do all three in various mixtures to match what you need.

Share on other sites

I've successfully implemented MS COM objects in assembly language.

Like the C++ classes they're based on, they're nice to implement, but a bit bulky... (although that's probably my fault, because the C++ compiler probably does a better job at optimizing machine code than I do). I did find a way to implement virtual method thunking using one less "jmp" instruction than the C++ compiler.

(This is not a joke.. really!)

If the future of MS are the metro-type and unified apps they're bragging about, I'm gonna miss this.

Edited by tonemgub

Share on other sites

Now I did not fully hear what he was saying, because I tuned in to the stream a bit late, so I missed the beginning of his talk.

Just as a small note, all the streams are archived on YouTube (usually it's up roughly a day after the stream is done):

If you miss parts of a stream or want to watch a particular episode again, they're all there.

Share on other sites

Now I did not fully hear what he was saying, because I tuned in to the stream a bit late, so I missed the beginning of his talk.

Just as a small note, all the streams are archived on YouTube (usually it's up roughly a day after the stream is done):

If you miss parts of a stream or want to watch a particular episode again, they're all there.

Yah I know. But when he was talking about OOP he didn't start recording the video yet. It should be up on twitch past broadcast. I should re-watch that.

-----

You know, this thread is an eye opener for me. Honestly just reading through the thread and all the links provided by you guys, I'm actually started to get anxious. Its like when I was a kid and some teacher starts screaming at me for doing something wrong, when I didn't know it was wrong, and instead of teaching me that this is the wrong way of doing things, they just keep screaming at me and telling me how stupid I am (probably not a good teacher to learn from him, but still).

After reading this thread, I'm honestly more scared to share my source code with the public than ever. Because I might be doing something stupid and someone will just come along and start bashing me for writing shit code. 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.

I don't know......

Edited by FantasyVII

Share on other sites

If anyone is making rash, absolute statements like that, then they should not be teaching other people.

More like, if anyone is reducing a quote to an absolute statement, you better not believe it before going to the source first. I'm not even sure what was quoted there, but from what I read/listened of Casey, he does not make such absolute stamements, even if he does say he mostly codes in a different way.

Share on other sites

If anyone is making rash, absolute statements like that, then they should not be teaching other people.

More like, if anyone is reducing a quote to an absolute statement, you better not believe it before going to the source first. I'm not even sure what was quoted there, but from what I read/listened of Casey, he does not make such absolute stamements, even if he does say he mostly codes in a different way.

Your probably right. I might have actually miss quoted him. But I wasn't just talking about what Casey said, I was generalizing that some programmers do hate OOP. I will actually re-watch the beginning of the broadcast and post the link.

For the record. I do enjoy watching his stream. He has been very educational, and I have learned a lot from his videos/stream,

Edited by FantasyVII

Share on other sites

http://dataorientedprogramming.com

- compilation of DOD articles and videos

Share on other sites

There IS such a thing as over-engineering a program (or project of multiple programs) and the clue here might be the original source being someone talking about programming games.  A blanket statement that all OOP is bad is bunk as 'OOP' isnt a fixed definition - and it can be a matter of degree it is used (and frequently abused).

I'm an old school programmer who writes C++ programs as if they were C for my own stuff (hundreds of thousand of lines of code), but had no problem with using a a number of OOP styled libraries (DirectX is organized OOP after all, and I used that for the graphical parts of MY projects).

When you are creating a game, you may NOT have it all designed out to a fine detail, and often WILL have to add/modify things and even rethink the program's processing almost completely, when it didn't work the way you expected or expanded what it was to be.   Alot of OOP stuff does add alot of extra formal coding to implement that style heavily and it takes time that the programmer has little enough of to get the game working  (Ive gotten the evil eye from programmers when I called their programs 'prototypes' when I knew from experience that what they thought was sufficient fell well short of what the product had to be).

So perhaps that original comment came from someone whose programming  work WAS largely 'prototyping', where OOP might NOT be right for what they are doing (timewise) and don't realize that for bigger projects  it has advantages (I recall when OOP was newly out that there were comments/recommendations that for organized projects the few people who controlled the Class sets were critical. To keep from having every other programmer on the project (and his brother) go every which way in the design and willy-nilly change/add Class things because it was convenient.

Edited by wodinoneeye

Share on other sites

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:

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.

Edited by ChrisChiu

Share on other sites

Honestly just reading through the thread and all the links provided by you guys, I'm actually started to get anxious. Its like when I was a kid and some teacher starts screaming at me for doing something wrong, when I didn't know it was wrong, and instead of teaching me that this is the wrong way of doing things, they just keep screaming at me and telling me how stupid I am (probably not a good teacher to learn from him, but still).

After reading this thread, I'm honestly more scared to share my source code with the public than ever. Because I might be doing something stupid and someone will just come along and start bashing me for writing shit code. 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.

Often this is something that goes away with age, but it's also a cultural issue - the importance placed on protecting one's ego.
E.g. In America it's common for people to not want to admit they don't know something - from lying to your friends, saying you've heard of [obscure band]... to dancing around your co-workers questions with qualified stalling like:
"Now I would say... that this system X probably works similar to system Y"
"I haven't used system X. Greg wrote it. You should ask him, or I can look at it with you to try and figure it out".

It's ok to not know things. It's good to know that you don't know things!
"Ignorant" is not an insult, except when it's used to mean that you're choosing not to learn.
If you discover that you're ignorant of something, and then follow up with more learning, then you're now a better person.
Without first admitting and accepting that you need to learn, this self-improvement is impossible.

The internet (and professional software studios) are amazing as they can surround you with lots of really knowledgeable programmers. That's an amazing resource that you can use to become an amazing programmer yourself.
The only catch, is you've got to first admit that you're a shitty programmer. Even me, now, with over a decade making games, I'm willing to humble myself before other programmers if they're more knowledgeable in an area than me. 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.

The second part is learning to accept criticism. The Wikipedia page for that word is a good start in explaining it - that a critique is not a personal attack and can/should be objective. If you get defensive when provided with a critique of you're work, then you're choosing to be a bad student, choosing permanent ignorance over learning.
Sometimes people are bad at providing critique / some people are lacking in tact. These people's critiques may sound offensive, may sound like they're attacking you personally. Just remember that they're really only there to show you where you can continue learning. If they've done this in a seemingly hurtful way, it is not your problem to deal with - it's actually their own problem, their own bad interpersonal skills. They need to learn how to interact with people better ;)
Always assume good faith and mentally translate people's words into the best meaning before taking them to heart. This can mean translating "OMG U SUCK! Why is this code 100 lines?" to "You could have done this with less lines. Ask me how."

Also, when people suck at communication like this, keep in mind that (ironically) it's usually tactful not to tell them, even though without this feedback, they themselves are being robbed of an opportunity to learn/improve their communication skills

Thank you. That was really helpful

Edited by FantasyVII

Share on other sites
OOP allows you to organize the code in rational segments that when properly encapsulated represent black boxes you can interconnect while keeping code coupling at a minimum. It is an invaluable tool for writing maintainable and easy to understand code because the objects we create translate nicely to the concepts in our head.

It is not a perfect tool for every situation though, and most definitely not the best performing solution.  However when building large systems the ability to easily modify and quicky understand them becomes increasingly more important and quickly outweights the performance implications. I could not have imagined making Banshee Engine (which now has little over 200k LOC) using anything else but OOP.

Data oriented programming has been getting a lot of traction recently as it makes good use of processor cache and make it easier to work with vector extensions - both of which can offer significant performance benefits. However it makes your code very hard to maintain and understand but it is sometimes the only solution if performance is absolutely critical. It's not something I would ever use for building an engine but I will use it in performance critical systems (like a raytracing renderer) but even then I will encapsulate it in an OOP abstract interface.

Therefore don't let anyone tell you OOP is flat out bad. It has plenty of uses, and so do other paradigms. For me from a perspective of an engine developer it has proven invaluable.

Share on other sites
This topic is now closed to further replies.

• Forum Statistics

• Total Topics
628290
• Total Posts
2981856

• 11
• 10
• 10
• 11
• 17