[LRUG] The advantage of immutability?

[Frederick Cheung]

That sounds like a good example of what happens when you live in a halfway house - because strings could be mutated you have to  copy / allocate stuff because you can't assume that someone won't mutate the string later, which leads to ugly changes like https://github.com/rails/rails/commit/9aa2b2d7b (although the constant bit isn't needed as of ruby 2.2 - see https://github.com/rails/rails/commit/9f1b5c9b40)

Fred
On 10 September 2015 at 11:05:48, Stephen Best (bestie at gmail.com) wrote:

I believe Camille Baldock made an excellent point in one of her talks a while back (was it the memory leak one?) where string allocation was causing significant performance issues, this was easily solved by mutating strings instead.

I'm looking forward to string mutability being off by default but I think the great thing about Ruby is that you can pretty much do whatever you feel is appropriate.


On 10 September 2015 at 10: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 and you will have harder time to use it in a more functional way then directly using languages like Haskell. With Rails you will have even harder time because it is a framework design to change the state of shared objects. But it is possible and hard to figure out in the beginning because you are trying to use immutability in a place where mutability is everywhere (and JC explained that very well).

You were talking about Java Strings, I would add that strings should be immutable, and Ruby should not allow the usage of mutable strings. Mutable strings do not give any advantage and introduce only problems.

On 10 September 2015 at 10:39, Tom Stuart <tom at codon.com> wrote:
On 10 Sep 2015, at 10:34, Stephen Best <bestie at gmail.com> wrote:
> In every example I've seen immutability has certainly required more effort, but I don't think this always correlates with more complexity.

This reminds me (belatedly) of a bit I wrote last year, on implementing immutable trees: http://codon.com/notes-on-counting-tree-nodes#immutable-trees

I wrote that in an attempt to demonstrate how immutability can be useful — in that particular case, by making a data structure correct by construction, rather than having to write extra code to deal with malformed trees and so on. So I think that’s a decent example of how “more effort” (to implement the operations without mutation) leads to “[less] complexity” (because the resulting code is ultimately simpler to work with).

Cheers,
-Tom
_______________________________________________
Chat mailing list
Chat at lists.lrug.org
Archives: http://lists.lrug.org/pipermail/chat-lrug.org
Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org



--
Riccardo Tacconi

http://github.com/rtacconi
http://twitter.com/rtacconi

_______________________________________________
Chat mailing list
Chat at lists.lrug.org
Archives: http://lists.lrug.org/pipermail/chat-lrug.org
Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org


_______________________________________________  
Chat mailing list  
Chat at lists.lrug.org  
Archives: http://lists.lrug.org/pipermail/chat-lrug.org  
Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org  
List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20150910/c73bc811/attachment-0003.html>