There seems to be a lot of "buzz" lately (the past few years) that modern languages should be immutable-by-default or strive towards it. There seems to be this notation that mutability is bad and I don't know if that's empirically true.
In C/C++, I hardly even use `const` any more because during developing, code likes to mutate and thus a lot of the data does too. It might be that I just very used to the mutable-by-default concept but all the advantages that people advocate about, I don't really have problems with. I understand that being stateless is powerful but being stateful is just as powerful but for different reasons.
Is there any evidence to back up their claims or is it just an opinion that cannot be proven or even just the current "fad"?
- Bill
In C/C++, I hardly even use `const` any more because during developing, code likes to mutate and thus a lot of the data does too. It might be that I just very used to the mutable-by-default concept but all the advantages that people advocate about, I don't really have problems with. I understand that being stateless is powerful but being stateful is just as powerful but for different reasons.
Is there any evidence to back up their claims or is it just an opinion that cannot be proven or even just the current "fad"?
- Bill
If your code is multi-threaded, then having data shared across threads never change is a very good thing™. Even in single threaded code it means that if different parts of the program need the same data then they can share a pointer to the same block without having to worry that something will change it.
However taking this to the extreme means that every struct would need to be manipulated using a copy-on-write scheme and some way of reclaiming all the unreferenced garbage.
The copy-on-write also has the danger that the new data may not get propagated to everyone who cares about the new data and they instead keep using the old data. The only way to ensure that doesn't happen is to always look at the data from a shared mutable root pointer that points to the data tree
However taking this to the extreme means that every struct would need to be manipulated using a copy-on-write scheme and some way of reclaiming all the unreferenced garbage.
The copy-on-write also has the danger that the new data may not get propagated to everyone who cares about the new data and they instead keep using the old data. The only way to ensure that doesn't happen is to always look at the data from a shared mutable root pointer that points to the data tree
In the case of shared data in concurrency, immutability can be very good as you suggest. I'm not saying immutability is never useful but are its advantages outweigh the advantages of mutable-by-default?
There is also the a CSP-like concurrency model in which you share memory by communicating. In this case, mutability never really arises as a problem. You can apply immutable or mutable and they both work.
I've just not seen any really convincing argument yet other than the "mutable-by-default is dangerous" mantra.
- Bill
There is also the a CSP-like concurrency model in which you share memory by communicating. In this case, mutability never really arises as a problem. You can apply immutable or mutable and they both work.
I've just not seen any really convincing argument yet other than the "mutable-by-default is dangerous" mantra.
- Bill
C++'s const is not a good comparison. The constness is too shallow. Pointers can still mutate other data, including the object itself.
In other languages you often create a new value. Haskell has special syntax for updating some fields while keeping all the rest. Without that it can be quite annoying, especially when there are many fields.
Rust makes use of move operations to avoid unnecessary object creations. The compiler prevents you from accidentally accessing the value afterwards and you can also create multiple values of the same name in the same scope. If useful, you can write
In other languages you often create a new value. Haskell has special syntax for updating some fields while keeping all the rest. Without that it can be quite annoying, especially when there are many fields.
Rust makes use of move operations to avoid unnecessary object creations. The compiler prevents you from accidentally accessing the value afterwards and you can also create multiple values of the same name in the same scope. If useful, you can write
1 2 | let foo = bar(); let foo = modify(foo); // foo is moved into modify and the return value is bound to the name foo again |
You might investigate and see if the Quorum language team ever did any experiments with immutable default vs not:
https://quorumlanguage.com/
99.9% of discussion on these things is just rhetoric, gotta dig to find actual experiments, which is the only way to know things.
https://quorumlanguage.com/
99.9% of discussion on these things is just rhetoric, gotta dig to find actual experiments, which is the only way to know things.
Edited by Jack Mott
on
Thank you for that paper. Even though they have a small sample size, it does seem that (im)mutability by default seems to be more about personal preference rather than one being better than the other.
-Bill
-Bill
it matches what the memory is. There isn't a "immutable" region
and when you want to edit something immutable you need to make a copy and update the references to the new object.
and when you want to edit something immutable you need to make a copy and update the references to the new object.