Timeline for Why are we using mutable collections but immutable strings
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 23, 2017 at 16:29 | comment | added | Frank Hileman | 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. | |
| Aug 16, 2017 at 15:13 | history | edited | Robert Harvey | CC BY-SA 3.0 |
deleted 409 characters in body
|
| Aug 14, 2017 at 21:49 | answer | added | Ewan | timeline score: 1 | |
| Aug 14, 2017 at 20:12 | comment | added | Esben Skov Pedersen | ToList() is also (at least) O(n) so we replace one O(n) for another. | |
| Aug 14, 2017 at 20:11 | comment | added | Doc Brown | ... 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). | |
| Aug 14, 2017 at 20:03 | comment | added | Doc Brown | 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". | |
| Aug 14, 2017 at 19:55 | comment | added | Esben Skov Pedersen | @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. | |
| Aug 14, 2017 at 19:52 | comment | added | Doc Brown | 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. | |
| Aug 14, 2017 at 19:49 | history | edited | Esben Skov Pedersen | CC BY-SA 3.0 |
added 407 characters in body
|
| Aug 14, 2017 at 19:46 | review | Close votes | |||
| Aug 19, 2017 at 3:03 | |||||
| Aug 14, 2017 at 19:37 | comment | added | Esben Skov Pedersen | Neither of those answer the question. I immutability is good for byte arrays why is it not useful for other arrays. | |
| Aug 14, 2017 at 19:36 | comment | added | Robert Harvey | Strings aren't collections. | |
| Aug 14, 2017 at 19:27 | comment | added | gnat | Possible duplicate of Why doesn't Java 8 include immutable collections? | |
| Aug 14, 2017 at 19:23 | history | asked | Esben Skov Pedersen | CC BY-SA 3.0 |