4 ms·

>> Reading files and writing to the console is one thing, >> Think about apps Photoshop, Super Mario Bros, or Sublime text. Well, there's literally no differe

>> Reading files and writing to the console is one thing, >> Think about apps Photoshop, Super Mario Bros, or Sublime text. Well, there's literally no difference between reading from a file or from a queue of requests from the user on any level of abstraction. E.g. you could (functionally) apply a list of operations to an image in Photoshop that the user has supplied you with.

dahart 8y ago
There is a big difference between reading files and human interaction. You don’t normally have to output intermediate state while reading a file, but you do with human interaction. Human interaction is usually responding and reacting to intermediate the state of the program. Think a bit more about Super Mario Bros. A file can be read as a single chunk of memory, and it doesn’t need to consist of a queue of sequential operations. We can decide and design what files are and what’s in them. An array in a file doesn’t need to be read one number at a time. Human interaction, unlike a file, cannot happen all at once, needs intermediate feedback, and cannot be reordered or easily reformulated into another representation, because it’s responding to the intermediate state of the system.
- zachrose 8y ago
  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.
- heavenlyblue 8y ago
  So what is an example of an intermediate state in a human being?
  - dahart 8y ago
    What do you mean? I’m talking about the program’s intermediate state, not the human’s. Humans respond to the program, then give it new inputs, then the program outputs a new intermediate state, then the human responds again, and so on. This loop is fundamentally different than reading a static file that doesn’t change or depend on the state of the program.
    - heavenlyblue 8y ago
      Well, then swap a file for an ethernet socket and voila - it's unpredictable, too.
      - dahart 8y ago
        You are still missing the critical piece. The reason a file is different than a human is that everything in the file is known in advance, whereas the human reacts to the program. It’s not just about unpredictability, it’s also about the dependency. The human input is not decided until the program displays it’s intermediate state, and when the human does send input to the program, the input is based on what the human sees, which is the program’s intermediate state. So, the human input depends on the intermediate state. A file input does not depend on the program’s intermediate state. The file input is a static queue of data that doesn’t change. If you change the program, the file won’t change, but the human input will. A queue of commands in a file is fixed, and showing the program’s output doesn’t affect which command comes next from the file. The human input is a function of time and also of the program’s intermediate state, and lastly of the human’s whims. These things force the program’s evaluation loop with human input into a specific order that cannot be evaluated or re-ordered or simplified in advance, unlike the file. Is that making more sense now? All of this is exactly what the author of the article was talking about when he discussed weak vs strong composition. Do you understand what he meant by functional composition being stronger than Von Neumann composition, and why?

dahart 8y ago

There is a big difference between reading files and human interaction. You don’t normally have to output intermediate state while reading a file, but you do with human interaction. Human interaction is usually responding and reacting to intermediate the state of the program. Think a bit more about Super Mario Bros. A file can be read as a single chunk of memory, and it doesn’t need to consist of a queue of sequential operations. We can decide and design what files are and what’s in them. An array in a file doesn’t need to be read one number at a time. Human interaction, unlike a file, cannot happen all at once, needs intermediate feedback, and cannot be reordered or easily reformulated into another representation, because it’s responding to the intermediate state of the system.

zachrose 8y ago
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.
heavenlyblue 8y ago
So what is an example of an intermediate state in a human being?
- dahart 8y ago
  What do you mean? I’m talking about the program’s intermediate state, not the human’s. Humans respond to the program, then give it new inputs, then the program outputs a new intermediate state, then the human responds again, and so on. This loop is fundamentally different than reading a static file that doesn’t change or depend on the state of the program.
  - heavenlyblue 8y ago
    Well, then swap a file for an ethernet socket and voila - it's unpredictable, too.
    - dahart 8y ago
      You are still missing the critical piece. The reason a file is different than a human is that everything in the file is known in advance, whereas the human reacts to the program. It’s not just about unpredictability, it’s also about the dependency. The human input is not decided until the program displays it’s intermediate state, and when the human does send input to the program, the input is based on what the human sees, which is the program’s intermediate state. So, the human input depends on the intermediate state. A file input does not depend on the program’s intermediate state. The file input is a static queue of data that doesn’t change. If you change the program, the file won’t change, but the human input will. A queue of commands in a file is fixed, and showing the program’s output doesn’t affect which command comes next from the file. The human input is a function of time and also of the program’s intermediate state, and lastly of the human’s whims. These things force the program’s evaluation loop with human input into a specific order that cannot be evaluated or re-ordered or simplified in advance, unlike the file. Is that making more sense now? All of this is exactly what the author of the article was talking about when he discussed weak vs strong composition. Do you understand what he meant by functional composition being stronger than Von Neumann composition, and why?