[LRUG] The advantage of immutability?

Riccardo Tacconi rtacconi at gmail.com
Thu Sep 10 04:07:00 PDT 2015


An ADA developer how wrote code running on the Boeing planes said that he
did not wanted freedom, he wanted a tool to have correctness. Now, no one
is using Ruby to control plane, I hope so, but we all want our web sites to
stay up and be correct in manipulating data. So I do not think that "you
can pretty much do whatever you feel is appropriate" is a good idea.

On 10 September 2015 at 11:05, 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
>
>


-- 
Riccardo Tacconi

http://github.com/rtacconi
http://twitter.com/rtacconi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20150910/3d1bc49d/attachment.html>


More information about the Chat mailing list