<story><title>Clojure’s Approach to Identity and State (2008)</title><url>https://clojure.org/about/state</url></story><parent_chain></parent_chain><comment><author>stuhood</author><text>Immutability is very helpful, and the connection between values and identity is illuminating.&lt;p&gt;But there have been very important developments in programming languages since this post&amp;#x2F;page was written: notably, the introduction of &amp;quot;borrow checking&amp;quot; (exemplified by Rust&amp;#x27;s implementation). Borrow checking has a very significant positive effect on the sustainability of imperative code, which makes the claim that &amp;quot;imperative programming is founded on an unsustainable premise&amp;quot; feel dated.&lt;p&gt;It is worth taking the time to understand what borrow checking enables. For example: borrow checking allows even mutable datastructures to be treated as values with structural equality. It does this by guaranteeing that unless you have exclusive access to something, it may not be mutated.&lt;p&gt;A good explanation of the benefits of ownership and borrow checking: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;squidarth.com&amp;#x2F;rc&amp;#x2F;rust&amp;#x2F;2018&amp;#x2F;05&amp;#x2F;31&amp;#x2F;rust-borrowing-and-ownership.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;squidarth.com&amp;#x2F;rc&amp;#x2F;rust&amp;#x2F;2018&amp;#x2F;05&amp;#x2F;31&amp;#x2F;rust-borrowing-and-o...&lt;/a&gt;</text></comment>
<story><title>Clojure’s Approach to Identity and State (2008)</title><url>https://clojure.org/about/state</url></story><parent_chain></parent_chain><comment><author>etbebl</author><text>This is interesting. I&amp;#x27;ve tried Clojure, and heard about the idea of avoiding mutable data and using pure functions plenty of times, but imperative&amp;#x2F;OOP have still always made the most sense to me. When reading this though, something clicked because I&amp;#x27;ve encountered the problem of getting a stable state to read&amp;#x2F;write without blocking other operations, and dealt with it in C++ in a similar way to Clojure without realizing it at the time.&lt;p&gt;I have this little lightly-tested library: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;tne-lab&amp;#x2F;rw-synchronizer&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;tne-lab&amp;#x2F;rw-synchronizer&lt;/a&gt;. I&amp;#x27;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 &amp;quot;snapshot&amp;quot; of the last thing that was written, but it&amp;#x27;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&amp;#x27;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.&lt;p&gt;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&amp;#x27;m probably reinventing the wheel here...</text></comment>