-1

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?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Esben Skov Pedersen
  • 5,098
  • 2
  • 21
  • 24
  • Possible duplicate of [Why doesn't Java 8 include immutable collections?](https://softwareengineering.stackexchange.com/questions/221762/why-doesnt-java-8-include-immutable-collections) – gnat Aug 14 '17 at 19:27
  • 2
    Strings aren't collections. – Robert Harvey Aug 14 '17 at 19:36
  • Neither of those answer the question. I immutability is good for byte arrays why is it not useful for other arrays. – Esben Skov Pedersen Aug 14 '17 at 19:37
  • 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 Aug 14 '17 at 19:52
  • @DocBrown could you be more specific? I would wager the same argument that in 90% where linq ToList() is called in .NET no further elements are added afterwards and could thus trivially be replaced with an immutable list without any performance loss. – Esben Skov Pedersen Aug 14 '17 at 19:55
  • Well, I question your 90%, at least for the codebases where I currently work, but the replacement itself would require an O(n) operation, which is quite different from "without any performance loss". – Doc Brown Aug 14 '17 at 20:03
  • 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 Aug 14 '17 at 20:11
  • ToList() is also (at least) O(n) so we replace one O(n) for another. – Esben Skov Pedersen Aug 14 '17 at 20:12
  • 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 Aug 23 '17 at 16:29

1 Answers1

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."

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • 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 Aug 15 '17 at 04: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 Aug 16 '17 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 Aug 16 '17 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 Aug 16 '17 at 16:57
  • ?why do you say it is difficult to make your own? – Ewan Aug 16 '17 at 17:01
  • It is not difficult as such but I'm not going through a large codebase and changing all instances of list so something homemade. It would be nice if there were some kind industry standard. – Esben Skov Pedersen Aug 16 '17 at 17:05
  • the recommended best practice is to expose and pass IEnumberables not Lists. so you could easily create your own immutable one – Ewan Aug 16 '17 at 17:15
  • 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 Aug 23 '17 at 16:26