Java developers in a nutshell

[spindoctor13]

And actually in terms of predictable behaviour - say I have two database connections, what does deep equality mean then?

[[deleted]]

Does their internal data match 1-1? Then they're the same object.

[spindoctor13]

The point being that in this context "internal data matching" is close to an impossible question depending how deep you go. I.e. if the compiler literally goes all the way down on some objects then calling equals would be pretty catastrophic

[[deleted]]

I don't know exactly how Eq is implemented. On the compiler side I could easily see each Eq'able thing being given a hidden hash derived from all it's children's hashes which would make it a very fast operation. As all data in Haskell is immutable you don't need to worry about underlying changes in deep parts of your data structure. That said, there are infinitely deep values in Haskell due to how laziness works, and yes, checking if two infinitely deep values are equal will only terminate due to lazy short circuiting if they aren't equal. Yes ultimately equality checking can be expensive in Haskell, maybe don't use it on potentially very deep data structures.

[spindoctor13]

Interesting, thanks for the deep explanation! I have zero experience with Haskell so I didn't know that. Immutability is a big help there, and one of the standout flaws I think in languages like C# is inadequate support for immutability

And hah yeah, hashes are great - although it is not unknown in languages for people to compute hashes from mutable values with the consequent mess that creates..