We humans like dealing in absolutes. It's easy. Nuance is hard. Unfortunately for us, everything involves nuance. That's why we should question our...
For further actions, you may consider blocking this person and/or reporting abuse
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.
I attribute the 'don't mutate gospel' to inexperience. It was accepted at face value in Js community solely because of opinionated frameworks like React.
So much so, that we now see entire component designs requiring its use.
In a poll here on Dev.to, I asked for comments on the goodness on non mutable design. The best answer was 'to avoid per element comparisons' to determine what changed in an array'. All other answers were weak.
We got by just fine mutating objects in C# for 30 years. So the new found non mutable crowd has little history to stand on.
Also JS didn't really have strong typing nor did users really understand by reference and by value. All contributed to traps.
It's all about perspective and experience. Either way works, but what I choose in the end is simply the right thing for my project.
This article is greatl!
I really appreciate this perspective, John. As I mentioned in the introduction, we often find ourselves clinging to dogmatic views based on some bad experiences or simply because nuance is hard.
I also think the “opinionated frameworks like React” part is more like a misunderstanding a lot of folks have about React. The truth is React works based on referential equality, so its only opinion on mutation is that you shouldn’t mutate an object if you expect React to detect that change and take an action based off of it.
Anyways, thank you so much for the thoughtful response!
My thoughts on React being opinionated is based on how it demands its own way of doing things. For example just look at how it did styling. React is 20 times less opinionated than Angular which is good. The advent of webassembly brings all discussions like these to an end. We now have the ability to write entire websites using c# and it's huge set of class libraries. Cool
Object reuse as a pattern of shape for mutation is just ridiculous. It violates SRP and is always by reference. Thus the birth on non mutable to me was based on malpractice all along.
When a framework dislikes creation of new objects and instead tries to copy and change, it has a fundamental issue in allowing it to happen without warning. Newbies fall on this trap often.
No what I meant was 25 years of programming experience with no issues with mutating objects speaks volumes.
All the non mutable stuff has only 1 great attribute; which is simply a comparison of two references to instantly detect change.
This same thing has been possible for more than 25 years now in .Net
You are explaination is save alot of time in debugging when I work in JS.This artical is freaking cool.
Thank you, I really appreciate that!
Ok list some advantages to immutabilty.
As for Haskell is it in top 5 or 10?
The 7 articles shown are not absolute truths but are presented that way. Total hype.
I prefer not to mutate the object in any case.