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

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 ?