Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: