4 ms·

You are using "object oriented programming" by definition, the moment you formulate an "object" in code with interactions on that object (regardless of what lan

You are using "object oriented programming" by definition, the moment you formulate an "object" in code with interactions on that object (regardless of what language you're using)! I completely agree with the arguments showing how harmful OOP abuse is (especially branching inheritance trees!), just like abusing pointers, or structs, or error codes, or abusing <insert_language_feature_here> is harmful. But what does that have to do with OOP inherently? Let's look at historical crashes, glitches, and hopelessly messy code and try to count their actual source. I bet you'll find sloppy programmers as the #1 root cause (maybe null-able pointers and/or weak typing as #2). OOP isn't bad because it's OOP, it's bad because hordes of bad programmers use it at big companies who don't care about code quality. Beautiful functional code is beautiful. Beautiful procedural code is beautiful. Beautiful object oriented code is beautiful. ... Spend more time writing beautiful code that draws its elegance from the rich set of paradigms and tools we have; spend less time participating in fad paradigm-ocide movements :)

jokoon 12y ago
Containers are a particular case. almost nobody re implements a container. and you're talking and template, not OOP. > How would you do this without some kind of "object orientation"? Variables. Variables are not "objects". What is an "object" anyway ? It's a shallow abstract concept which is impractical. > The moment you formulate an "object" in code with interactions on that object No that's not what the article is trying to talk about. What people argue against OOP is how it's applied to anything for any case. Creating new classes/type/abstract concept each time you want to realize something can often lead to code bloat. How many classes named "XXX_manager" can one encounter ? > Sorry for shattering everyone's hopes and dreams of coding pure OOPless. OOP tends to have state, which doesn't bode well will multithreading, which tend to favor functional programming. I don't know if the future is going to be massively multithreaded, but I just think that OOP is just another way to structure a program, nothing more. Processes and threads already are objects. Functions too. So why tell students to create new types all the time ?

jokoon 12y ago

Containers are a particular case. almost nobody re implements a container. and you're talking and template, not OOP. > How would you do this without some kind of "object orientation"? Variables. Variables are not "objects". What is an "object" anyway ? It's a shallow abstract concept which is impractical. > The moment you formulate an "object" in code with interactions on that object No that's not what the article is trying to talk about. What people argue against OOP is how it's applied to anything for any case. Creating new classes/type/abstract concept each time you want to realize something can often lead to code bloat. How many classes named "XXX_manager" can one encounter ? > Sorry for shattering everyone's hopes and dreams of coding pure OOPless. OOP tends to have state, which doesn't bode well will multithreading, which tend to favor functional programming. I don't know if the future is going to be massively multithreaded, but I just think that OOP is just another way to structure a program, nothing more. Processes and threads already are objects. Functions too. So why tell students to create new types all the time ?