0

In three popular platforms I'm familar with(.NET, java, python) strings are immutable but lists are by default mutable.

In all languages there is some functional support(linq, streams, list comprehensions) so it is easy to transform/filter a list to a different list.

Strings and lists are quite similar in that both are wrappers of a array and indeed it is quite common in the wild to see code bases where most lists are used in a immutable way once they have been constructed with e.g linq.

I understand that in all three language the functional support was not have been there in version 1.0 but the fact remains that in neither language there is not a simple first-class supported class that offers the guarantee of immutability that string does. In e.g .NET there is a nuget package to install this functionality which seems to me at least to be almost as useful as string.

I don't think most programmers would dream of creating a substring of a string using anything other than the built-in substring method. What is the reason we are still defaulting to mutable collections when functional apis are available that can easily construct immutable collections?

Improve this question
9
  • Possible duplicate of Why doesn't Java 8 include immutable collections?
    – gnat
    Commented Aug 14, 2017 at 19:27
  • 2
    Strings aren't collections.
    – Robert Harvey
    Commented Aug 14, 2017 at 19:36
  • 1
    The link posted by gnat is not a duplicate (which is the standard case when gnat votes for something as a "dupe"), but it gives at least a pointer in the right direction: immutable collections need a lot of different infrastructure to be as efficient as their mutable counterparts, or one has to use only stack and tree-like immutable collections with adapted algorithms. For strings, however, this is not true, in 80 to 90% of the use cases for a string an immutable version performs fine, and for the remaining 10 to 20% one can use a StringBuilder.
    – Doc Brown
    Commented Aug 14, 2017 at 19:52
  • 3
    ... IMHO, it is also a "school of thought" thing - at the time when C#, Java and Python were designed, time was ready to replace to replace mutable strings (like the ones in C or C++) by immutable ones, since this was more or less easy to implement, and for many people this kind of design seemed to be superior. But for "classic collections" like arrays or dictionaries time was not quite ready (immutable collections were known, of course, but only in form of Lisp-like lists or trees, and they require a functional way of programming to be really useful).
    – Doc Brown
    Commented Aug 14, 2017 at 20:11
  • 1
    I think the real problem is thinking that language designers and implementers are continually advancing the field. Look at how many functional features have been retrofit to C#: these were all invented and explored prior to C#. The hash table implementation using prime sized arrays was considered obsolete at the time the Java libraries were adopted; C# used the same implementation and it caused many problems.
    – Frank Hileman
    Commented Aug 23, 2017 at 16:29

1 Answer 1

Reset to default
1

We are not:

https://msdn.microsoft.com/en-us/library/dn467185(v=vs.111).aspx

Why do we have a mutable version? Mutable objects have value too, if we didnt you would be asking why don't we have a mutable list.

this makes for an interesting read:

https://blogs.msdn.microsoft.com/dotnet/2013/09/25/immutable-collections-ready-for-prime-time/

It addresses some of the difficulties for creating immutable collections

"Other operations of our immutable collections follow this spirit of maximizing reuse. For example, adding an order line to an order with 1,000 order lines will not create an entire new list with 1,001 elements. Instead, it will reuse a large chunk of the existing list. This is possible because the list is internally represented as a tree which allows sharing nodes between different instances."

Improve this answer
8
  • Yes - this is hardly first-class support when it is not even part of the framework. The question remains, why have immutable collections not been the default choice for .ToList() and .ToDictionary()
    – Esben Skov Pedersen
    Commented Aug 15, 2017 at 4:51
  • @EsbenSkovPedersen: Why would you make immutable collections the default when mutable collections are the historical norm? Immutability solves a specific set of problems, problems which not everyone has. Immutability is an option, not a mandate; it's an enhancement over regular collections, not the default.
    – Robert Harvey
    Commented Aug 16, 2017 at 15:11
  • @EsbenSkovPedersen: Further, you seem to make the assumption that immutability is the preferred or standard way of doing things. That's not at all self-evident. Immutability only exists at the programming language level anyway; at the machine level, almost everything is blissfully mutable, including the processor's own machine language.
    – Robert Harvey
    Commented Aug 16, 2017 at 15:14
  • One thing is mutability being the default. Another thing is making immutability prohibitily difficult. There is not even an immutable list in the standard .NET library and the nuget package has a completely different license banning it from many platforms. It seems weird to me it has to be so hard to get the guarantee that other code cannot modify a certain collection. If you inheritet a codebase that used StringBuilders all over the place instead of strings I bet the WTFs/per minute would be pretty high.
    – Esben Skov Pedersen
    Commented Aug 16, 2017 at 16:57
  • 1
    @Ewan While this works, lack of certain members commonly available in even immutable collections causes problems. The lack of a Count property in particular.
    – Frank Hileman
    Commented Aug 23, 2017 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.