[LRUG] The advantage of immutability?

[Florian Gilcher]

> On 10 Sep 2015, at 11:53, Riccardo Tacconi <rtacconi at gmail.com> wrote:
> 
> 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...


Nothing in Ruby rules out using immutable objects, if you ignore obscure weird features like instance_variable_set/get.

Optional (im)mutability and imperativeness are quite a good fit for each other, see, for example, Rust.

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]

Take, for example, an array.

  x = [1,2,3]
  len = x.length
  do_something(x)
  // is len still x.length?

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.

  r = read_request
  foo = r.param(:foo)
  dispatch(r)
  if foo == :bar
    // do something
  end

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.

Now, this can also happen with immutable objects (I just _replace_ the request), but consider debugging/logging:

   r = read_request
   debug(r) # GET /foo/bar/batz
   debug(r.object_id)
   dispatch(r)

   def dispatch(r)
      r = manipulate(r)
      debug(r) # POST /foo/bar/batz
      debug(r.object_id) // the same as above in the mutable case, different in the immutable
   end

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.

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.

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.

Best,
Florian


[1]: A good writeup from the Rust world: http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20150910/4a3c5b51/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20150910/4a3c5b51/attachment-0003.sig>