Mutation doesn't get blamed due to anyone's lack of understanding about references. it's about expectation pure and simple. If I have an object x and it's still named x then it shouldn't change. If it changes, its name should reflect it. It's not that looking at the code wouldn't tell me about the change, it's that it requires revisiting the code over and over whenever I need to answer a question about state instead of me following a simple convention that a variable name is descriptive enough.
The idea that mutation is "excellent" if the mutation doesn't leave a function is just wrong. It might make it acceptable but the fact that it doesn't leave a function isn't some benefit it adds, it merely doesn't permeate side effects. That's not a value in itself.
The notion that using mutating language constructs make code readable is actually one of the reasons I laugh at the concept that a language is just a tool. It's a tool alright but one that forms habits and mentality. The fact that a developer can get along with mutating language constructs because Ina certain language it provides readability (despite its downsides) is something that will carry over. It becomes a way of doing things and everyone hangs on to their ways during any transition. This particular one is problematic because it's related to the particular syntax sugar of JS which teaches developers that mutation is acceptable, but you won't fare well if you take this habit elsewhere.
Objects shouldn't change without a name change? You mean like an object of me and my age or address should never change? Hasn't ever been an issue in C#, ever.
Objects shouldn't change in a context where the local logic doesn't expect it to. That's the gist.
In C# you are forced to do conscious decisions about mutability so certain behaviours are expected. Rust falls in the same place.
Yes this is exactly why mutation is never an issue in C# because the context is fully known. The same applies to Javascript. "Know thy context". Trouble happens in Javascript due to bad practices. Immutabilty works perfectly in proper context but is not a "single tool solves all" where frameworks require it.
Sorry but it's not at all the same thing. JavaScript doesn't provide immutability mechanisms at all. In C# you can specify "readonly" on object property and go to bed. In Rust you actually need to allow mutation specifically with "mut". In JavaScript you need to re-investigate the context, as anyone might inadvrtedly call the wrong function on the wrong thing. Better leave a whole lot of documentation on which functions use mutating constructs and end up mutating stuff themselves and hope everyone does flawless code review.
You missed my point which ultimately was that the immutable fan club became that way due to Javascript programmers not knowing context. It is a 10 pound hammer for a 1 pound problem. So much so the magical spread operators were invented that allow mutation and return a new array. Over engineering in my opinion.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This kind of thinking is somewhat flawed.
Objects shouldn't change without a name change? You mean like an object of me and my age or address should never change? Hasn't ever been an issue in C#, ever.
Objects shouldn't change in a context where the local logic doesn't expect it to. That's the gist.
In C# you are forced to do conscious decisions about mutability so certain behaviours are expected. Rust falls in the same place.
Yes this is exactly why mutation is never an issue in C# because the context is fully known. The same applies to Javascript. "Know thy context". Trouble happens in Javascript due to bad practices. Immutabilty works perfectly in proper context but is not a "single tool solves all" where frameworks require it.
Sorry but it's not at all the same thing. JavaScript doesn't provide immutability mechanisms at all. In C# you can specify "readonly" on object property and go to bed. In Rust you actually need to allow mutation specifically with "mut". In JavaScript you need to re-investigate the context, as anyone might inadvrtedly call the wrong function on the wrong thing. Better leave a whole lot of documentation on which functions use mutating constructs and end up mutating stuff themselves and hope everyone does flawless code review.
You missed my point which ultimately was that the immutable fan club became that way due to Javascript programmers not knowing context. It is a 10 pound hammer for a 1 pound problem. So much so the magical spread operators were invented that allow mutation and return a new array. Over engineering in my opinion.