Brian Will makes the case for procedural programming over object-oriented programming, arguing that OOP's promised encapsulation and decoupling are largely illusory. He analyzes real code examples and the problems of tying data to behavior in classes.
Why Hacker News points people here: HN returns to it as the go-to critique of OOP, recommended for explaining the costs of abstraction better than most written arguments.
“I highly recommend this video by Brian Will who does a much better job explaining this problem than I could.”HN comment, 2017
“I highly recommend this video by Brian Will who does a much better job explaining this problem than I could.”
Explains problems with encapsulating data and behavior in classes.
Full comment
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
Strongly recommendsjmulhoDec 2019
“Brian's other (not controversial) videos (dozens) are excellent for learning about programming.”
Argues design-pattern books are not worth years of effort; Brian's videos excellent.
Full comment
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!"
RecommendsthunderbongMar 2016
“honestly, it rings too close to my experience. Need to think about this a bit more deeply!”
Resonates with commenter's experience of OOP's problems.
Full comment
Previous videos Object-Oriented Programming is Bad this video Object-Oriented Programming is Embarrassing: 4 Short Examples link I'm watching the 'is Bad' one, and honestly, it rings too close to my experience. Need to think about this a bit more deeply!
RecommendsNegatioNMar 2017
“I liked Rich Hickeys talk "Simple made Easy" [1] and "Brian Will: Why OOP is Bad" [2]”
Supports view that OOP magnifies design problems.
Full comment
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
RecommendshackitsMar 2017
“One of the video that can articulate the whole thing better than me is”
Articulates the case against OOP well.
Full comment
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.
RecommendslazulicurioOct 2019
“The blog post and related youtube videos are pretty interesting as well[2][3][4].”
Pretty interesting videos on state in OOP.
Full comment
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
RecommendscrimsonalucardDec 2019
“Take a look at the following video”
Criticism of OOP that applies to design patterns.
Full comment
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.
RecommendscxrJun 2020
“It's both thoughtful and thought-provoking, although I don't agree with the conclusion.”
Thoughtful and thought-provoking video essay on OOP.
Full comment
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
RecommendszamalekMar 2022
“Here's a really popular video that touches on many of the contentions”
Popular video touching on many contentions against OOP.
Full comment
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
RecommendsDeathArrowMar 2022
“For those interested in something better than OOP, here's a few links”
Offered among alternatives to OOP.
Full comment
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: linkthis videolink
RecommendscloogshicerMar 2022
“A lot of my thoughts are summarized well by Brian Will in this video”
Summarizes the costs of abstraction well.
Full comment
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
Recommends_dain_Dec 2023
“This video has a pretty good breakdown of how the "encapsulation" and "decoupling" promised by OOP is mostly a mirage”
Breakdown of how OOP's encapsulation and decoupling are mostly a mirage.
Full comment
This video has a pretty good breakdown of how the "encapsulation" and "decoupling" promised by OOP is mostly a mirage: this video
RecommendscutlerNov 2024
“OOP is an industry of its own which generates a ton of incidental complexity.”
Argues OOP generates incidental complexity.
Full comment
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 ).
Cites itfenesiistvanFeb 2016
“Brian Will says that that whole OOP concept is bad”
Brian Will argues OOP is bad.
Full comment
Brian Will says that that whole OOP concept is bad (not to say about C++ which is OOP in the ugly way): this video
Cites itfogettiDec 2018Full comment
You are implying that the causation goes like this: redux good -> so the app will be good too. And to make a case in point you are trying to make an argument that because many apps are poorly designed, everyone should use redux. You really can't see how fundamentally broken is your argument? Really??? And you are not the only one who makes this HUGE fallacy. All the redux/react fanboys are like you. At this point I already consider those people who make these arguments that they are just following/using redux because it's a religion for them. Not to mention the fact that some people considers the whole uni-directional message flow a HUGE antipattern. See: this video
Cites itRumperuuMar 2019
“Brian Will of “Object-Oriented Programming is Bad”[0] fame”
Brian Will's earlier anti-OOP video, cited as background for his follow-up.
Full comment
Brian Will of “Object-Oriented Programming is Bad”[0] fame presents ‘a positive case for an alternative’, or a ‘prescription for how code should be written, rather than how it shouldn't .’ [0] this video
Cites itnooberminJul 2019
“May be this is just in my head because I recently discovered this talk (ignore the incendiary title)”
Recently discovered talk that prompted rethinking OOP.
Full comment
I'm not a systems designer, so I am somewhat ignorant to make this statement, but this sounds almost like "nouns-first" is the right thing, but almost every single one of those people cited in the article are anti-oop people. Moreover, OOP has generally fallen by the way side and been blamed for unnecessary complexity in some legacy systems from the 90s/00s. The moment you conceptualize your system as the interaction of concrete data types, OOP starts to seem like a logical paradigm to choose. May be this is just in my head because I recently discovered this talk (ignore the incendiary title): this video
Cites itzackmorrisNov 2021Full comment
Engineering within the wrong paradigm can kill your product. I see far more problems on a day-to-day basis with patterns and anti-patterns taken too far. For example, I never use the factory pattern, because it leads one down the Java road where everything ends up an object with mutable state. Which isn't scalable over some metric (like a million lines of code) because a human brain can't trace execution, even with a debugger. A far better pattern generally is to take a functional approach of accepting data, swizzling it, and returning the resulting data without mutability or side effects. Another really bad pattern is when execution suspends and resumes somewhere else (goto hell). Any project which uses queuing, eventual consistency, promises, nonblocking streams, even basic notifications or things as complex as monads will encounter this nondeterminism and inability to statically analyze code. Note that pretty much all web development suffers from some aspect of this due to its async and multi-signaling nature. So what I do now, which I don't see much these days, is solve problems abstractly in a spreadsheet (pure functional programming), in the shell (the Actor model) or as a flowchart (declarative and data-driven design), and then translate that to whatever crappy language/framework I have to use for the project. I find that today, roughly 90% of developer effort goes to discovery, refactoring and testing of ill-conceived code. Only 10% is "actual work" and that's probabl
Cites itimbnwaJul 2022
“Brian Will's procedural programming recommendation contra OOP in his classic 'Object-Oriented Programming is Bad'[1]”
Classic video recommending procedural over OOP, compared to Agile.
Full comment
I find an uncanny correspondence between the recommendation given here, following as it does from an interpretation of the Agile manifesto, and Brian Will's procedural programming recommendation contra OOP in his classic 'Object-Oriented Programming is Bad'[1] [0] this video
Cites itmuixoozieFeb 2025
“he has a series basically ranting about this.”
Series ranting about needless abstraction with simplification examples.
Full comment
Lol Reminds me of Brain Will's this video he has a series basically ranting about this. One of them he goes into examples simplifying needlessly abstract code.
