4 ms·

In my opinion you're not really doing object-oriented programming unless each object is also a separate process. This is why the best object-oriented programmi

In my opinion you're not really doing object-oriented programming unless each object is also a separate process. This is why the best object-oriented programming uses functional programming languages and the actor model (i.e., Erlang). Just having state and methods, but without having an associated isolated process means you end up in situations in which multiple processes may fiddling with the same objects and all your encapsulation of data just gets you in a twist. It's only when you commit fully to functional programming and have immutable state that you truly unlock the power of object-oriented programming.

AnimalMuppet 3y ago
> without having an associated isolated process means you end up in situations in which multiple processes may fiddling with the same objects and all your encapsulation of data just gets you in a twist. 1. Don't do that. Don't have multiple threads messing with the same data. 2. If you have to do that, use a mutex/semaphore/guarded region. So far, so conventional. There's nothing about OOP in that. The difference with OOP is that only member functions can access that data, so you have a strictly limited number of places you have to think about protecting. OOP makes that aspect easier. Each class just protects its own data. Of course, you still have to worry about "deadly embrace", and by putting the semaphores in the class, it can make that aspect harder to reason about. > It's only when you commit fully to functional programming and have immutable state that you truly unlock the power of object-oriented programming. Um, no. Almost all real programs have mutable state, and the state has to live somewhere. I work in embedded systems. There's often a lot of persistent state, and, worse, shared mutable persistent state. FP isn't going to make that go away; it's just going to distribute it differently. But if I have to reason about the shared mutable state, then a distribution that pretends it isn't there doesn't make that easier. (Pure functions, on the other hand, do help.) I mean, look, FP is absolutely right that shared mutable state is evil. Avoid it... if you can. (And think harder about whether you can.) But sometimes the very nature of the problem is shared mutable state, and when that happens, you need tools that help you deal with it, not tools that say "don't do that".
- jononomo 3y ago
  > Um, no. Almost all real programs have mutable state, and the state has to live somewhere. The state lives in the process and you can have millions of processes if you'd like. If you want to get some bit of state then just send a message to the process that manages that state and it will give it to you. It's like traditional object oriented programming except the objects are alive.
  - c_crank 3y ago
    There's a reason Erlang works the way it does, but not every problem will make sense to solve with a million object processes communicating with each other.
    - jononomo 3y ago
      Why would a million objects be any better?
      - c_crank 3y ago
        For when the main thrust of the program is to simulate interactions between objects. I'm not the biggest general fan of the style, but that is where it shines.
        jononomo 3y ago
        Why not just do it better with functional programming, though?
        c_crank 3y ago
        Maybe because there are a lot of times where it really is more convenient to just update a variable or print a string instead of jumping through a million hoops to show off how pure everything is? Or we just want to implement quicksort without having a seizure?

AnimalMuppet 3y ago

> without having an associated isolated process means you end up in situations in which multiple processes may fiddling with the same objects and all your encapsulation of data just gets you in a twist. 1. Don't do that. Don't have multiple threads messing with the same data. 2. If you have to do that, use a mutex/semaphore/guarded region. So far, so conventional. There's nothing about OOP in that. The difference with OOP is that only member functions can access that data, so you have a strictly limited number of places you have to think about protecting. OOP makes that aspect easier. Each class just protects its own data. Of course, you still have to worry about "deadly embrace", and by putting the semaphores in the class, it can make that aspect harder to reason about. > It's only when you commit fully to functional programming and have immutable state that you truly unlock the power of object-oriented programming. Um, no. Almost all real programs have mutable state, and the state has to live somewhere. I work in embedded systems. There's often a lot of persistent state, and, worse, shared mutable persistent state. FP isn't going to make that go away; it's just going to distribute it differently. But if I have to reason about the shared mutable state, then a distribution that pretends it isn't there doesn't make that easier. (Pure functions, on the other hand, do help.) I mean, look, FP is absolutely right that shared mutable state is evil. Avoid it... if you can. (And think harder about whether you can.) But sometimes the very nature of the problem is shared mutable state, and when that happens, you need tools that help you deal with it, not tools that say "don't do that".

jononomo 3y ago
> Um, no. Almost all real programs have mutable state, and the state has to live somewhere. The state lives in the process and you can have millions of processes if you'd like. If you want to get some bit of state then just send a message to the process that manages that state and it will give it to you. It's like traditional object oriented programming except the objects are alive.
- c_crank 3y ago
  There's a reason Erlang works the way it does, but not every problem will make sense to solve with a million object processes communicating with each other.
  - jononomo 3y ago
    Why would a million objects be any better?
    - c_crank 3y ago
      For when the main thrust of the program is to simulate interactions between objects. I'm not the biggest general fan of the style, but that is where it shines.
      - jononomo 3y ago
        Why not just do it better with functional programming, though?
        c_crank 3y ago
        Maybe because there are a lot of times where it really is more convenient to just update a variable or print a string instead of jumping through a million hoops to show off how pure everything is? Or we just want to implement quicksort without having a seizure?