4 ms·

> The world is not functional, as it turns out. Have you watched the talk "Are we there yet?" by Rich Hickey? He makes a convincing case, referencing the phil

by tome 7y ago

> The world is not functional, as it turns out. Have you watched the talk "Are we there yet?" by Rich Hickey? He makes a convincing case, referencing the philosophy of Alfred North Whitehead, that "the world is functional". http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...

ukj 7y ago
In a functional world persistence (e.g memory) cannot be a thing. The case is convincing, but it requires you to reject your own, human, faculties. Makes the use/expression of language rather awkward when you can't remember any words.
- tome 7y ago
  Thanks for your input, Euthyphro!
  - ukj 7y ago
    My knack for spotting performative contradictions didn't sway you towards Deskartes?
- kchamplewski 7y ago
  > In a functional world persistence (e.g memory) cannot be a thing. Why not? To give a functional Haskell flavoured example, I can use the Reader and Writer monads (which are functional) to create a whole bunch of operations which write to and read from a shared collection of data. That feels a lot like memory to me. Indeed, the Reader monad is defined as: > Computations which read values from a shared environment. I just don't understand the whole "you can't have memory / order of operations / persistence / whatever else" as an argument against functional concepts when they have been implemented in functional ways decades ago. The modern Haskell implementation of the writer monad is an implementation of 1995 paper. Edit: it looks like who I responded to doesn't actually want to have a reasonable discussion, but for anyone else reading along, it's entirely possible to have functional "state" or "memory" - what makes it functional is that the state / memory must be explicitly acknowledged. Trying do dismiss functional computation in this way is essentially a no true Scotsman; functional computation is useless because it can't do X (X being memory or persistence or whatever), but when someone presents a functional computation that does do X, it's somehow not a "real" functional computation precisely because it does X. Redefining functional computation as "something that can't do X" doesn't help anyone, and doesn't actually help with discussing the pros and cons of functional programming since you're not actually discussing functional computation but some inaccurate designed-to-be-useless definition mislabeled as functional computation.
  - tome 7y ago
    Just FYI, you're debating with a troll.
    - ukj 7y ago
      If I am Euthyphro, then you are Socrates - no? I thought Socrates was the troll.
  - deleted 7y ago
    [deleted]
  - ukj 7y ago
    What is this thing that you reading from and writing to? It sounds mutable.
    - yakshaving_jgt 7y ago
      I’m sorry if immutability is a new concept to you, but you can read from one state, and write to a new state. There you go. No mutation!
      - ukj 7y ago
        Writing state is the definition of mutation. It's what all data storage systems do. An immutable data store sounds pretty useless. https://en.wikipedia.org/wiki/Persistence_%28computer_science%29 https://en.wikipedia.org/wiki/Persistence_%28computer_scienc...
        yakshaving_jgt 7y ago
        It’s fine for you to think that. That’s not going to stop other people from finding these concepts useful though. Once again, you are free to ignore the things you don’t understand. Your trolling is mostly harmless.
        ukj 7y ago
Barrin92 7y ago
I like hickey but a lot of his examples are data driven domains where we can indeed model the world in functional or accounting-like terms. Where this falls short is domains that are extremely ill-suited to keeping track of past states over time (his identity idea) simply because it would break performance or be hard to model in those terms, say simulations, game development, directly working with hardware and so on. Much of his argument relies on the GC and internal implementation being able to optimise away the inefficiences of the functional model that needs to recreate new entities over and over, but this simply is not always enough. This also is very obvious if you look into the domains where Clojure or other declarative functional languages have success, it's almost always business logic / data pipeline work. edit: And in fact a lot of his most salient points aren't really as much about functional programming as they are about lose coupling and dynamic typing. A lot of his criticism of state and identity in languages like Java isn't related to Java not being functional, it's related to Java breaking with the idea of late binding and treating objects as receivers of messages rather than "do-ers".
- filoeleven 7y ago
  > it would break performance or be hard to model in those terms, say simulations, game development, directly working with hardware and so on Performance seems to be the problem there more than the model not fitting. And Rich’s answer would probably be that Clojure isn’t the right tool for those tasks in the same way that any general-purpose GC’d language isn’t. Modeling a game or sim as a successive series of immutable states sounds great to me, so I’m curious where you see a mismatch with them. Abstracting hardware properties this way sounds useful too, but I’ve not worked with it enough to comment.
  - Barrin92 7y ago
    >Modeling a game or sim as a successive series of immutable states sounds great to me, so I’m curious where you see a mismatch with them. because I don't really think the functional model describes it in an intuitive way. You can model a sim or game at a high level like worldstate1 -> worldstate2 etc.. but it doesn't really tell you much, because often you don't really care what the state was a second ago anyway in particular not in its entirety, and because at that high level of abstraction you don't really get any useful information out of it, so there's no point in tracking it in the same way it makes sense to track a medical history or a bunch of business transactions. Rather instead of thinking of games or sims as high level abstract transitioning states we tend to reason about them as a sort of network of persistent agents or submodules and that lends itself much closer to a OO or message based view of the world. I think in many systems that are highly complex and change very incrementally reasoning about things in terms of functions doesn't really tell you much. You can for example reason about a person as like say a billion states through time but there's not much benefit to it at least to me.

