4 ms·

Usually when I see people rant against OOP, they're not ranting in favor of FP (or even better, in favor of something like Scala that combines OOP and FP) but r

Usually when I see people rant against OOP, they're not ranting in favor of FP (or even better, in favor of something like Scala that combines OOP and FP) but rather in favor of a return to procedural/top-down programming. There are very good reasons that procedural programming was abandoned a long time ago and the need for global variables to make it work is one of the big ones.

jchw 6y ago
In my opinion, the case against inheritance is strong, but it’s in favor of composition, which is still often object oriented.
Jtsummers 6y ago
> There are very good reasons that procedural programming was abandoned a long time ago and the need for global variables to make it work is one of the big ones. Procedural programming does not, at all, require global variables to make it work. I'm not a big fan of procedural programming at scale because it almost always seems to assume mutability (by default) and shared state when dealing with concurrency, but let's set those aside. You use structures to contain what a naive programmer (or a prototype) would use global state for. Instead of: player_t current_turn; // a global You do: struct game_state { player_t current_turn; } And pass that game_state value or reference around. The global state can easily be minimized or eliminated from most procedural programs. I've done this quite often as part of improving older programs.
- antonvs 6y ago
  That's basically a hand-rolled implementation of a state monad that supports real mutability. The Haskell equivalent is the ST monad. While it's possible to do this kind of thing, it's busywork that properly designed programming languages are perfectly capable of handling well on our behalf.
  - commandlinefan 6y ago
    I had the same thought: he's doing OOP without using the "class" keyword. Well-written C code is actually very object-oriented this way, it just doesn't take advantage of the syntactic sugar of C++.
    - Jtsummers 6y ago
      This is only one thing that OO languages provide. My point, though, was that global state is not inherent to procedural languages as you claimed. And if all you're getting from an OO language is a bit of sugar and single dispatch, you're not getting much.
    - mypalmike 6y ago
      This is a common misunderstanding. Structural programming like this is clearly similar to what we think of as OO. But it existed before OO and is still heavily practiced in non-OO languages such as C. The main feature that OO added to this was dynamic function dispatch via inheritance. The specific function that gets called at runtime depends on the type of the struct. Inheritance has proven powerful but often results in confusing code. The development of interface-based (non-inheritance) dynamic dispatch in COM and Java, and later embraced by Go and Rust, shows that we can get what is arguably the primary benefit of OO with a flat structural approach.
      - commandlinefan 6y ago
        ... and this inevitable pedantry is why I thought twice about replying to OP.
        mypalmike 6y ago
        It's not pedantic. If you're not doing dynamic dispatch, you aren't doing OO. https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html

jchw 6y ago

In my opinion, the case against inheritance is strong, but it’s in favor of composition, which is still often object oriented.

Jtsummers 6y ago

> There are very good reasons that procedural programming was abandoned a long time ago and the need for global variables to make it work is one of the big ones. Procedural programming does not, at all, require global variables to make it work. I'm not a big fan of procedural programming at scale because it almost always seems to assume mutability (by default) and shared state when dealing with concurrency, but let's set those aside. You use structures to contain what a naive programmer (or a prototype) would use global state for. Instead of: player_t current_turn; // a global You do: struct game_state { player_t current_turn; } And pass that game_state value or reference around. The global state can easily be minimized or eliminated from most procedural programs. I've done this quite often as part of improving older programs.

antonvs 6y ago
That's basically a hand-rolled implementation of a state monad that supports real mutability. The Haskell equivalent is the ST monad. While it's possible to do this kind of thing, it's busywork that properly designed programming languages are perfectly capable of handling well on our behalf.
- commandlinefan 6y ago
  I had the same thought: he's doing OOP without using the "class" keyword. Well-written C code is actually very object-oriented this way, it just doesn't take advantage of the syntactic sugar of C++.
  - Jtsummers 6y ago
    This is only one thing that OO languages provide. My point, though, was that global state is not inherent to procedural languages as you claimed. And if all you're getting from an OO language is a bit of sugar and single dispatch, you're not getting much.
  - mypalmike 6y ago
    This is a common misunderstanding. Structural programming like this is clearly similar to what we think of as OO. But it existed before OO and is still heavily practiced in non-OO languages such as C. The main feature that OO added to this was dynamic function dispatch via inheritance. The specific function that gets called at runtime depends on the type of the struct. Inheritance has proven powerful but often results in confusing code. The development of interface-based (non-inheritance) dynamic dispatch in COM and Java, and later embraced by Go and Rust, shows that we can get what is arguably the primary benefit of OO with a flat structural approach.
    - commandlinefan 6y ago
      ... and this inevitable pedantry is why I thought twice about replying to OP.
      - mypalmike 6y ago
        It's not pedantic. If you're not doing dynamic dispatch, you aren't doing OO. https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html