For some reason 'arguments' against OOP seem to follow a common pattern. You have said many things against OOP, but you haven't actually presented an argument f

For some reason 'arguments' against OOP seem to follow a common pattern. You have said many things against OOP, but you haven't actually presented an argument for why it's bad. I'll present each of your assertions here individually to clarify. > OOP is prove a poor model for computation > OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functional, or structured paradigm. These claims may or may not be true, but they aren't very useful at all if you don't provide a justification as well as merely asserting them. > Recent trends in language design (see Rust, Go, Elixir) also seem to be abandoning OOP in favor of other models There are a number of ways to account for these trends besides OOP being an intrinsically bad model. The most obvious one is that there are fashions in language design, and right now OOP is not fashionable. We already know that; it's not a strong argument against it. Ironically, many in the OOP opposition use the same argument to justify OOP every getting popular in the first place: "it was just fashionable." > OOP provides competing ways of abstracting behavior that in Haskell we can model with type parameters and constraints. > Objects are not truly encapsulated in the way Erlang processes are and a poor fit for SMP. You have pointed out here that more classical OOP languages do things differently from Haskell and Erlang. This should be expected and is not an argument against those OOP languages. (Yes, you could say, "Erlang is better at concurrency" because of the way in which it's different—but my understanding is it's pretty well accepted that Erlang is sort of freak of nature here, so it's not a good argument against OOP generally.) > Objects also pathologically hide data in attempt to manage mutability, making it impossible to reason about the memory layout of the program. They do hide data, but the 'pathologically' is something you've added on your own. There is a design philosophy in which this data hiding plays an important, positive role. When you say, "making it impossible to reason about the memory layout of the program." —this sounds to me like missing the point of that design philosophy: the purpose (and oftentimes tradeoff) of higher-level languages is that you don't need to personally manage these details. I think it's largely an application-dependent thing: you many be writing code that requires that, but not all interesting software hinges on low-level performance tuning. > OOP is a toolkit for building bad abstractions: > ... abstractions that do not easily model computation > ... that hide data > ... and has tended to create overly complex solutions to problems that are often full of errors that a language focused more on type expressivity could catch at compile time. Another collection of unjustified assertions, except the 'hide data' part which I accounted for earlier. So across ~10 negative assertions about OOP you have 3 quasi-justifications: newer languages aren't using OOP as much, hiding data is bad, and Erlang is better for SMP.