[LRUG] The advantage of immutability?

Stephen Best bestie at gmail.com
Thu Sep 10 03:05:13 PDT 2015


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20150910/be073300/attachment-0003.html>


More information about the Chat mailing list