Object-Oriented Programming is Bad

Looking at your top priority books I recalled a slide from one of Brian Will's videos on object oriented programming: "Object Oriented Programming is Bad" ▶ this video . At around the 43:51 he pulls up a slide picturing several of these (and similar) books. Here is a rough quote: "I can tell you from personal experience of having read these books that you don't need to read them. They don't have answers, they aren't going to square the circle, and you are going to waste productive years of your life trying to live up to their ideals." Now that is just one rather controversial opinion, but we are talking about potentially wasting productive years of your life so I wanted to let you know that opinion is out there. That being said, it would probably be hugely beneficial to read a few of those books and then watch a few of Brian's videos (he has three or four on the topic) and sort out your own opinion. Also, Brian's other (not controversial) videos (dozens) are excellent for learning about programming. Also, Steve Krug's Don't Make Me Think is a keeper. I thought of it last night when I was checking out at a store. I stuck my debit card into the thing, entered my PIN number, then clicked the big blue button that said "Skip PIN". The woman behind the counter said "don't worry about it; everybody does that!"

Code should be written first and foremost for humans to understand, and incidentally for compilers to understand. link If we can all agree about that then we have to ask ourselves if encapsulating data and behavior at the granularity of classes makes the most sense for human comprehension. In naive OO examples (Animal -> Cat) it does. In practice however, it's debatable (at best). I highly recommend this video by Brian Will who does a much better job explaining this problem than I could. ▶ this video Douglas Crockford also does a good job of explaining some of the trouble with classes. link

OOP is an industry of its own which generates a ton of incidental complexity. See "Object-Oriented Programming is Bad" by Brian Wills ( ▶ this video ) and most of Rich Hickey's excellent videos, especially his keynote at Rails Conf 2012 where he basically told the Ruby crowd they're doing it wrong ( link ).

This video has a pretty good breakdown of how the "encapsulation" and "decoupling" promised by OOP is mostly a mirage: ▶ this video

Here's a really popular video that touches on many of the contentions: ▶ this video My personal tipping point was the realization that OOP forces you to first figure out how you solution maps to OOP, before figuring out (or iterating on) how it maps to code. It creates nothing more than accidental complexity: link

I think this is a valid critique. But then, most of the development (C aside) has been a victim to OOP. I have begun to think that OOP creates more problems than it solves. Added complexity and performance loss being the biggest. It's insane if you peek into a big projects where many developers came and went and each of them read an article about what it seemed an interesting design pattern and tried to implement them. You can have some kind of procedural programming if you use classes just to store data and use static methods. But the frameworks are OOP and there is no way around that unless you write your own frameworks. I am a big fan of Mike Acton's Data Oriented Architecture speeches, but I didn't find a way to implement something similar in C#. For those interested in something better than OOP, here's a few links: link ▶ this video link

That's fair - I'm not against abstraction in general. I agree that we wouldn't be able to handle the essential complexity of software without it. I'm just saying that each abstraction also has a cost, and makes understanding the whole thing more difficult. Abstraction is, in my understanding, a necessary but costly tool. A lot of my thoughts are summarized well by Brian Will in this video: ▶ this video

At the risk of putting readers off by the title, there's a video essay on YouTube called "Object-Oriented Programming is Bad"[1]. It's both thoughtful and thought-provoking, although I don't agree with the conclusion. Steve Naroff (from Stepstone/NeXT/Apple) did a recent-ish set of interviews with the Computer History Museum[2][3] and referenced that video a bit (and extemporized about objects in small parts throughout). Side note: Naroff and Brad Cox are set to present a paper on Objective-C at this year's HOPL[4]. I wish it were as readily available as Allen Wirfs-Brock's JS paper for the same conference[5][6]. 1. ▶ this video 2. link 3. link 4. link 5. link 6. link

This isn't about OOP vs. FP. This is about OOP vs. everything else. Rust, Go and javascript are three languages that are moving away from the OOP paradigm. None of those three languages are classified as functional. >Is there some resource you can point to that says in the past when faced with situation X developers tended to use pattern Y, these days that has been superseded with way of doing things Z? No. A general trend is an anecdotal observation. Still a quick google search yielded: link Take a look at the following video: ▶ this video While I don't agree with a lot of it, I think it sums up my opinion really clearly. It's not about DP's but because DP's focus around OOP and the video is a criticism of OOP therefore the arguments apply to DPs.

There was an article on state in OOP posted here a few days ago that I found very thought-provoking[1]. The blog post and related youtube videos are pretty interesting as well[2][3][4]. [1] link [2] link [3] ▶ this video [4] link

Prodcedural code can also be well compartmentalized and tested. I was also until recently quite convinced OOP was the only way to go, but I'm seeing signs everywhere that a lot of the design-problems I've met over the past few years are at least magnified by OOP. The abstraction promised by OOP is a good thing, however very few people are able to consistently make good, reusable and maintained abstractions. To the point where it becomes a weakness rather than a strength. I don't want a billion wrapper-objects that obfuscate my code, and makes the surface area of it bigger than it has to be. Often I struggle understanding code more because of how it was separated, than because of the complexity of what it actually does. I liked Rich Hickeys talk "Simple made Easy" [1] and "Brian Will: Why OOP is Bad" [2] [1]: link [2]: ▶ this video

One of the video that can articulate the whole thing better than me is ( ▶ this video ) It was a long winded written rant. I still use OOP but its more or less glorified name spaces with functions. Today I rather work on procedural code than OOP code. It may have bugs, it may have their own little quirks but its like a old rusted vehicle that still keeps going.