3 ms·

I learned this 25 years ago when I got started with the language. It tripped me up once, I learned about how references work in Java, and that was that. We are

I learned this 25 years ago when I got started with the language. It tripped me up once, I learned about how references work in Java, and that was that. We are expected to learn about our tools.

jraph 5y ago
> We are expected to learn about our tools. I hope making mistakes is ok though? I learnt C years before Java, it's also the first language I properly learnt. And a little bit of C++ too, so I've known the concepts of pointers and references way before learning Java. In C, you also either do pointer equality or explicit value equality (with strcmp) for string equality tests. I never had any issue understanding how things work in Java. It's not about learning anything. It's about doing mistakes. And I won't take "you should know better" as a counter argument to a mention of some rough edge in an API or a programming language. It's like Javascript: you might know the differences between == and === in Javascript full well, but still happen to write == by mistake because you just wrote some C/Java/Python code just before. I'll probably not forget about .equals(...) in Java most of the time but the fact that == would be silently accepted and not do what is wanted is still a bit concerning (and .equals(...) is ugly, too). A linter will do indeed and that's a fair point. I'd argue that linters are there to work around rough edges of programming languages, but that's fair enough too, every programming language has its gotchas and I'll accept considering a programming language + its linter(s) instead of a programming language alone. However, that's still not ideal because you might have to work on non linted code and deal with these gotchas without any safety net. I hadn't thought about number comparisons (mentioned in other comments) but that's even worse indeed. It's no wonder Kotlin and Groovy both chose value comparison for ==.

I learned this 25 years ago when I got started with the language. It tripped me up once, I learned about how references work in Java, and that was that. We are expected to learn about our tools.

jraph 5y ago

> We are expected to learn about our tools. I hope making mistakes is ok though? I learnt C years before Java, it's also the first language I properly learnt. And a little bit of C++ too, so I've known the concepts of pointers and references way before learning Java. In C, you also either do pointer equality or explicit value equality (with strcmp) for string equality tests. I never had any issue understanding how things work in Java. It's not about learning anything. It's about doing mistakes. And I won't take "you should know better" as a counter argument to a mention of some rough edge in an API or a programming language. It's like Javascript: you might know the differences between == and === in Javascript full well, but still happen to write == by mistake because you just wrote some C/Java/Python code just before. I'll probably not forget about .equals(...) in Java most of the time but the fact that == would be silently accepted and not do what is wanted is still a bit concerning (and .equals(...) is ugly, too). A linter will do indeed and that's a fair point. I'd argue that linters are there to work around rough edges of programming languages, but that's fair enough too, every programming language has its gotchas and I'll accept considering a programming language + its linter(s) instead of a programming language alone. However, that's still not ideal because you might have to work on non linted code and deal with these gotchas without any safety net. I hadn't thought about number comparisons (mentioned in other comments) but that's even worse indeed. It's no wonder Kotlin and Groovy both chose value comparison for ==.