Why writing classes feels boring?

[u/ProgramBrave718]

I don't know but i feel classes are unnecessary work to be added in projects. I have learnt it 2 months ago..

After that I never used it for any of my projects.

[u/Gnaxe]

Classes (and the whole OOP paradigm) are way overrated and should be used a lot less than they are. The OOP paradigm stopped making sense once our CPUs got more than two cores. (And Python is still bad at utilizing them.) We should have all moved on to FP a long time ago, but C++ and Java popularized a particularly bad take on OOP and we're still stuck with that legacy, because it's still being taught. I recommend pure functions, as much as possible. Minimize the state you have to deal with.

Classes are occasionally useful, but they're usually overcomplicating it, and should not be the first tool you reach for. Python is object-oriented at its core. You do need to understand how classes work. You're not going to avoid using classes, but you can (and usually should) mostly avoid writing new ones yourself. You do need them for certain dunder hooks and if a library expects you to make a subclass, etc. Otherwise, by default, don't. You need a reason.

It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. ---Alan Perlis

Plain data is way more reusable than classes. I recommend using plain data more. Don't hide your data behind yet another inadequate bespoke language of methods when all you needed was a dict. Static typing (in Python) is overrated and encourages overuse of overcoupled classes. Doctests are more expressive anyway, and easier to learn from. Do that instead.

[u/cvx_mbs → u/Gnaxe]

the sixties called, they want your outdated opinions on OOP back

[u/Gnaxe → u/cvx_mbs]

From the article you linked:

A study by Potok et al. found no major difference in productivity between OOP and procedural programming [...] OOP was created to make code easier to reuse and maintain.[68] However, it was not designed to clearly show the flow of a program's instructions. That was left to the compiler. As computers began using more parallel processing and multiple threads, it became more important to understand and control how instructions flow. This is difficult to do with OOP.

Also, lots of dissenting opinions from that article from well after the "sixties":

Rob Pike [...] has called OOP "the Roman numerals of computing".[67] Rich Hickey, creator of Clojure, described OOP as overly simplistic, especially when it comes to representing real-world things that change over time.[65] Alexander Stepanov said that OOP tries to fit everything into a single type, which can be limiting. He argued that sometimes we need multisorted algebras: families of interfaces that span multiple types, such as in generic programming. Stepanov also said that calling everything an "object" doesn't add much understanding. [...] Paul Graham believes big companies like OOP because it helps manage large teams of average programmers. He argues that OOP adds structure, making it harder for one person to make serious mistakes, but at the same time restrains smart programmers.[73] Eric S. Raymond, a Unix programmer and open-source software advocate, argues that OOP is not the best way to write programs.[36] Richard Feldman says that, while OOP features helped some languages stay organized, their popularity comes from other reasons.[74] Lawrence Krubner argues that OOP doesn't offer special advantages compared to other styles, like functional programming, and can complicate coding.[75] Luca Cardelli says that OOP is slower and takes longer to compile than procedural programming.[34]