by tome 7y ago

ukj 7y ago

In a functional world persistence (e.g memory) cannot be a thing. The case is convincing, but it requires you to reject your own, human, faculties. Makes the use/expression of language rather awkward when you can't remember any words.

tome 7y ago
Thanks for your input, Euthyphro!
- ukj 7y ago
  My knack for spotting performative contradictions didn't sway you towards Deskartes?
kchamplewski 7y ago
> In a functional world persistence (e.g memory) cannot be a thing. Why not? To give a functional Haskell flavoured example, I can use the Reader and Writer monads (which are functional) to create a whole bunch of operations which write to and read from a shared collection of data. That feels a lot like memory to me. Indeed, the Reader monad is defined as: > Computations which read values from a shared environment. I just don't understand the whole "you can't have memory / order of operations / persistence / whatever else" as an argument against functional concepts when they have been implemented in functional ways decades ago. The modern Haskell implementation of the writer monad is an implementation of 1995 paper. Edit: it looks like who I responded to doesn't actually want to have a reasonable discussion, but for anyone else reading along, it's entirely possible to have functional "state" or "memory" - what makes it functional is that the state / memory must be explicitly acknowledged. Trying do dismiss functional computation in this way is essentially a no true Scotsman; functional computation is useless because it can't do X (X being memory or persistence or whatever), but when someone presents a functional computation that does do X, it's somehow not a "real" functional computation precisely because it does X. Redefining functional computation as "something that can't do X" doesn't help anyone, and doesn't actually help with discussing the pros and cons of functional programming since you're not actually discussing functional computation but some inaccurate designed-to-be-useless definition mislabeled as functional computation.
- tome 7y ago
  Just FYI, you're debating with a troll.
  - ukj 7y ago
    If I am Euthyphro, then you are Socrates - no? I thought Socrates was the troll.
- deleted 7y ago
  [deleted]
- ukj 7y ago
  What is this thing that you reading from and writing to? It sounds mutable.
  - yakshaving_jgt 7y ago
    I’m sorry if immutability is a new concept to you, but you can read from one state, and write to a new state. There you go. No mutation!
    - ukj 7y ago
      Writing state is the definition of mutation. It's what all data storage systems do. An immutable data store sounds pretty useless. https://en.wikipedia.org/wiki/Persistence_%28computer_science%29 https://en.wikipedia.org/wiki/Persistence_%28computer_scienc...
      - yakshaving_jgt 7y ago
        It’s fine for you to think that. That’s not going to stop other people from finding these concepts useful though. Once again, you are free to ignore the things you don’t understand. Your trolling is mostly harmless.
        ukj 7y ago

Barrin92 7y ago

I like hickey but a lot of his examples are data driven domains where we can indeed model the world in functional or accounting-like terms. Where this falls short is domains that are extremely ill-suited to keeping track of past states over time (his identity idea) simply because it would break performance or be hard to model in those terms, say simulations, game development, directly working with hardware and so on. Much of his argument relies on the GC and internal implementation being able to optimise away the inefficiences of the functional model that needs to recreate new entities over and over, but this simply is not always enough. This also is very obvious if you look into the domains where Clojure or other declarative functional languages have success, it's almost always business logic / data pipeline work. edit: And in fact a lot of his most salient points aren't really as much about functional programming as they are about lose coupling and dynamic typing. A lot of his criticism of state and identity in languages like Java isn't related to Java not being functional, it's related to Java breaking with the idea of late binding and treating objects as receivers of messages rather than "do-ers".

filoeleven 7y ago
> it would break performance or be hard to model in those terms, say simulations, game development, directly working with hardware and so on Performance seems to be the problem there more than the model not fitting. And Rich’s answer would probably be that Clojure isn’t the right tool for those tasks in the same way that any general-purpose GC’d language isn’t. Modeling a game or sim as a successive series of immutable states sounds great to me, so I’m curious where you see a mismatch with them. Abstracting hardware properties this way sounds useful too, but I’ve not worked with it enough to comment.
- Barrin92 7y ago
  >Modeling a game or sim as a successive series of immutable states sounds great to me, so I’m curious where you see a mismatch with them. because I don't really think the functional model describes it in an intuitive way. You can model a sim or game at a high level like worldstate1 -> worldstate2 etc.. but it doesn't really tell you much, because often you don't really care what the state was a second ago anyway in particular not in its entirety, and because at that high level of abstraction you don't really get any useful information out of it, so there's no point in tracking it in the same way it makes sense to track a medical history or a bunch of business transactions. Rather instead of thinking of games or sims as high level abstract transitioning states we tend to reason about them as a sort of network of persistent agents or submodules and that lends itself much closer to a OO or message based view of the world. I think in many systems that are highly complex and change very incrementally reasoning about things in terms of functions doesn't really tell you much. You can for example reason about a person as like say a billion states through time but there's not much benefit to it at least to me.