4 ms·

I agree with the article, and I have to admit I think Rich Hickey (creator of Clojure) is a brilliant man. If you check into his thoughts on programming you wi

by nkh 16y ago

I agree with the article, and I have to admit I think Rich Hickey (creator of Clojure) is a brilliant man. If you check into his thoughts on programming you will find some very interesting arguments. His talk on state and identity: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... is awesome, and I can not recommend highly enough. If you want motivation for learning a lisp (Clojure is one) check out http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html if you have not already done so. An awesome essay to re-read if you have not done so in a while. Edit: Fixed Link (thanks atuladhar)

deleted 16y ago
[deleted]
jules 16y ago
Can you explain the point he is making in "Are we there yet"? I have watched it but I didn't really get a different viewpoint on state and identity. That could be because I already had the same viewpoint, but I doubt that.
- nkh 16y ago
  The text below is directly lifted from the Clojure site at: http://clojure.org/state http://clojure.org/state The article describes it more clearly and succinctly then I could. There is another way, and that is to separate identity and state (once again, indirection saves the day in programming). We need to move away from a notion of state as "the content of this memory block" to one of "the value currently associated with this identity". Thus an identity can be in different states at different times, but the state itself doesn't change. That is, an identity is not a state, an identity has a state. Exactly one state at any point in time. And that state is a true value, i.e. it never changes. If an identity appears to change, it is because it becomes associated with different state values over time. This is the Clojure model.
  - jules 16y ago
    So is he saying that you should not nest refs? i.e. you should not create a vector of refs and assign the vector to a ref. Because now the state itself can change.

by nkh 16y ago

deleted 16y ago

[deleted]

jules 16y ago

Can you explain the point he is making in "Are we there yet"? I have watched it but I didn't really get a different viewpoint on state and identity. That could be because I already had the same viewpoint, but I doubt that.

nkh 16y ago
The text below is directly lifted from the Clojure site at: http://clojure.org/state http://clojure.org/state The article describes it more clearly and succinctly then I could. There is another way, and that is to separate identity and state (once again, indirection saves the day in programming). We need to move away from a notion of state as "the content of this memory block" to one of "the value currently associated with this identity". Thus an identity can be in different states at different times, but the state itself doesn't change. That is, an identity is not a state, an identity has a state. Exactly one state at any point in time. And that state is a true value, i.e. it never changes. If an identity appears to change, it is because it becomes associated with different state values over time. This is the Clojure model.
- jules 16y ago
  So is he saying that you should not nest refs? i.e. you should not create a vector of refs and assign the vector to a ref. Because now the state itself can change.