Timeline for If immutable objects are good, why do people keep creating mutable objects?
Current License: CC BY-SA 3.0
29 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 13, 2015 at 8:52 | comment | added | srph | Immutability is now being embraced in "GUI", especially in the Web. See Redux, ImmutableJS, Rx, and the like. | |
| Jan 30, 2015 at 18:03 | comment | added | weberc2 | @KonradRudolph It would be cool if languages allowed you to speak of 'values' and 'objects', and the compiler/interpreter would work out when it is appropriate (taking into account correctness and efficiency) to copy the data vs referencing it. | |
| Dec 2, 2014 at 20:20 | comment | added | Evan Zamir | "However, for large and/or complex objects, creating a new copy of the object for every single change can be very costly and/or tedious." Generally true in most languages, but Clojure (and the genius of Rich Hickey) specifically seems to alleviate this concern by implementing persistent data structures. | |
| Mar 7, 2014 at 18:30 | comment | added | hurturk | Well, if you consider gas in fuel tank is apart, you don't need to recreate the car and you can still keep most things immutable. | |
| Aug 28, 2013 at 12:52 | comment | added | Eonil | +1 for where objects don't have an identity. Making up efficient reference-able identity was mostly impossible to me. I still want a trick to solve it. | |
| Sep 20, 2012 at 9:17 | comment | added | SK-logic | @FlorianSalihovic, ever heard of functional reactive programming? | |
| Aug 24, 2012 at 15:48 | history | made wiki | Post Made Community Wiki by supercat | ||
| Aug 23, 2012 at 21:54 | comment | added | Giorgio | @Péter Török: I graduated in 1993 in Italy. We had one course on computability, covering lambda calculus, and one general course on programming languages, covering the principles of procedural, object-oriented, functional, and logic programming languages. I did one project in Prolog and also played a bit with Lisp at that time. We also learnt about denotational semantics, which is also based on composing functions and often uses the lambda notation. | |
| Aug 23, 2012 at 20:01 | comment | added | Péter Török | @Giorgio, when did you study CS? I graduated in 1994 and our curricula contained none of FP nor lambda calculus, although it was math / theory heavy. Fair enough, my country was not and is not at the cutting edge regarding IT and CS, so it may be that FP was more well known in the academia of other parts of the world even back then. | |
| Aug 23, 2012 at 8:22 | comment | added | Giorgio | "Note that most developers of today have been trained well before immutability (and the containing paradigm, functional programming) became "trendy" in their sphere of influence": I find this a bit strange though: FP languages have been around for more than 40 years and are quite common in Computer Science curricula. My main education was with procedural and object-oriented programming languages but I had to learn about Lisp, lambda calculus, etc, so now the switch to FP is not that hard. So I do not totally understand this inertia and this difficulty to think in a different paradigm. | |
| Jul 7, 2012 at 8:41 | comment | added | Konrad Rudolph | @supercat Ouch, my mistake. Still, I think that it could have been just as well been made immutable. | |
| Jul 6, 2012 at 20:27 | comment | added | supercat |
@KonradRudolph: The Point structure in .net exposes its fields and thus allows them to be mutated by anything which has access to the storage location holding the Point which contains them. Note that the fields of all non-trivial structs stored in mutable storage locations are mutable (even if only by doing an all-field-copy assignment), and the fields of all structs stored in immutable storage locations are immutable.
|
|
| Jun 11, 2012 at 7:02 | vote | accept | Vinoth Kumar C M | ||
| Jun 8, 2012 at 13:52 | history | edited | Péter Török | CC BY-SA 3.0 |
added 27 characters in body
|
| Jun 8, 2012 at 7:42 | comment | added | Péter Török | @TimothyBaldridge, fair enough, "you can't step twice into the same stream", stated Heraclitus more than 2K years ago :-) | |
| Jun 8, 2012 at 4:54 | comment | added | Maja Piechotka | As of speed - the compiler could optimize it out so the immutable object are mutable behind scene and/or reason about the code enabling further optimalisation. Of course it does not mean it do. @scriptocalypse: One could argue that if you mutate all of the state that make no difference performance-wise. If the 'objects' are large arrays then computation usually IS non-destructive(code writes into different region of memory the it reads from) - for example on GPUs. Which makes the particle systems probably a bad example. | |
| Jun 6, 2012 at 20:09 | comment | added | scriptocalypse | Even more than simply moving a character around, imagine a particle effect system. Imagine the cost in time and memory to instantiate hundreds, possibly thousands of new particle objects 60 times per second. Mutable particles, with mutable world positions have a tremendous performance advantage. | |
| Jun 6, 2012 at 18:56 | comment | added | Timothy Baldridge | You make a good point about state vs identity. This is why Rich Hickey (author of Clojure) broke the two apart in Clojure. One could argue, that the car you have with 1/2 tank of gas is not the same car as the one with 1/4 tank of gas. They have the same identity, but they are not the same, every "tick" of our reality's time creates a clone of every object in our world, our brains then simply stitch these together with a common identity. Clojure has refs, atoms, agents, etc. to represent time. And maps, vectors and lists for actual time. | |
| Jun 6, 2012 at 14:47 | comment | added | Péter Török | @KonradRudolph, good points, thanks. I did not mean to rule out using immutability in complex objects, but implementing such a class correctly and efficiently is far from being a trivial task, and the extra effort required may not be always justified. | |
| Jun 6, 2012 at 14:41 | comment | added | Péter Török | @SnOrfus, good point, I should add that resistance may come from the organization as well. Luckily, we can always look for a better workplace :-) | |
| Jun 6, 2012 at 14:23 | comment | added | Konrad Rudolph |
Two small caveats to this: (1) Take the moving game character. The Point class in .NET for instance is immutable but creating new points as the result of changes is easy and thus affordable. Animating an immutable character can be made very cheap by decoupling the “moving parts” (but yes, some aspect is then mutable). (2) “large and/or complex objects” can very well be immutable. Strings are often large, and usually benefit from immutability. I once rewrote a complex graph class to be immutable, making the code simpler and more efficient. In such cases, having a mutable builder is the key.
|
|
| Jun 6, 2012 at 14:18 | comment | added | Steven Evers | It's not just resistance, I'm sure lots of devs would love to try out the latest and greatest, but how often do new projects spin up in the average dev's environment where they can apply these new practices? Not everone can or will write a hobby project just to try out immutable state. | |
| Jun 6, 2012 at 13:40 | history | edited | Péter Török | CC BY-SA 3.0 |
added 146 characters in body
|
| Jun 6, 2012 at 9:48 | vote | accept | Vinoth Kumar C M | ||
| Jun 6, 2012 at 15:54 | |||||
| Jun 6, 2012 at 8:30 | history | edited | Péter Török | CC BY-SA 3.0 |
added 197 characters in body
|
| Jun 6, 2012 at 8:17 | history | edited | Péter Török | CC BY-SA 3.0 |
added 197 characters in body
|
| Jun 6, 2012 at 7:59 | history | edited | Péter Török | CC BY-SA 3.0 |
added 622 characters in body
|
| Jun 6, 2012 at 7:56 | comment | added | Florian Salihovic | That's right. Especially in GUI programming, mutable object are very handy. | |
| Jun 6, 2012 at 7:51 | history | answered | Péter Török | CC BY-SA 3.0 |