8 HN users recommended this talk8 months2012–2025score 10
Years with an HN recommendation, 2007–2026
HN returns to it repeatedly as the canonical argument for simplicity and against premature abstraction, and several commenters say it changed how they write code.
Jack Diederich's PyCon 2012 talk argues that classes are overused in Python and walks through real code, refactoring away unnecessary classes, exceptions and modules. It popularized the heuristic that a class with two methods, one being __init__, should be a function.
“Jack Diederich has a great video called Stop Writing Classes: It's about Python, but the observation can apply to several languages.” (HN, 2020)
Stop writing classes - Jack Diederich - [this video] Show them this. I'm still grateful for the moment I grew dissatisfied with OOP, or at least OOP in the Java/C# way. I was almost getting to an intermediate level in python (by myself) and had been thinking about a video game architecture problem I just couldn't solve. I was still "indoctrinated" in the gang-of-four patterns and inheritance. When I discovered the solution, Entity Component Architectures[1], I also discovered the "composition over inheritance" philosophy. My mind was blown! Coupled with some Python's characteristics (duck-typing, everything is public, first-class functions) I was having a blast. Then I saw the video above, and all fell into place. Class based OOP have specific uses, but It's a shame how heavily enforced the paradigm is. “Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function.” – John Carmack Now, for scripts or not-to-big programs in Python, I mainly use NamedTuples for passing data around and (mostly) pure functions. P.S. Another funny thing: At my job I use J2EE aka "lots of hinheritance and classes and boilerplate". Sometimes I just have to go home and write some code in python or lua to "cleanse my palate". It helps me get motivated for my personal projects. [1] [link]
I also tend to avoid writing many classes (in Python). Jack Diederich has a great video called Stop Writing Classes: [this video] It's about Python, but the observation can apply to several languages. Pithy quote: "I hate code and I want as little of it as possible in our product."
Reminds me of this talk, "Stop Writing Classes": [this video] Changed my perspective on this newfound tool I'd learned to use called "indirection". My favorite quote is something like "don't waste 10 minutes now to save yourself 2 minutes later".
Yes, the standard library has a lot of questionable design (some inspired by Java, some by C), and many programmers overuse classes. I'm a fan of (former core dev) Jack Diederich's talk, [this video] .
I like this trend towards values instead of objects, Rich's talk is really worth watching too [link] . Using this approach in UIs is stretching the idea even further into a realm where I previously thought OO had a sweet spot. I still like to convince myself, though, as to why this approach makes sense over the traditional OO / encapsulation approach. My current line of reasoning is that while having well defined services and interfaces can help organize a software system, the actual arguments and return values of these end points are really better thought of as values - and the expected structure of these values can certainly be part of the API. You just don't force people to construct and destruct objects for everything you are passing around. A couple of related resources on this topic: "Stop writing classes" from PyCon [this video] Rob Pike's reflection on using data vs OO: [link]
PyCon talk on classes versus plain data and functions
"The signature of 'this shouldn't be a class' is that it has two methods, one of which is __init__." [0] Why not write a function? This addresses all of the objections. Then refactor by pulling out concerns into other functions. Need to share logic around the functions? Use a decorator. Passing too many attributes? Create a class to contain them. I think classes are best avoided until it's obvious that encapsulating state provides a benefit, which I don't see in this case. [0] [this video]
Source of the two-methods heuristic for when not to use a class
Growing a Python codebase like you would a Java/C# one (i.e. with tons of classes, interfaces, factories etc.) is a sure way to pull your hair out. However, Python provides a bit of metaprogramming that could drastically reduce the number of LOC needed, should you write it in a Pythonic way. That is, experienced Python programmers could write concise and performant Python code in less or at worst equal time as experienced Java/C# programmers. But if you hire Java/C# devs to write Python code, I can see how you could arrive at your conclusion. Bonus video: [this video]
Bonus video on avoiding Java-style class bloat in Python
Also known in python as "if your class has only two methods, one of which is init, it's a function" in the "stop writing classes" [this video] EDIT: typo, changed link
It reminds me of a pycon talk [0] which, while i dont agree with the whole thing, has the message "we ship features, not code". That also reminds me of "when a measure becomes a target, it ceases to be a good measure". LOC is a decent measure, but features are our targets [0] [this video]
PyCon talk message that we ship features, not code
> But my instinct tells me a node will eventually have more attributes and methods. I couldn't agree more with Jack Diederich's thoughts on that sentiment, at 5:40 in the video linked above: [this video] > Lots of times people think they might need something later. You don't. Or, you can just do it later.
Diederich's point at 5:40 about not building for later
“So I spent a week doing OAuth2 stuff. It took a couple days to read through [Google’s] ten-thousand lines of code, so then I went and looked for other libraries. There's `python-oauth2`... it's the second version of python-oauth, it doesn't actually do OAuth2. But that took a while to figure out. So that one was a little bit better, 540 source lines of code, 15 classes, but I wasn’t going to put that in either because it didn’t actually do what I needed to do. So I rewrote that to just do bearer-token authentication, it’s ‘python-foauth,’ or if you prefer, ‘eff oauth.’” -- Jack Diederich, “Stop Writing Classes”, [this video]
"Lots of times people think they might need something later. You don't. Or you can just do it later if it comes up." [this video] For glue code scripts like this you usually don't end up using encapsulation and inheritance or any other fancy OOP design patterns. It's usually grungy IO-bound procedural code, the sort of thing you'd write in bash if bash weren't terrible for long scripts. Don't burden it with premature abstractions. If you end up needing a class, just write the class later.
Quote on not building for hypothetical future needs
I strongly disagree. You should always keep the code as simple as possible and only add abstractions once you really need them. Too many times I've found huge applications that it turns out be most scaffolding and fancy abstractions without any business logic. My biggest achievement is to delete code. 1. I've successfully removed 97% of all code while adding new features. 2. I replaced 500 lines with 17 lines (suddently you could fit it on a screen and understand what it did) Also: [this video]
Supports keeping code simple and avoiding premature abstraction
Type hints encourage this sort of object-oriented design though, in my experience. The resulting code is extremely verbose compared to Pythonic "executable pseudocode". For example, see Jack Diederich's talk "Stop Writing Classes": [this video]
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.
20 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Read more
Citations, criticism and jokes
Read more
Read more