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.

[Added]

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

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.

Moving toward object oriented concepts means moving away from other concepts. Most notably, it tends to move away from functional programming. Functional programming is much more strongly related to reusable software, focuses more on what is getting done rather than the things being manipulated. Sciences and mathematics tend to be easier to develop and maintain using functional languages. Fortran (amazing language for calculations), Lisp, Wolfram (the language of Mathmatica), and R (a statistics language) these are languages used by scientists that push away from object oriented "nouns" of doing things and tend instead to be "verbs" of doing things. Even languages like SQL tend to be function oriented rather than object oriented.

There is an expression that when all you have is a hammer everything looks like a nail.

If your only experience is in languages like Java that is heavily based on object oriented principles, C# and C++ that are strongly but not fully entrenched in object oriented camps, then you will only have the one tool in your toolbelt. Your languages are all hammers, and you haven't learned any of the amazing other tools out there.


It is not that object oriented programming is bad, so much that there are so many other excellent options out there yet too many programmers learn one or two languages, mastering how to use two different types of hammers, and never look around the shop to discover the wide collection of screwdrivers and lathes and drills and saws and other tools. All they have is a hammer. They may be really good at hammering, but other tools may provide better solutions to a problem.

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.

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#.

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.

Are you shaking your head in disbelief yet?

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.

And how about interoperation? How about implementing code libraries?

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.

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.