Stop Writing Classes

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

Stop writing classes is one of my favorites. Also many pycon talks are great, or any talks by Brandon Rhodes. ▶ this video

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 think you're thinking of Jack Diederich's talk "Stop Writing Classes". You can (and should!) watch it online here: ▶ this video

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 .

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

I read this book: link While doing these labs: link Also a colleague made me watch this from Jack Diederich: ▶ this video

Hickey gives great talks, but I also really liked Jack Diederich's talk "stop writing classes" at PyCon 2012 ▶ this video

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

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

Its onlt recently that classes are embraced by python community. Before that dictionaries where seen as pythonic and classes where not. ▶ 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.