4 ms·
In the abstract you're right that equality is subtle and complicated, but it seems to me that in practice, most practicing software engineers just want value-eq
by lgessler 7y ago
In the abstract you're right that equality is subtle and complicated, but it seems to me that in practice, most practicing software engineers just want value-equality on garden-variety data structures most of the time (remember == for Strings in Java?), and that for this use-case, a leaky abstraction is fine--preferable, even. At least, the alternative--forcing users to consider the subtleties of equality even in circumstances where it can be safely ignored and having them memorize dozens of cryptic equality operator names--is excessive and unnecessary.
- ska 7y agoI'm not really saying any of those choices is wrong (although clearly you can make design mistakes that make the leaks problematic, if you pick (c)). It's more that none of them are clearly right. Really I'm rejecting the idea that that equality as presented in CL was any of: wrong, design by committee, or something we have learned do better since '84. There are historical artifacts in CL that aren't great (cf filesystem stuff) but this wasn't a good example in my opinion. I hear your argument - not fully convinced other than in a 80/20 sense. And CL was not designed as a language to leave the 20% out in the cold. To be fair I don't find clojure compelling as a lisp but I don't think I'm being biased in above.