I think that OO languages are more natural, although most people are writing their objects "wrong".
OOP more naturally models a multicore system, because it bundles state and behavior. That more closely modelsthe hardware: multiple CPUs, each of which address a non-uniform portion of memory. That is like methods an an object that operate on local/private state.
What's missing in some languages is an abstraction for "thread of control", i.e. your program counter.
But that can be added, and has been -- people are just not using it as widely as they should. Whereas I think functional languages are great for some things but awkward for others. I like algebraic data types but I'm beginning to think they are orthogonal to functional programming, as in Rust, which has them, but is an imperative language.
I expanded on this style of treating OO languages in a more functional style state here:
If OO is a better fit for parallel programming, why are functional programming models such as Hadoop or Spark, so much easier than message passing alternatives such as MPI? My answer is that they bring abstraction and composition, which classical OO does not easily allow, thanks to mutable state.
I think the key point is it's not either/or. The post I linked was saying that you can use a functional ARCHITECTURE (immutable data, explicit dependencies like monads) inside an OO language.
Hadoop is written in an OO language -- Java. But it has a functional architecture (MapReduce).
So really the two camps aren't that far apart. They both have something to bring to the table.
Opponents of OOP are thinking of all the spaghetti imperative code with globals dressed up as classes, which people have realized is a mistake, but there's still hundreds of millions of lines of code out there like that. And there are tons of "frameworks" which actually FORCE you to write in that style.
But yeah there is no real contradiction that I see. Thinking that you can write a for loop to update a hash table is as big a mistake as writing spaghetti objects.
OOP more naturally models a multicore system, because it bundles state and behavior. That more closely modelsthe hardware: multiple CPUs, each of which address a non-uniform portion of memory. That is like methods an an object that operate on local/private state.
What's missing in some languages is an abstraction for "thread of control", i.e. your program counter.
But that can be added, and has been -- people are just not using it as widely as they should. Whereas I think functional languages are great for some things but awkward for others. I like algebraic data types but I'm beginning to think they are orthogonal to functional programming, as in Rust, which has them, but is an imperative language.
I expanded on this style of treating OO languages in a more functional style state here:
https://news.ycombinator.com/item?id=11841893