4 ms·

It's not about either. He is illustrating a problem that only occurs in functional programming: There is no concept of time in pure functions. In imperative p

It's not about either. He is illustrating a problem that only occurs in functional programming: There is no concept of time in pure functions. In imperative programming when two actors approach the same spot, whether the application is parallel or not, one actor ALWAYS arrives first and the other will arrive subsequently. Therefore the Second actor can read the state of the first and act accordingly... This is not the case for functional programming. Per frame the state of each actor changes (or in other words: new actors with updated states are created) at the same time and thus you can have two actors approach the same spot at the same time. You will then need an extra step for conflict resolution. Of course there's a bunch of ways to deal with this. Carmack briefly mentioned something about using some other attribute of the actor as a priority number... it's not like this is some crazy issue that's impossible to solve.

ece 9y ago
But one actor can always read the state of the other actor, and modify their actions accordingly. The state of each actor is immutable, so each action taken based on the state is sure to be conflict free. As opposed to imperative programming, were each actors position might not get updated correctly or in time until too late. Deadlock and starvation don't happen when you have pure functions with no side effects and immutable state like they do in non-FP languages. Timing is harder to get right when everything is async, but if your game design is good, you just need to better implement it to get it right frame by frame. He also talks about having monads to handle things like this.
- crimsonalucard 9y ago
  If two actors moved to one spot at the same time which actor occupies that spot? How can an actor act accordingly if they moved at the same time? In functional programming this can happen... in imperative programming it NEVER happens, because the actors move imperatively, aka step by step or one at a time. This is the problem he is talking about.
  - deleted 9y ago
    [deleted]
  - ece 9y ago
    It can only never happen if you use a lock correctly. In separate threads, this can absolutely happen in imperative programming. As a reader-writer or dining philosopher problem will show, two actors can try to do the same thing at the same time unless you EXPLICITLY stop them by using locks. In FP, you will have an immutable variable for state instead of a mutable variable wrapped in a lock. You will be passing a whole new immutable state variable to a pure side effect free function every time, and won't have to worry about getting a lock and releasing it explicitly (these would be side effects). As long as the state is immutable and synced across threads, actors in any thread can just plot their next actions using that state. In imperative programming, like I said, you'll have to explicitly get and release locks to make sure two actors don't occupy the same spot. So, if you use atomic immutable variables with pure functions, and the logic in your actors can be conflict free, you can have horizontal scalability across as many cores as you want pretty easily. If your actors cannot be conflict free, you will need to wrap a lock of your choice in a monad and use that, but you will still have gained better debugging, testing and maintainability by using FP. Now if only every zero-cost OO abstraction had a straight forward FP alternative that was also zero-cost, we'd all be doing FP as of yesterday.
    - ves 9y ago
      I don't think the latter point is true. FP requires a lot of thinking up front, which is not how most engineers like to work. That's not to say that FP is at odds with iterative programming, but it means that you have to work out a "specification" of your code pretty completely from the beginning. Although, even then it's not so bad because the excellent type systems and compilers mean you can develop the specification interactively (see Idris' typed holes).
      - ece 9y ago
        Which part? I think even John Carmack in the video talked about the upfront thinking required for FP. If every CS student learned category and type theory like they learn complexity theory; and FP compilers could optimize type classes and all the object creation, FP would definitely be more widely used. But, yes, there is definitely a cost to picking up FP today in almost any domain, but it's getting lower.
craigsmansion 9y ago
> There is no concept of time in pure functions. Very true, but there is a fundamental concept of time, almost by definition, in game-worlds. Whereas in imperative programming it's true that one actor always arrives first in computation, he might not have arrived first "in the game": conflict resolution is still a necessity. As such I don't think this is a problem that only occurs in functional programming. It's my impression that it's the events up to any conflict are much cleaner to express functionally.
- crimsonalucard 9y ago
  Correct. But when things arrive at the same time and the same place "in game" the imperative programming style resolves this automatically by giving precedence to the object that was computed first, thus this problem is handled automagically in the imperative world. In fact you probably don't even have to really think about this issue when using the imperative style, unlike the functional style where this issue must be explicitly dealt with. FYI I'm not saying either paradigm is worse or better, it is what it is.

ece 9y ago

But one actor can always read the state of the other actor, and modify their actions accordingly. The state of each actor is immutable, so each action taken based on the state is sure to be conflict free. As opposed to imperative programming, were each actors position might not get updated correctly or in time until too late. Deadlock and starvation don't happen when you have pure functions with no side effects and immutable state like they do in non-FP languages. Timing is harder to get right when everything is async, but if your game design is good, you just need to better implement it to get it right frame by frame. He also talks about having monads to handle things like this.

crimsonalucard 9y ago
If two actors moved to one spot at the same time which actor occupies that spot? How can an actor act accordingly if they moved at the same time? In functional programming this can happen... in imperative programming it NEVER happens, because the actors move imperatively, aka step by step or one at a time. This is the problem he is talking about.
- deleted 9y ago
  [deleted]
- ece 9y ago
  It can only never happen if you use a lock correctly. In separate threads, this can absolutely happen in imperative programming. As a reader-writer or dining philosopher problem will show, two actors can try to do the same thing at the same time unless you EXPLICITLY stop them by using locks. In FP, you will have an immutable variable for state instead of a mutable variable wrapped in a lock. You will be passing a whole new immutable state variable to a pure side effect free function every time, and won't have to worry about getting a lock and releasing it explicitly (these would be side effects). As long as the state is immutable and synced across threads, actors in any thread can just plot their next actions using that state. In imperative programming, like I said, you'll have to explicitly get and release locks to make sure two actors don't occupy the same spot. So, if you use atomic immutable variables with pure functions, and the logic in your actors can be conflict free, you can have horizontal scalability across as many cores as you want pretty easily. If your actors cannot be conflict free, you will need to wrap a lock of your choice in a monad and use that, but you will still have gained better debugging, testing and maintainability by using FP. Now if only every zero-cost OO abstraction had a straight forward FP alternative that was also zero-cost, we'd all be doing FP as of yesterday.
  - ves 9y ago
    I don't think the latter point is true. FP requires a lot of thinking up front, which is not how most engineers like to work. That's not to say that FP is at odds with iterative programming, but it means that you have to work out a "specification" of your code pretty completely from the beginning. Although, even then it's not so bad because the excellent type systems and compilers mean you can develop the specification interactively (see Idris' typed holes).
    - ece 9y ago
      Which part? I think even John Carmack in the video talked about the upfront thinking required for FP. If every CS student learned category and type theory like they learn complexity theory; and FP compilers could optimize type classes and all the object creation, FP would definitely be more widely used. But, yes, there is definitely a cost to picking up FP today in almost any domain, but it's getting lower.

craigsmansion 9y ago

> There is no concept of time in pure functions. Very true, but there is a fundamental concept of time, almost by definition, in game-worlds. Whereas in imperative programming it's true that one actor always arrives first in computation, he might not have arrived first "in the game": conflict resolution is still a necessity. As such I don't think this is a problem that only occurs in functional programming. It's my impression that it's the events up to any conflict are much cleaner to express functionally.

crimsonalucard 9y ago
Correct. But when things arrive at the same time and the same place "in game" the imperative programming style resolves this automatically by giving precedence to the object that was computed first, thus this problem is handled automagically in the imperative world. In fact you probably don't even have to really think about this issue when using the imperative style, unlike the functional style where this issue must be explicitly dealt with. FYI I'm not saying either paradigm is worse or better, it is what it is.