4 ms·

But we can imagine a program that reads a file byte-by-byte and where some internal state of the program changes depending on those bytes. This program could ev

But we can imagine a program that reads a file byte-by-byte and where some internal state of the program changes depending on those bytes. This program could even exit when given three “#” characters, which might mean you need an internal counter for each “#”. In that sense Mario isn’t really that different! (Subtly, a purely functional Mario game has more inputs than just the controller. You’ll need a clock signal for the Koopas to walk around at a given pace, but that’s not too different from a file of sequential numbers that’s read at a particular speed.) Backstory: I used to think that front-end JavaScript programming was too stateful and inherently messy to be compared with, say, handling HTTP requests. But the Elm language (and to a lesser extent React/Redux) has shown me that the messiness is accidental. You actually can apply the techniques of purely functional programming to create arbitrarily sophisticated GUI programs. Here’s a simplified version of Mario in Elm: https://github.com/avh4/elm-mario. https://github.com/avh4/elm-mario.)

dahart 8y ago
No, you missed the point. The human input depends on the intermediate state, where the file input does not. Manufacturing a case where you output the intermediate state as you read a file is missing that crucial dependency. You must also assume that the human input cannot be predicted before the intermediate state is known. Assuming that it’s a function of time is cheating. > You actually can apply the techniques of purely functional programming to create arbitrarily sophisticated GUI programs. No, you can’t. That’s exactly what this article is talking about. React is a state machine under the hood. You can handle each request in a functional way, but you can’t build the request processing behind the scenes in a function way, it’s not currently possible. However, from your point of view, all of your code can appear to be functional, so some of the comments here are, reasonably, asking the question, why does it matter?
- zachrose 8y ago
  > The human input depends on the intermediate state, where the file input does not. Not sure what you mean by “depends” here. If I’m at a game controller I can smash buttons for years without caring what the state of the game is. It’s up to the game to make sense of those button presses and do the right thing.
  - dahart 8y ago
    It’s a two-way dependency. You are taking about the game responding to the human, but I’m talking about the human responding to the game. Both need to happen, they are entangled, which is why you fundamentally can’t separate them and treat them as an abstract function of time, nor can you re-order the events (which may be necessary for pure functional interaction). Just because you can smash buttons randomly doesn’t prove anything, that’s not normally how people play games. Normally, they see what’s happening and respond in order to succeed.
    - zachrose 8y ago
      Ok that’s something else then. I thought we were just talking about crafting a program that accepts user input (sensical or otherwise) and draws the right graphics on a screen. If you want a complete cybernetic framework to model the player and the game, I wouldn’t know where to begin.
      - dahart 8y ago
        I don’t want a model of the player at all. (And I don’t think it’s possible to make one that will solve this problem.) We are talking about how to increase the scope of FP to include the I/O layer, because it currently ends at the I/O interface. I’m arguing that it might be fundamentally, perhaps provably impossible to have pure FP when there’s unpredictable human interaction, due to the coupled dependency on intermediate state.
      - magicalhippo 8y ago
        Imagine a simple game where the player has to adjust a dial to tune in an old FM radio manually by holding either button A or button B. The game needs to provide feedback to the user as the tuning happens, in the form of more or less noise, so that the user can stop when the station is found.

dahart 8y ago

No, you missed the point. The human input depends on the intermediate state, where the file input does not. Manufacturing a case where you output the intermediate state as you read a file is missing that crucial dependency. You must also assume that the human input cannot be predicted before the intermediate state is known. Assuming that it’s a function of time is cheating. > You actually can apply the techniques of purely functional programming to create arbitrarily sophisticated GUI programs. No, you can’t. That’s exactly what this article is talking about. React is a state machine under the hood. You can handle each request in a functional way, but you can’t build the request processing behind the scenes in a function way, it’s not currently possible. However, from your point of view, all of your code can appear to be functional, so some of the comments here are, reasonably, asking the question, why does it matter?

zachrose 8y ago
> The human input depends on the intermediate state, where the file input does not. Not sure what you mean by “depends” here. If I’m at a game controller I can smash buttons for years without caring what the state of the game is. It’s up to the game to make sense of those button presses and do the right thing.
- dahart 8y ago
  It’s a two-way dependency. You are taking about the game responding to the human, but I’m talking about the human responding to the game. Both need to happen, they are entangled, which is why you fundamentally can’t separate them and treat them as an abstract function of time, nor can you re-order the events (which may be necessary for pure functional interaction). Just because you can smash buttons randomly doesn’t prove anything, that’s not normally how people play games. Normally, they see what’s happening and respond in order to succeed.
  - zachrose 8y ago
    Ok that’s something else then. I thought we were just talking about crafting a program that accepts user input (sensical or otherwise) and draws the right graphics on a screen. If you want a complete cybernetic framework to model the player and the game, I wouldn’t know where to begin.
    - dahart 8y ago
      I don’t want a model of the player at all. (And I don’t think it’s possible to make one that will solve this problem.) We are talking about how to increase the scope of FP to include the I/O layer, because it currently ends at the I/O interface. I’m arguing that it might be fundamentally, perhaps provably impossible to have pure FP when there’s unpredictable human interaction, due to the coupled dependency on intermediate state.
    - magicalhippo 8y ago
      Imagine a simple game where the player has to adjust a dial to tune in an old FM radio manually by holding either button A or button B. The game needs to provide feedback to the user as the tuning happens, in the form of more or less noise, so that the user can stop when the station is found.