3 ms·

I don't understand the modern hate for OOP. Perhaps a bad mentor or inheritance nazi. Inheritance can be thrown in the trash but otherwise OOP is just a collect

I don't understand the modern hate for OOP. Perhaps a bad mentor or inheritance nazi. Inheritance can be thrown in the trash but otherwise OOP is just a collection of related functions where you can have shared data to work with while not polluting global scope. I don't see how it's so oppressive unless if you're trapped in Java land where OOP is inescapable as opposed to dynamic languages where you can sprinkle in your OOP with other coding styles as needed.

logicchains 6y ago
A relevant quote from Joe Armstrong, creator of Erlang: "the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." In a nice procedural or functional program, when I need to do something I just write a function that takes the relevant arguments. From the function signature, I can reason about the function, that it only depends on and interacts with those things I passed in. It also means I can reuse that function anywhere else in the code I happen to have some of those things that are the function args. In the OO approach, even if a function only needs to access a few member variables, I still pass in the whole object every time I declare a member function. This makes the function harder to reason about, as the body of the function could touch any member of the class, and if it has other classes as members then it could rely on any of them too. It also makes the function much harder to use, as even if it only needs X, Y and Z, calling it requires creating a whole instance of that class of which the function is a member, which may require a bunch of other stuff. In that sense, the OO approach introduces unnecessary coupling, between the logic in the body of a member function and the class members not used in that function. Because I can't use that function's logic without creating instances of the members not used in that function.
ashtonkem 6y ago
I genuinely think that it’s as simple as the grass being greener on the other side of the fence. Most of us work in an OOP paradigm most of the time, so it’s easier to focus on what non-OOP languages would give you rather than what OOP does give you.
bdcravens 6y ago
I think it's more of a hate for patterns than OOP and like in your inheritance example, a confusion of the two (similar to "agile" and all the process that comes with "scrum")

logicchains 6y ago

A relevant quote from Joe Armstrong, creator of Erlang: "the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." In a nice procedural or functional program, when I need to do something I just write a function that takes the relevant arguments. From the function signature, I can reason about the function, that it only depends on and interacts with those things I passed in. It also means I can reuse that function anywhere else in the code I happen to have some of those things that are the function args. In the OO approach, even if a function only needs to access a few member variables, I still pass in the whole object every time I declare a member function. This makes the function harder to reason about, as the body of the function could touch any member of the class, and if it has other classes as members then it could rely on any of them too. It also makes the function much harder to use, as even if it only needs X, Y and Z, calling it requires creating a whole instance of that class of which the function is a member, which may require a bunch of other stuff. In that sense, the OO approach introduces unnecessary coupling, between the logic in the body of a member function and the class members not used in that function. Because I can't use that function's logic without creating instances of the members not used in that function.

ashtonkem 6y ago

I genuinely think that it’s as simple as the grass being greener on the other side of the fence. Most of us work in an OOP paradigm most of the time, so it’s easier to focus on what non-OOP languages would give you rather than what OOP does give you.

bdcravens 6y ago

I think it's more of a hate for patterns than OOP and like in your inheritance example, a confusion of the two (similar to "agile" and all the process that comes with "scrum")