3 ms·

It's insane in that Java pretends to have strong, static typing, then does things like that.

by Zak 9y ago

Spivak 9y ago
Overloading the plus operator for strings was probably a mistake in the language but that's hardly a condemnation of their type system.
- Zak 9y ago
  A lot of languages overload + to mean concatenate. I think that's a mistake, however... In Python: "abc" + None TypeError: cannot concatenate 'str' and 'NoneType' objects "abc".join(None) TypeError: can only join an iterable In Ruby "abc" + nil TypeError: no implicit conversion of nil into String In Lua = "abc" .. Nil attempt to concatenate global 'Nil' (a nil value) But not Java. Java implicitly tries to coerce the provided value to be a string, which seems out of place in a language that values type safety. That all types might also be null also seems out of place in a language with strong, static typing, but that's been discussed to death. The problem is compounded by the fact that null is actually converted to "null" instead of an empty string.
  - Too 9y ago
    On the other hand, it's easier to get into this situation in Python than Java. bar = "bar" foo = "foo" foo_bar = foo + baar # intentional typo (baar will be None) In Java this would be a compiler error, but python accepts it until the program is being run.
    - Zak 9y ago
      That's a NameError in Python: undefined variables don't have a value, not even None. It won't be caught until runtime since there's no AOT compiler in Python, but it's the same kind of error it is in Java. My claim isn't that Python is safer overall than Java. Instead, it's that Java, a language that is mostly type safe, most of the time should not have these two potentially surprising behaviors: 1. The standard string concatenation operator does implicit coercion rather than rejecting an input that isn't a string. There should be a builtin to make a string from any value no matter what for logging and debugging, but that shouldn't be the standard concatenation operator. 2. This is more controversial, but strongly statically typed languages should not allow arbitrary values to be null. That sabotages one of the major strengths of strong static typing. Instead, there should be an option type to make it explicit. For something familiar to most programmers, SQL does this.

It's insane in that Java pretends to have strong, static typing, then does things like that.

by Zak 9y ago

It's insane in that Java pretends to have strong, static typing, then does things like that.

Overloading the plus operator for strings was probably a mistake in the language but that's hardly a condemnation of their type system.

Zak 9y ago
A lot of languages overload + to mean concatenate. I think that's a mistake, however... In Python: "abc" + None TypeError: cannot concatenate 'str' and 'NoneType' objects "abc".join(None) TypeError: can only join an iterable In Ruby "abc" + nil TypeError: no implicit conversion of nil into String In Lua = "abc" .. Nil attempt to concatenate global 'Nil' (a nil value) But not Java. Java implicitly tries to coerce the provided value to be a string, which seems out of place in a language that values type safety. That all types might also be null also seems out of place in a language with strong, static typing, but that's been discussed to death. The problem is compounded by the fact that null is actually converted to "null" instead of an empty string.
- Too 9y ago
  On the other hand, it's easier to get into this situation in Python than Java. bar = "bar" foo = "foo" foo_bar = foo + baar # intentional typo (baar will be None) In Java this would be a compiler error, but python accepts it until the program is being run.
  - Zak 9y ago
    That's a NameError in Python: undefined variables don't have a value, not even None. It won't be caught until runtime since there's no AOT compiler in Python, but it's the same kind of error it is in Java. My claim isn't that Python is safer overall than Java. Instead, it's that Java, a language that is mostly type safe, most of the time should not have these two potentially surprising behaviors: 1. The standard string concatenation operator does implicit coercion rather than rejecting an input that isn't a string. There should be a builtin to make a string from any value no matter what for logging and debugging, but that shouldn't be the standard concatenation operator. 2. This is more controversial, but strongly statically typed languages should not allow arbitrary values to be null. That sabotages one of the major strengths of strong static typing. Instead, there should be an option type to make it explicit. For something familiar to most programmers, SQL does this.