2 HN users recommended this lecture2 months2016–2022score 2.5
Years with an HN recommendation, 2007–2026
HN recommends it as a concrete, worked example of the case against heavy OOP rather than abstract argument.
Brian Will critiques object-oriented programming and rewrites a roughly 3800-line OO program in a procedural style, cutting code and complexity. It is part of a series of OOP critiques.
For anyone unfamiliar, I recommend the whole series, but it also culminates in the presenter rewriting an entire nontrivial OOP program into a procedural one and saving whopping amounts of code/complexity. The big example helps to show this isn't just abstract rambling against OOP. [this video]
Rewrites a nontrivial OOP program procedurally, saving code and complexity
There are three talks, actually. Here are the other two. Object-Oriented Programming is Embarrassing: 4 Short Examples[0] Object-Oriented Programming is Garbage: 3800 SLOC example[1] [0]: [link] [1]: [this video]
This kind of thinking bothers me, but I'm not sure how to put my finger on what exactly it is that bothers me, or how to put it into words. The thing with these abstract architecture principles is they are not always practical if you try to be puristic about enforcing them. I get where these ideals come from. I've seen novice programmers take a stab at writing mildly complicated apps, and the code is a nightmare to read because everything is jumbled up together. This is bad and we can all agree on that. But I've also seen projects where everything is split into a tiny little function or object that don't seem to be doing anything meaningful. Presumably these projects are following the principles of "single responsibility" and "loose coupling", but it's so loose that it's hard to put the pieces together in your mind and nearly impossible to follow the flow of the program. I consider generic rules of the form: "<X> related objects should not be doing <Y> related stuff" to be harmful. (An example of such "bad rules" can be found in the article under the heading "Use Cases") Instead I prefer practical rules that make the code easy to read, understand, and updated, without making it any more complicated that it needs to be. * If a piece of logic can be contained in a function, let it be contained in one function without splitting it across 10 different objects and factories and coordinators. Even if that function is slightly long, there's no need to split it apart just because it'
Brian Will, the guy behind the 'why OOP is bad' youtube video brings this into his argument. In a follow up video to that video he rewrites an OO program in procedural style. In doing so he reduced the number of methods/functions from 321 to 113, 54 of which were contained inside other functions as they were only accessed by the containing function. The total number of lines of code remained about the same. That's over 200 fewer meaningful names to try to come up with in a short program. Plus the fact that functions that do bigger tasks are easier to name in the first place, imo. [this video]
Rewrites an OO program in procedural style, cutting function count
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
4 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Citations, criticism and jokes
Read more