Clojure’s Approach to Identity and State (2008)
1–10 of 69 posts
Re: Clojure’s Approach to Identity and State (2008)
#2Rich Hickey has a talk on this
(The Value of Values) here: https://youtu.be/-6BsiVyC1kM
Re: Clojure’s Approach to Identity and State (2008)
#3Would be helpful with practical examples in code. As a self thought programmer I dont know what all concepts are called, but when I see code I can usually recognise them. The actor model as described in the article becomes less painful when you have an abstraction layer. The question might be are you going for horizontal scaling or vertical scaling, although you are best off implementing the simplest solution in order to avoid premature optimization (and overengineering).
Re: Clojure’s Approach to Identity and State (2008)
#4This has been extremely useful to me while writing a (somewhat optimizing) compiler for spreadsheets. I can do subtree deduplication just by `assoc`ing into a map.
Re: Clojure’s Approach to Identity and State (2008)
#5Would be helpful with practical examples in code. As a self thought programmer I dont know what all concepts are called, but when I see code I can usually recognise them. The actor model as described in the article becomes less painful when you have an abstraction layer. The question might be are you going for horizontal scaling or vertical scaling, although you are best off implementing the simplest solution in orde…
Regarding values: you can construct the same datastructure in any place, and compare it meaningfully with a datastructure from a completely different source (and you can do so efficiently). This is accomplished, as far as I know, by representing almost everything as persistent hash trees (with some implementation voodoo and shortcuts).
Beyond that, you can actually just read the Clojure runtime code. It's a bit messy but there's not really that much there.
Re: Clojure’s Approach to Identity and State (2008)
#6This is interesting. I've tried Clojure, and heard about the idea of avoiding mutable data and using pure functions plenty of times, but imperative/OOP have still always made the most sense to me. When reading this though, something clicked because I've encountered the problem of getting a stable state to read/write without blocking other operations, and dealt with it in C++ in a similar way to Clojure without realizing it at the time.
I have this little lightly-tested library: https://github.com/tne-lab/rw-synchronizer. I'm not using it much currently but have played with it a lot while building extensions to Open Ephys. The idea being that as a reader, you get a "snapshot" of the last thing that was written, but it's really just one of several copies, and subsequent writes can happen on the other copies. So you never really modify the current data, just push newer versions of it. The cool thing is, if you know how many simultaneous readers you'll need ahead of time, all the allocation can be done upfront, so then if you have a real-time loop or something, all it needs to do is exchange pointers.
If I ever get around to it, the next thing I would do is allow any writer to also read the latest value, so it can use a transformation to create a new one. Maybe even do it automatically with copy-on-write semantics? On the other hand, I'm probably reinventing the wheel here...
Re: Clojure’s Approach to Identity and State (2008)
#7Would be helpful with practical examples in code. As a self thought programmer I dont know what all concepts are called, but when I see code I can usually recognise them. The actor model as described in the article becomes less painful when you have an abstraction layer. The question might be are you going for horizontal scaling or vertical scaling, although you are best off implementing the simplest solution in orde…
Regarding values: you can construct the same datastructure in any place, and compare it meaningfully with a datastructure from a completely different source (and you can do so efficiently). This is accomplished, as far as I know, by representing almost everything as persistent hash trees (with some implementation voodoo and shortcuts). Beyond that, you can actually just read the Clojure runtime code. It's a bit messy…
Persistent hash tries [1]
I have an efficient C# implementation here [2]
[1] https://michael.steindorfer.name/publications/phd-thesis-eff...
[2] https://github.com/louthy/language-ext/blob/master/LanguageE...
Re: Clojure’s Approach to Identity and State (2008)
#8This has been extremely useful to me while writing a (somewhat optimizing) compiler for spreadsheets. I can do subtree deduplication just by `assoc`ing into a map.
I want to hear more about your somewhat optimizing compiler for spreadsheets!
Re: Clojure’s Approach to Identity and State (2008)
#9Re: Clojure’s Approach to Identity and State (2008)
#10This is interesting. I've tried Clojure, and heard about the idea of avoiding mutable data and using pure functions plenty of times, but imperative/OOP have still always made the most sense to me. When reading this though, something clicked because I've encountered the problem of getting a stable state to read/write without blocking other operations, and dealt with it in C++ in a similar way to Clojure without realiz…
IIUC Rich Hickey probably did just that too, writing ad-hoc version of clojure semantics in cpp before making his own language enforcing this.