"Mutable objects have a hash method and can go in Hashes. Why!" This is indeed terrible. It is broken beyond repair and it's probably because they thought Jav

"Mutable objects have a hash method and can go in Hashes. Why!" This is indeed terrible. It is broken beyond repair and it's probably because they thought Java doing something similar with their hashcode() method was "smart". It is not that mutability is "evil". It is that contracts provided by the language / APIs on top of mutability definitely is evil, because it's impossible to obey / respect the contracts. It is probably one of the biggest source of hard-to-find / hard-to-reproduce / hard-to-debug bugs. The problem goes way further than that in Java that said: the very presence of "hashcode()" and "equals()" at the very top of the hierarchy (in the Object class) is fundamentally broken. Even if you are using immutable objects in Java, you are still deeply fcked if your classes are non-final. Even if you classes are* only allowing to create immutable objects and are final, you are still deeply fcked if you use composition. Because it is impossible* to extend a class (or use composition) and satisfy the hashcode/equals contract. This was explained in "Effective Java" back in the days. Now it may even be possible that this very equals/hashcode/mutability SNAFU is, unconsciously for a lot people, at the heart of the current backlash and hatred towards mutability. The fact that it is so broken (and provably broken: the contracts CANNOT, as in RFC2119, be respected) may be the reason while functional programming is making a comeback. It certainly is for me and I'm not looking back.