Some programmers actually hate OOP languages? WHAT?!

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.

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.

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.

Then it's partly - as frob pointed out - that there are many other methodologies for programming. Even procedural code (e.g. FORTRAN or C) which is often considered a "precursor" to OOP has a lot of strengths in many circumstances (one could even argue that OOP is just a way of structuring procedural code). Functional programming has a lot of advantages. Declarative programming is another under-appreciated paradigm. There's a lot of way to express an algorithm, and each one has different strengths and weaknesses. Constraining yourself to just one paradigm like OOP leads to the classic metaphor of "when all you have is a hammer, every problem looks like a nail."

There's also multi-paradigm languages. C# can be used in a very functional manner, as can JavaScript and C++, though those languages have syntaxes that are better suited to object-oriented or procedural programming. 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).

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.

…I so rock…

The original poster asked for an objective discussion regarding the pros and cons of object-oriented programming, not your life’s story and personal opinions.


As already mentioned, object-oriented programming is just one tool in your belt.
Anyone who broadly generalizes by saying, “object-oriented programming definitely sucks,” or, “object-oriented programming definitely rocks,” is an idiot.


L. Spiro

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.

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.

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.

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):

https://www.youtube.com/user/handmadeheroarchive

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

There is great blog entry where Casey is explaining his coding style.

http://mollyrocket.com/casey/stream_0019.html

a lot of text

I had a bit of déjà vu when I read that and after going back through your old threads I learned why. Back in 2012 you made a thread that's very similar: extremely low on facts but lots of strong opinions, tons of pathos and a good dosage of completely wrong. And the same religious prosecution reference.
My personal advice would be to drop that religious prosecution stuff first. It just screams "nutcase". Unless you really actually believe it. In that case I would advise professional help.

I was pondering for a bit whether I should try to talk about whatever facts (or supposed facts) I could find in your posts but then decided against it. There is so much hyperbole and pathos in it, I really don't want to read it a second time in the hope of finding something to work with. Besides, I'm fairly certain the bug I was hunting is fixed now and I just won't have the time while I wait for my processing step to run through.

In my experience, people who "hate on" OOP fit into these groups:

1) The old guru. You've been programming the same way since 1983 and you resist change. You're proficient in procedural C, or FORTH or FORTRAN and you see no reason to learn anything else.

2) The elitist. You use your choice of language as a filter to form an exclusive club. You feel that 10% of people who program in X are bad programmers, but 90% of people who program in Y are bad programmers. Therefore you must shun Y, in order to keep the bad programmers away from your club.

3) The enterprise defector. You've been raised on Java in a large company, and have been forced to write one too many SolutionFactoryAdaptaorPatternVisitorFlyweightProxyFactoryProviders and other wtfs, with coworkers who buy into this tripe, probably just for political gain within the enterprise.

4) The tried it once-er. You tried learning C++/Java/SmallTalk back in 1998, wrote tonnes of inheritance trees, realized your code was terrible, and decided to forever shun this thing that you barely understood in the first place.

5) The old-school optimizer. You wrote a better version of virtual in C 20 years ago, so now shun all C++ compilers, even though you've never bothered to re-run your tests with modern compilers. You're probably also an old-guru.

6) The hardcore game-dev. You actually understand all the points being made in Mike Acton's rants, and therefore you subscribe to point #2 -- you're sick of seeing bad programmers write bad code, so you want to take away the tools they're abusing.

And he was talking about OOP and how bad it is.

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

There is great blog entry where Casey is explaining his coding style.
http://mollyrocket.com/casey/stream_0019.html

That falls into the straw-man argument category. To paraphrase:
"I don't understand OOP, so based off the badly taught perversion of it that I was using, I'm going to declare that it's all horseshit."

The big staw-man there is he bases all the opening paragraphs on an example where a problem is solved using a faulty inheritance hierarchy, implying that this is the OO way to do things... when in fact OO teaches the opposite of this -- to prefer composition over inheritance -- and thus the opening paragraphs are either ignorantly or deliberately presenting a terrible and/or contrived solution to generate a false impression.

All the ideas he's putting forth in that post can be combined with the useful ideas from OO theory... i.e. they're mostly orthogonal.

It's very arrogant to just dismiss it (and harmful to teach such arrogance to others) because you had a bad experience in the past.

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):

https://www.youtube.com/user/handmadeheroarchive

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

And he was talking about OOP and how bad it is.

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.

And he was talking about OOP and how bad it is.

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,

http://dataorientedprogramming.com

- compilation of DOD articles and videos

DISCLAIMER: I probably fit into several of Hodgman's categories.

I happen to not like OOP, but it's not because of objects: It's because of the second "O". I understand and use objects regularly, but I don't find it healthy to orient your programming towards a particular tool. The name of the paradigm implies that you need to buy into it completely and you can't write any code outside of methods for classes.

There are certain types of programs for which OOP might be a perfectly good solution (making GUIs comes to mind). It so happens that most of the programs I like to write (board game AI is the main example) don't benefit a whole lot from structuring things into objects. For instance, when writing a chess engine there isn't much to be gained from having objects representing the pieces, the squares on the board or the players: For the most part you can use enums or even small integers to identify all those things. For higher-level concepts (the board, a game, an opening book, a transpositions table, an engine...) objects are generally a good fit.

The main strength of objects, in my opinion, is in defining clear interfaces between parts of the code. And that's primarily what I use them for.