5 ms·
Not sure why immutable data structures have surfaced as something important. Typically you never change fields so it is kind of only of academic value if a fiel
by AtNightWeCode 5y ago
Not sure why immutable data structures have surfaced as something important. Typically you never change fields so it is kind of only of academic value if a field in a POD, POJO, POCO or whatever it is called in the specific language actually may change.
- ramblerman 5y ago> so it is kind of only of academic value if a field in a POD, POJO, POCO or whatever it is called in the specific language actually may change. I'm not sure if you've debugged much, or inherited any large legacy projects, but knowing it is immutable vs "typically it isn't" is a pretty big distinction in that moment.
- AtNightWeCode 5y agoGood code don't have this issue.
- slver 5y agoGood code doesn’t have concepts like “typically doesn’t mutate”. It’s either mutable or immutable.
- AtNightWeCode 5y agoThe standard way to do it is to mutate clones as always in Java. Typically by use of libraries that provide this. You really need very bad code to have to think about if objects are mutable.
- slver 5y agoApparently you don’t know most immutable structures are optimized for modified cloning in ways mutables aren’t.
- AtNightWeCode 5y agoThis is Java.
- slver 5y agoAnd?
- marcodave 5y agogood code shouldn't need to be debugged either ;)
- razzm256 5y agoThere are many good things enabled by immutability, like safer/easier multithreading, value-like semantics for objects. It is definitely not only of academic value.
- AtNightWeCode 5y agoTypically you use values and not objects for these kind of things so not that much gained.
- kaba0 5y agoValues require copying, so depending on the problem it can be worse from a perspective point of view.
- the_af 5y ago"Typically" this means you can never be sure, which is a problem.
- AtNightWeCode 5y agoSure of what? If your code is not garbage it takes two seconds to see where things change. It should be very places in the code.
- slver 5y agoIt takes two seconds in a hello world demo. It takes probably more in a millions of lines project.
- AtNightWeCode 5y agoFields of an object should typically not change. But yes, I had to make a field of a class immutable some time ago. There was a bug and I could not read the code to figure out were the object was changed. Still, caused by bad code. Same object sent around pretty much everywhere.
- slver 5y agoSo even you, the master of great code, wrote bad code. I guess immutability is worth something then.
- AtNightWeCode 5y agoI did not write the original solution...
- slver 5y agoSo you reckon we only need immutability if two or more people have to work on code. Ok.
- reom_tobit 5y agoKeyword being “may”. Guarantees are nice. Especially if objects are going to be passed around every which way from Sunday. It allows you to better reason about what could happen, and where. Java has taken a while to get there, but I’m glad that they have finally.
- AtNightWeCode 5y agoWell, if you pass around objects and change their state records will not help. People who does this are already using immutable frameworks in Java to clone and change some field and then pass it along.
- reom_tobit 5y agoSure, things have been bolted on top of Java to allow this to happen. People have made use of them. Java now has built in support for these things, so no longer will developers rely on third-party solutions. This is great for the Java world, and for any languages that are being built on top of the JVM by extension. I would politely disagree with your characterisation of it being just academic, as an engineer I find it incredibly exciting. Admittedly, my bar is pretty low for excitement these days.
- AtNightWeCode 5y agoI have done Java for 25 years and never felt any need for records. There are so many issues...