[Noob here] Can someone explain to me the advantage of mutable objects?

[shanmugha@lemmy.world]

Logical and human friendly answer: mutable objects are not a problem, poorly designed code is

Personal rant: why even bother with objects, just use strings, ints, floats, arrays and hashmaps (sarcascm. I have spent hours uncovering logic of large chunks of code with no declaration of what function expects anx produces what)
And also, seeing endless create-object-from-data-of-other-object several times has made me want to punch the author of that code in the face. Even bare arrays and hashmaps were less insane than that clusterfuck

[eluvatar@programming.dev]

I was trying to think of a good real world example, but couldn't think of anything. But if you were to think of it as Google docs. You could just copy every doc to change it, but if you've shared it with people then you will have to share it again. It also takes up a whole lot more space to do that, sure you could delete those old ones but that takes some work too.

[michal@programming.dev]

Because recreating entire object just to make a single change is dumb.

[spacemanspiffy@lemmy.world]

I seriously appreciate you taking the time to do this. Good info.

[monkdervierte@lemmy.ml]

Sounds like a thing Java would do.

[sudo@programming.dev]

Saves memory.

[giooschi@lemmy.world]

Well, but then you're basically just pushing the mutability onto the container

That's the point, when programming with immutable structures you always pass the mutability onto the enclosing structure.

It's a good strategy at times though. Like say you're working in a language where strings are immutable and you want a string you can change. You can wrap it in a list along the lines s=['foo'] and pass references to the list around instead. Then if you go s[0]='bar' at some point, all the references will now see ['bar'] instead.

A list is an antipattern here IMO. Just wrap it in some dedicated object (see e.g. Java's StringBuilder).

[sudo@programming.dev]

You can safely do a shallow copy and re-use references to the unchanged members if you have some guarantee that those members are also immutable. Its called Persistent Data Structures. But that's a feature of the language and usually necessitates a GC.

[pupbiru@aussie.zone]

strings? ints? floats, arrays, HASHMAPS? so inefficient… just directly access memory!!!!

[2xsaiko@discuss.tchncs.de]

They made that and it’s called pure functional programming. Take a look at Haskell

[behindthebarrier@programming.dev]

Try making a list without copying every time you add something. Mutability matters then. Imagine copying 10000 elements, or copying 10000 references to items every time something were to be added or changed.

[tunetardis@lemmy.ca]

That’s the point, when programming with immutable structures you always pass the mutability onto the enclosing structure.

I guess the point I was trying to make here was if the data type is already mutable, there is no point in sticking it in a list just so you can replace a reference with an identifier. You're just adding an extra level of indirection. But sure yeah, if the type is inherently immutable, you have to do something.

A list is an antipattern here IMO. Just wrap it in some dedicated object (see e.g. Java’s StringBuilder).

Interesting. I'm not aware of anything like StringBuilder in the standard library for either Python or JavaScript. Looks like it wraps a list of characters and tries to behave as string-like as possible? You could presumably write your own class like that or download an implementation from someplace.

I guess in most cases in my own code, where I need a mutable string is usually as part of a larger data structure which is the thing that gets passed around by reference, so it's easy enough to replace a field within that.

For building up a string, I would tend to use an io.StringIO in Python with file-writing calls, but those aren't meant for sharing. What you don't want to do is use the += operator a lot on strings. That gets expensive unless strings are mutable (like they are in say C++'s std::string).

[wewbull@feddit.uk]

You can do exactly as you say, and you're right - it makes code easier to reason about. However it all come down to efficiency. Copying a large data structure to modify one element in it is slow. So we deal with the ick of mutable data to preserve performance.

[derarzt@lemmy.world]

For all the people in this thread talking about the inefficiencies of immutability, they may find this talk by Rich Hickey (the creator of clojure) interesting. Not so much as it shows that they're wrong, but more so that it's a good lecture explaining how we can build immutable data structures that address the limitations immutability in a way that reduces the overhead.

[traister101@lemmy.today]

So your writing a game. This game has what I'm going to call "entities" which are the dynamic NPCs and such objects. So these objects are most easily conceptualized as mutable things. Why mutable? Well they move around, change states depending on game events ect. If this object is immutable you'd have to tie the in world representation to a new object, constantly just because it moved slightly or something else. This object is mutable not just because it's easier to understand but there are even efficiency gains due to not needing to constantly create a new version just because it moved a little bit.

In contrast the object which holds the position data (in this case we'll have 3 doubles x, y, z) makes a lot of sense as an immutable object. This kind object is small making it cheap to replace (it's just 3 doubles, so 3*64 bits or a total of 24 bytes) and it's representing something that naturally makes sense as being immutable, it's a set of 3 numbers.

Now another comparison your typical dynamic array type container (this is your std::vector std::vec ArrayList and friends). These are mutable objects mainly due to efficiency (it's expensive to copy the contents when adding new values) yet they also are easier to conceptualize when mutable. It's an object containing a collection of stuff like a box, you can put things in, take stuff out but it's still the same box, just it's contents have changed. If these objects are immutable to put something into the box you must first create a brand new box, and create a copy of the old boxes contents, and then put your new item into the box. Every time. Sometimes this kind of thing makes sense but it's certainly not a common situation.

Some functional languages do have immutable data structures however in reality the compiler usually does some magic and ends up using a mutable type as it's simply so much more efficient.