<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 10 Sep 2015, at 11:53, Riccardo Tacconi <<a href="mailto:rtacconi@gmail.com" class="">rtacconi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Yes I can recommend Tom's post to understand how to build immutable data structures in Ruby. The problem is that Ruby is mainly an imperative programming language...</span></div></blockquote></div><div><br class=""></div><div class="">Nothing in Ruby rules out using immutable objects, if you ignore obscure weird features like instance_variable_set/get.</div><div class=""><br class=""></div><div class="">Optional (im)mutability and imperativeness are quite a good fit for each other, see, for example, Rust. </div><div class=""><br class=""></div><div class="">My case for Immutability is the following: at large, it allows more _assumptions_ to be expressed about a data structure. The interesting thing is that concurrent situations are not even necessary for race-like situations.[1]</div><div class=""><br class=""></div><div class="">Take, for example, an array.</div><div class=""><br class=""></div><div class=""> x = [1,2,3]</div><div class=""> len = x.length</div><div class=""> do_something(x)</div><div class=""> // is len still x.length?</div><div class=""><br class=""></div><div class="">This is obviously trivialising, but I cannot guarantee that the assertion holds without auditing do_something in every aspect. Now imagine do_something being something as large as Rails. Request-like objects are a good example here.</div><div class=""><br class=""></div><div class=""> r = read_request</div><div class=""> foo = r.param(:foo)</div><div class=""> dispatch(r)</div><div class=""> if foo == :bar</div><div class=""> // do something</div><div class=""> end</div><div class=""><br class=""></div><div class="">Playing around with the request object in the Rack dispatch toolchain is not unusual, which can lead to bugs depending on which Middleware is deployed before which.</div><div class=""><br class=""></div><div class="">Now, this can also happen with immutable objects (I just _replace_ the request), but consider debugging/logging:</div><div class=""><br class=""></div><div class=""> r = read_request</div><div class=""> debug(r) # GET /foo/bar/batz</div><div class=""> debug(r.object_id)</div><div class=""> dispatch(r)</div><div class=""><br class=""></div><div class=""> def dispatch(r)</div><div class=""> r = manipulate(r)</div><div class=""> debug(r) # POST /foo/bar/batz</div><div class=""><div class=""> debug(r.object_id) // the same as above in the mutable case, different in the immutable</div></div><div class=""> end</div><div class=""><br class=""></div><div class="">Contrived again, but here's a thing: immutability guarantees that once the object is manipulated, I can tell by its id: if `manipulate` can only create a new object out of an old one to change it, I will never think "well, this is the object I sent into the system, why doesn't it do what I want later on?". I can assume that the object I pass in is unchanged if I get the same one back.</div><div class=""><br class=""></div><div class="">Furthermore, having immutability clarified allows interesting sharing approaches. On immutable data locations, lock-free concurrent access is possible. Mutable data requires locks (+ ensuring references don't escape the lock!). Some languages use this knowledge to build many access patterns around this and you can do this for your own piece of code without language support.</div><div class=""><br class=""></div><div class="">Now, the thing with ensured immutability is that it doesn't give you a lot in a three-line piece of code. It's power is being able to pass a complex piece of data into complex system and know that it will still be the same after the system finishes its labour.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Florian</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">[1]: A good writeup from the Rust world: <a href="http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/" class="">http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/</a></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>